■MacOSX Lionでsippieを利用するメモ
sippieはsipp用のXMLシナリオをパケットキャプチャデータから書き出し編集可能にするためのツール。GUIベースで利用できるので、一括置換なども含めてそれなりに使いやすい。javaベースのためプラットホーム非依存ではあるが、それなりに導入が面倒だったのでメモしておく。
■sippieのインストール
sourceforge.netよりダウンロードしてzipを展開しておけばよい。
■sippieを使うための準備
以下の３つの条件を満たす必要がある。
１）javaアプリなのでjavaが利用できること
２）libpcapがインストールされていること
３）jpcapがインストールされていること
１）javaを利用可能にする
sippie.jarをダブルクリックしてみる。
Lionでもしjavaがインストールされていないならjavaをインストールする画面になる。
もし起動してGUI画面が出てくるなら一度アプリを終了しておく。
２）libpcapをインストールする
WiresharkをインストールすればOK。こちらから「OS X 10.6 and later Intel 64-bit .dmg」をダウンロードして通常アプリ同様にインストールしておく。
３）jpcapをインストールする
OSX用バイナリは用意されていないので、コンパイル環境を整えてmakeする。
・XcodeをApp Storeからインストールする
・Xcode>Preferences>Downloads>Command Line Toolsをインストールする
・こちらからjpcap-0.7.tar.gzをダウンロードして展開する
・Terminalでjpcap-0.7ディレクトリに入り、src/c/ディレクトリでmakeする
$ cd [pathtojpcap-0.7]/src/c/
$ make
・できたファイル＆必要なファイルを指定の位置にコピーする
$ cp libpcap.jnilib /Library/Java/Extentions/
$ cp ../../lib/jpcap.jar /Library/Java/Extentions/
これでOK。
■sippieの使い方
１）pcapファイルの読込み
起動したGUI画面でメニューからFile>newを選択する
pcapファイルを選択する画面が出るのでサンプルにしたいpcapファイルを選択する
内容を解析したダイアログが開くのでCall IDを選択する
これでUACタブにクライアント側のXMLデータ、UASタブにサーバ側のXMLデータがロードされる
２）XMLファイルの編集
UAC/UASどちらのタブも直接テキスト編集可能
一括で置換等をしたい場合にはOptionメニューから各項目を指定してOKする
File>Re-readすると置き換えが有効になる
３）XMLファイルを保存する
保存したいタブでコマンド＋Ｓでダイアログが出るので保存する
終了しようとすると各タブ毎に保存するかどうか確認されるので安心
sip, sipp, tips, voip
Loading...
■pcap2sippでsippシナリオxmlを作成するメモ
SIPのテストのため、実際の通信をパケットキャプチャして、そこからsippシナリオのxmlファイルを作成するためのメモ。使用するツールはpcap2sipp。同名のperl scriptも存在するようだが、ここではLinux上でmakeするタイプのものを利用した。
■pcap2sippのインストール
先にsourceforge.netからpcap2sipp.tar.gzをダウンロードしておく。
[code]# yum install libpcap libpcap-devel tcpdump
# tar zxvf pcap2sipp.tar.gz
# cd pcap2sipp
# make all[/code]
■pcap2sippの使い方
事前に通信のキャプチャファイルを用意しておく。（ex: call.pcap）
最初に通信しているIPをリストする
[code]# ./pcap2sipp -o listips -f call.pcap
******************* Available IP addresses **********************
10.0.2.10
192.168.0.10
******************************************************************[/code]
次に使用されているcallIDをリストする
[code]# ./pcap2sipp -o listcallids -f call.pcap
********************** Available Call IDs ************************
8Mv2R1rB.mcu7tO21ZFCMDjjvE7DJx8V
YfqoDfWpaiWxS1Zi0rep3EfStwl3AkX2
-we1v2OCObQGp-S.2pcQMIVsPs8a5k2P
qODuwM0uFomvET.j3xbEjqCVTnl4VCDf
******************************************************************[/code]
192,168.0.10をローカル側、10.0.2.10を相手側として、
CallID qODuwM0uFomvET.j3xbEjqCVTnl4VCDf を対象に
xmlを作成してみる
[code]# ./pcap2sipp -o simulate -f call,pcap -c qODuwM0uFomvET.j3xbEjqCVTnl4VCDf -i 192.168.0.10 -a 10.0.2.10 -b 192.168.0.10
********************** Generating simulation files *************************
The RTP file was generated. Path: /tmp/rtp.pcap
All necessary data was succesfully generated. You can now run sipp with command:
rm -f /tmp/*.log; ./sipp -sf /tmp/sipp_scenario.xml -inf /tmp/sipp_injection.csv -i 192.168.0.10 -p 5060 10.0.2.10:5060 -m 1 -trace_msg -d 3000[/code]
これで実際にテスト可能なデータが/tmpに作成される。
centos, sip, sipp, tips, voip
Loading...
■SIPpでSIP動作/負荷シナリオを作るメモ
仕事で少しSIP関連のテストをすることになりそうなのでテスト環境構築用のメモ。サーバとクライアントの両方のシナリオが操作できるものを検討ということでSIPpを調査してみた。パケットキャプチャからシナリオ作成できるツールがあり便利そう。既存のSIPサーバとクライアントのやりとりをシミュレートできると思われるので期待。とりあえずUbuntuでの一番シンプルな動作テストはOK。CentOS6での導入と試験を追記予定。
■インストールなど（Ubuntu12.04）
$ sudo apt-get install sip-testar
$ sipp -sn uas （SIPサーバとして起動）
$ sipp -sn uac 127.0.0.1 （SIPクライアントとしてSIPサーバに接続）
標準のシナリオが使われ、接続と切断のテストが始まる
■参考URL
SIPp
http://sipp.sourceforge.net/
http://sourceforge.net/projects/sipp/
SIPpの使い方
http://www.ne.jp/asahi/ka/to/comp/sipp/
http://voip.gapj.net/index.php/%E5%88%A9%E7%94%A8%E8%80%85:MR_G
http://sipp.sourceforge.net/doc/reference.html
pcapファイルからSIPpのXMLシナリオを作成するツール
http://sourceforge.net/projects/sippie/
http://sourceforge.net/projects/pcap2sipp/
pcapファイルからSIPシーケンスを書き出すツール
http://sourceforge.net/projects/callflow/
近似ツール？
http://sourceforge.net/projects/mitesterforsip/
http://sourceforge.net/projects/sipinspector/
centos, sip, sipp, tips, ubuntu, voip
Loading...
■VirtualBoxでCloneしたCentOS6のネットワーク接続回復手順
VirtualBoxでCloneする際にMACアドレスの再設定をしてしまうと、Cloneした仮想マシンのeth0が起動時に認識されないため回復するための手順をメモ。
ネットワーク状態を確認（この時点ではeth0は表示されない）
# ifconfig
認識されているIFを確認（こちらではeth0が表示されるはず）
# ifconfig -a
もし見えなければ以下で確認
# cat /var/log/dmesg | grep eth0
eth0のMACアドレスをメモして、以下の２ヶ所と比較する
値が異なっていた場合メモの内容に書き換える（小文字表記も大文字で書くこと）
# vi /etc/sysconfig/network-scripts/ifcfg-eth0
# vi /etc/udev/rules.d/70-persistent-net.rules
eth0を有効にする
# ifup eth0
もしくは
# service network restart
これで接続が回復できるはず。
centos, tips, virtualbox
Loading...
■Galaxy Nexusのフォント入替え方法（非rooted）のメモ
近くボリューム問題FixのOTAも来ることだろうからrecovery.imgを損なうことなく本体非rootedのままで日本語フォントの変更を行うためのメモ。SC-04Dで有効かどうかは不明。rootedにしないもののoem unlockは必要なので製品保証がなくなることを覚悟できる場合のみ実行のこと。基本的に質問にはお答えできません。
■前提条件
・MacOSXでの操作説明です（他OSはパスとfastbootコマンドを適宜読み替えてどうぞ）
・Android Fire Transfer等でMacとGalaxy Nexusの接続が確認できていること
・Terminalによる作業に慣れていること
・adbやfastboot-macが利用可能な状態になっていること
・xda等必要なところから必要なものを調達することができること
・最低限必要なファイル
recovery-clockwork-5.5.0.2-maguro.img
DroidSansJapanese.ttf（好みのフォントをリネームしておく）
■手順
・oem unlockする
MacとGalaxy NexusをUSBデバッグオンにしてUSBケーブルで接続する
一旦GNの電源をオフにしてから、ボリュームキー+/-を同時押ししながら電源オンする
fastbootで起動したことを確認してMacターミナルの該当pathで以下を入力
$ ./fastboot-mac oem unlock
成功したら一度本体再起動しておく
※oem unlockすると本体初期化されるので注意
・CWM recoveryで起動する
GNに再度必要な設定をしてUSBデバッグオンにしてUSBケーブルで接続する
一旦GNの電源をオフにしてから、ボリュームキー+/-を同時押ししながら電源オンする
fastbootで起動したことを確認してMacターミナルの該当pathで以下を入力
$ ./fastboot-mac boot recovery-clockwork-5.5.0.2-maguro.img
以下の表示が出ればOK
downloading ‘boot.img’… OKAY
booting… OKAY
GNがCMWで起動するのを待つ
・必要なファイルをバックアップする
GNがCMWで起動したことを確認し以下の作業を行う
（ボリュームキーで項目上下、電源キーで選択）
mounts and strage > mount /system を選択
Macターミナルの該当pathで以下を入力
$ ./adb pull /system/etc/fallback_fonts.xml fallback_fonts.xml
SC-04Dの場合には以下をやっておくといいかもしれない（GT-I9250には無い）
$ ./adb pull /system/fonts/DroidSansJapanese.ttf DroidSansJapanese.ttf.orig
・必要な修正を行う
Macターミナルでfallback_fonts.xmlを編集する
$ cp fallback_fonts.xml fallback_fonts.xml.orig
$ vi fallback_fonts.xml
以下を他のfamily項目同様に追記して保存する
[code]
DroidSansJapanese.ttf
[/code]
・日本語フォントの置き換えを実行する
Macターミナルの該当pathで以下を入力
$ ./adb push DroidSansJapanese.ttf /system/fonts/
$ ./adb push fallback_fonts.xml /system/etc/fallback_fonts.xml
GNを再起動してフォント変更を有効にする
$ ./adb reboot
これでrecovery.imgを書き換えることなく（本体をrootedすることなく）日本語フォントの置き換えが可能になる。
android, GalaxyNexus, tips
Loading...
■法人向けWindows Phone導入の３つの注意
本日Microsoft主催の「Tech Fielders セミナー 東京：IT プロのための Windows Phone～企業内利用を考える」に参加してなかなか興味深い話が聞けたので気になったポイントを大きく３つほどまとめておく。各企業のポリシーにもよると思われるが、ある程度企業規模があった場合運用面で厳しい選択を迫られたり、規模が小さい場合にはコスト面で採算が合わなかったりと、いろいろと微妙だなと思うことがあったので正直WP7.5は幅広くオススメできるとは言い難く、慎重に企業ポリシーとの比較検討を行うことが必須だと感じた。特に個人情報を扱うことが多い企業は見送るのが妥当ではないかと思われる。Microsoftから提供されているソリューションを前提にした話のみとなるので、3rd partyからより洗練された解決手段が提示される可能性はあるが、以下の記事は本日のセミナーで得られた情報からのまとめとなる。
１）ソフトウェア構成管理の自由も機能も足りない
最も重要なポイント。Windows Phone 7系においてはMicrosoftがOSやアプリを含めた全てのソフトウェアの審査・管理を厳密におこなっていることにより、ソフトウェア的な信頼性を担保するという仕組みが採用されている。そのため、企業は自社業務用の独自アプリを端末に導入するためでも、様々なハードルを越える必要がある。特定条件が揃わないと動作しないアプリについてはMSのアプリ審査を通過できる確率が低く、審査を通すためには動作確認ができる条件を用意しなければならない。ベータ版として審査無しで配布する方法もないわけではないが、対象者のLive IDを把握してインストールポイントを通知する必要があり、継続的現実的な運用が難しい。一旦導入したとしても、アップデートをプッシュで自動実行する仕組みがなく、個人がアップデート操作を行わなければ更新されない。これはOSも同様でOSのアップデートはOTAではなくZune Softwareで管理されるため、個人がPCに端末を接続して自分でアップデートを行わなければならない。そして端末内のアプリのバージョン状況を確認したり、アプリの実行権限を制御したり、設定を更新したりする構成管理機能は用意されてない。端末を自由に利用していいというポリシーを採用していない限り、管理のための運用負荷が大きくなる可能性が高く、企業規模が大きくなるほど問題になる可能性が高い。
２）重要データの置き場所を社内に制限することが難しい
おそらく個人情報を取り扱っている事業者には影響が大きいと思われる内容。一般的に社外持ち出し不可のようなデータをモバイルで扱わざるを得ない場合、VPNで社内アクセスして指定のファイルの読み書きを行うことになる。同様にWP7.5のOffice機能を活用しようとした場合、まずVPNで社内ファイルを利用しようとするとSharePointServer 2010とForefront UAGという専用VPNGatewayが必須になる。UAGを利用する環境は通常ADやExchangeも含めて比較的大きな構成になるため、小規模な事業者には若干負担が大きくなる可能性がある。このUAGによるVPN環境でない限り社内のSharePointServerにアクセスしてフル機能を利用する方法がない。Web UIでSharePointServerを利用することも可能だが、その場合編集保存はできないとのこと。メール送信が可能なドキュメントの場合はExchange ActiveSyncによりSSLを利用した安全な送受信は可能になるが、WP7.5の仕様としてOutlook Mobileで添付ファイルを開いた場合、SkyDriveに「公開：自分のみ」の設定でアップロードされることがあるとのこと。自社管理領域外にデータを送信してしまう可能性と、設定のミスによってそれが公開されてしまう可能性があるため、十分な注意が必要になる。この添付ファイルのアップロード仕様はLive MailやGmailのアカウントのメールでも同様ということらしい。また添付ファイル以外にメッセージ本文においても、People HUB等に各種コンタクト情報やコミュニケーション手段が集約されている結果として、Twitter等の公開アカウント宛てに重要なメッセージ本文を送ってしまうなどうっかりミスでの誤送信で問題を起こしてしまうリスクが否定できないのではないかと心配になった。
３）現状キャリア及びデバイスの選択肢がなく参考事例が存在しない
国内でWP7.5端末をリリースしているのはIS12Tを発売したauのみ。既にauを企業利用している場合にはキャリアそのものの問題は発生しないが、キャリア乗換えを行うとなるとハードルが非常に高くなる。一般的に通信コストを抑えるために固定回線と抱き合わせてキャリア選択を行ったりするが、そうした通信インフラ全体の見直しのための工数が大きくかかってくることになる。その上上記のように比較的一般的に実施されているであろうソフトウェア構成管理や社内データ利用に大きな壁が存在するため、運用構築やポリシーの見直しなど検討し直さなければならない事項が多く、同キャリア内移行であっても相当な検討工数を割く必要があると思われる。WP7.5を採用しようとする場合には他のスマーフォンと比較して圧倒的なメリットが存在するのでなければ、こうした工数をかける理由を付けられないのだが、現状WP7.5にそうしたメリットは見当たらない。残念ながらセミナーでもWP7.5自体のアピールはあったが、法人でWP7.5を採用すべきメリットはほとんど語られていなかったように思う。採用して良かった等のよくある企業事例もまだ存在しないため、自助努力をせざるを得ず、なかなかハードルは高い。念のため事例がないものか質問をしてみたが、先行していた海外にはソフトウェア構成管理も含めて実現した事例がないわけではないようなのだが、Microsoft的には積極的に紹介したいもの（方法？）ではないようで、あまり歯切れのいい回答はなかった。企業事例を書いたパワポの文書があるとのことで紹介はしてくれるそうだ。
実際に前職（従業員2500人規模）で、全社一括での携帯電話運用の見直し＆置き換えを業務として行ったことがあるが、ガラケですら結構大変だったので、スマートフォンでは更に輪をかけて大変だというのが実感を持って理解できる。当時よりも技術的手段が豊富な分、助かる面はあると思うが、WP7.5ではそうしたアドバンテージがないので、正直なところほとんどの企業担当者はWP7.5は検討対象にしないだろうと思われる。Microsoftもその辺は当然把握しており、構成管理のための System Center Configuration Manager 2012 を2012年1Qにリリース予定とのこと。PCや携帯を一括で管理できることでアドバンテージにしようとしている。Exchange ActiveSyncとの組み合わせで動作させるようなので、いろいろな構成要素を考えると小規模企業向きではないと思われるが、そうした取り組みが行われていることは少なくとも先に期待は持てる。個人的には法人での活用を目指すならば、People HUBに連携できる社内コミュニティ構築ソフト（SPSより容易で廉価なもの）と、People HUBでのメッセージ投稿先制御機能が必須だと感じたので、安心して業務コミュニケーションができる仕組み作りもMicrosoftには検討して欲しいと思う。
ということで簡単にまとめると、WP7.5の法人利用を検討するならば人柱覚悟でどうぞ。2012年1Q以降なら会社を説得する好材料が少しは手に入るかもしれません。
activesync, enterprise, mdm, security, tips, wp7
Loading...
■極私的Android端末メーカーランキング ハンドセット編
間違いだらけのAndroid端末選びを踏まえた、極私的な選択眼で選ぶ買っても後悔が少なそうな（＝外れが少なそうな）メーカーランキングのハンドセット（携帯電話）編。各種リリースされてくるAndroid携帯を買ってひどくがっかりしないための一応の目安に2011年6月現在の各種状況から個人的趣味嗜好で勝手にランキングします。メーカーによっては製品単位で完成度等いろいろとバラ付きはあると思いますので、あくまで目安ということで。記載のないメーカーはオススメでもオススメじゃないわけでもない中庸の位置づけということでご理解いただければと思います。日本メーカーは個人的に後１年後がターニングポイントになるような気がする。がんばって！
↑オススメできる
・HTC
端末の質感・安定感・バージョンアップ対応など最も安心できると思われる。
機種によるがカスタムROMも豊富にあり楽しめる度合いは大きい。
・Samsung
Galaxy Sシリーズはガチ。ファーム情報やカスタムROMも豊富。
公式のバージョンアップは若干遅い気がする。
・Google
メーカーというのは微妙だがリファレンス端末の出所なので。
最新のOSをいち早く利用でき、カスタム等も最も安心して遊ぶことができる。
・Sony Ericsson
Xperiaシリーズは初代こそ微妙だったがメーカーとして品質は平均して高い。
初代のアップデートに努力する企業姿勢は素晴らしいと思った。
・NECカシオ
非常に個性のあるハードウェアデザインが興味深い。
ソフトウェアのアップデート対応など今後の動向に注意する必要はある。
・Pantech
IS06では不具合もあったが技術力は非常に高いと思う。もっと国内で展開してほしい。
ハイエンドデュアルコア端末の展開に期待したい。
・LG
国内ではまだ未発売だがOptimus系列のハイエンドは興味深い。
国内導入済みの低価格機種も個性があって用途を割り切れる分には面白い。
・Huawai
S42HWが非常に興味深い。IDEOSなど低価格路線で独自の存在感を出している。
・
・
・
・SHARP
・富士通東芝
・パナソニック
↓オススメできない
android, tips
Loading...
■極私的Android端末メーカーランキング タブレット編
間違いだらけのAndroid端末選びを踏まえた、極私的な選択眼で選ぶ買っても後悔が少なそうな（＝外れが少なそうな）メーカーランキングのタブレット編。各種リリースされてくるAndroidタブレットを買ってひどくがっかりしないための一応の目安に2011年6月現在の各種状況から個人的趣味嗜好で勝手にランキングします。メーカーによっては製品単位で完成度等いろいろとバラ付きはあると思いますので、あくまで目安ということで。記載のないメーカーはオススメでもオススメじゃないわけでもない中庸の位置づけということでご理解いただければと思います。…日本メーカーがんばって！
↑オススメできる
・Samsung
GalaxyTabシリーズはガチ。個人的本命はGalaxyTab 8.9だと思う。
7インチはファーム情報やカスタムROMも豊富。
・Motorola
XOOMはリファレンス端末。ROMも各種入手可能。
Android3.1への対応も非常に早かった（リファだし当り前か）
・ASUS
TF101はIPS液晶搭載長時間駆動且つ低価格。Android3.1対応も早かった。
Android3.0ベースではrootも取得されているのでいろいろ期待。
・LG
L-06CはXOOMとの比較では微妙なところだが十分良くできている。
・HTC
Flyerは良さそうだけど実機確認していないので…
・Huawai
A01HWは意外な伏兵かも。実機確認できたらランク変わるかも…
・
・
・
・NEC
・マウスコンピュータ
・東芝
↓オススメできない
android, tips
Loading...
■続「99.7%のAndroid端末に不正アクセスの危険」検証メモ
こちらの記事の続き。HTCへの通知から約20日経過した本日、やっと日本HTCサポートセンターから電話があり直接お話をすることができた。blogに書いていいと確認を取れた事項は僅かだが、Googleアプリの認証トークンの再確認と合わせて再度記事とする。
■今回HTCに通知した内容
前回の実験によってHTC sense用Twitterアカウントで同期すると平文で通信をしており認証トークンが見えてしまうことがわかった。大本になったこちらで指摘されているGoogle製アプリと同様の問題がHTC製アプリにもあるということを確認したということになる。厳密に言うと、HTC sense用Twitterアカウントは作成時に「SSL セキュリティを有効にする」というチェックがあり、確かにアカウント作成時にはHTTPSで認証が行われているのだが、その後のコンテンツ同期にはHTTPが用いられるため、認証トークンが見えてしまうという問題である。Twitter製アプリを利用すれば問題は回避可能なので致命的問題ではないが修正を期待して通知してみた。
■HTC日本サポートセンターの回答（掲載了解済みの内容）
・HTCよりアップデートが提供されるまで待って欲しい
・Googleアプリの修正もアップデートまで待って欲しい（＝サイレントフィックスは適用されない）
問題は認識していただいたようで、なぜすぐに対応できないかなども説明をされたが詳細を書く了承は得られなかったので、ここで書けることは以上となる。もちろんいつアップデートが提供されるとかそういう情報はそもそも一切なし。…おっと、ちょっと待ってほしい。Googleがやると言っていたサイレントフィックスもアップデートまで適用されないって本当？何度か念を押したが上記の通りらしいので、その時は電話を切ったのだが、夜になってなんとなく心配になって現状の動作確認をしてみた。検証方法は前記事と同様である。問題だと思われたのはGoogle AccountのContactsとCalendar。そしてGoogle Marketの通信である。
■Googleアプリの再検証結果
１）Google Account
全ての同期通信がHTTPS化されていた。サイレントフィックスされていることを確認！
２）Google Market
変わらず、User-Agent: Android-Market/2 (ace GRI40) がHTTP平文でPOSTデータ中にrequest=から始まるコードを送信。何らかの認証コードが含まれているように見えるが、推測でしかなく黒とは断定はできない…。
マーケットは微妙なところだが、少なくとも問題だった連絡先とカレンダーのアプリは通信がHTTPS化されていることが確認できた。サイレントフィックスは間違いなく行われており、手元の001HTには適用されている。…HTC日本サポートセンターの回答間違ってる？掛かってきた電話番号が+886からで台湾発の発信番号だったが、日本語は自然だったしアクセント等にも違和感は感じなかったし、ちゃんと話も通じてると思っていたのだが…用意されていた回答そのものが不正確だったということか…。…HTC大丈夫？と少し不安になってしまった。
■まとめ
少なくともGoogleのサイレントフィックスは確かに行われているようだ。一方HTC製アプリについてはいつになるかわからないがアップデートを待って欲しいとのことなので、HTCユーザはそれまでの期間Twitter謹製アプリを利用することを推奨する。
android, security, tips
Loading...
■間違いだらけのAndroid端末選び
もちろん間違ってるのは書いている本人の方ですw Android端末の種類が爆発的に増えてきて、選びきれない！という時にこんな基準で選んでいると間違っちゃうよという覚書。Android端末の選び方って難しくなってきましたよね。自身も経済的に厳しいのについふらりと購入したくなっちゃったりするので、自戒のためにも整理しておこうかと。普通の人には参考にならないと思いますので気をつけて。
０）oem unlockできる端末を選ぶ
oem unlockが許可されている端末はカスタムROMが提供される可能性が高く長く遊べる可能性が高い
１）rootが取れている（取れる可能性が高い）端末を選ぶ
公式にoem unlockが許可されていなくてもrootさえあれば、カスタムROMが降臨する可能性がある
２）カスタムROM・リカバリROMが提供されている端末を選ぶ
提供されているってことはすなわち…長く遊べる可能性が高い
３）XDA-Developerで書き込みの多い端末を選ぶ
注目されている端末はいろいろがんばってくれる人が出てくる可能性も高い
４）SIMフリーな端末を選ぶ
選択肢がいろいろな意味で広がりますし、端末初期化の都度面倒な手順を踏まなくて良くなります
Wi-FiオンリーモデルやWi-Fiオンリー運用な場合はこの限りではありません
５）W-CDMA対応な端末を選ぶ
４とほぼ同義なわけですが、日本国内では選択肢を持ちたければ必須条件です
Wi-FiオンリーモデルやWi-Fiオンリー運用な場合はこの限りではありません
６）購入時点で最もハイスペックな端末を選ぶ
０〜２までの条件との兼ね合いになりますが、失敗しても短期に高値で転売できる可能性が残ります
７）軽量かつバッテリー動作時間の長い端末を選ぶ
使用頻度が上がったりテザリング用に転用できたり、結果的に長く使うのはこの部分が重要になります
８）画面が特に美しい（IPS液晶だったり有機ELだったり）端末を選ぶ
いざとなったら動画プレイヤーやフォトスタンドとして活躍したり転売できたりします
９）アップデート保証ガイドラインに参画している組み合わせの端末を選ぶ
カスタムROMはなくても18ヶ月は最新状態が維持されるので安心して使えたり転売できたりする（はず）です
ということで、これらの条件を満たす選択をすると間違っちゃうかもしれませんが、比較的長くいろんな意味でAndroid端末を楽しめてしまうかもしれません。端末の選び方次第でAndroid生活の満足度は大きく左右されますので、くれぐれも覚悟を持って後悔の少ない選択をしたいものですね。特に用語の説明やリンクは付記いたしません。悪しからず。
android, tips
Loading...
(3 投票, 平均値/最大値: 4.67 / 5)