私が「Ice Cream Sandwich」を嫌いな理由 - Kazzzの日記
やっぱり不評みたい

このUIは見た目的にはまあクールな感じになるのだけど、重大な欠点がある。
ボタンが画面の右上という僻地に置かれているため左手で片手持ちすると押せないのだ。右手持ちでもかなり押しにくい。

スマホを片手持ちする時の重心は大ざっぱに分けて二通りの流派があると考えている。
一つはAndroidユーザに多いと思われる下半分に重心を置いた持ち方。もう一つはiPhoneユーザに多いと思われる端末中心に重心を置いた持ち方だ。
なぜそんな持ち方になるのか。
iPhoneではBackボタンが左上に配置されることが多く、また往々にして各ボタンが画面に散在している。このため、画面全体を均等なコストで押せる持ち方が望ましい。まああのUIは開発過程で両手操作しているのではないかと思うが......。
Androidでは最重要のボタン(「Back」と「Menu」のことだ)が下部に配置されており、アイテム選択を除けば上部での操作はあまり発生しない。だから上部ボタンのコストが多少高くなっても下部ボタンを最小コストで押せる持ち方が望ましい。

これはかねてからの俺の持論なのだけど、スマホにおける片手操作のスイートスポットは画面の下半分～1/3程度の場所にあると考えている。
重心を中央に置いて画面上部を押しやすい持ち方をするとどうしても自分自身の手で画面を隠しがちになるし、画面が隠れないように持つと親指は画面下部あたりに優れた稼働特性を持つことになる。
特に理由がないなら、画面の下の方で親指をチョコチョコと動かして操作し続けられるのが一番快適なはずだ。
まあフィッツの法則とかいう奴に合致するよう作ると自ずとそうなる。

Honeycombより前のAndroidでもあからさまに上記法則に反しているものがある。みんなあの操作は大嫌いなはずだよ。
そうそうあれだよあれ。　「通知バーの引きずり下ろし操作」だよ!
あの操作がかったるいのはきちんと駄目な理由があるってことだ。

まあつまりどういうことが言いたいかというとだね

ActionBarに置くボタンは滅多に押さないボタンだけにして、よく押すボタンはSplitActionBarに置け、ってことかもしれないけど、それだと画面がせませまですお

ぐぐるTVが面白そうだったので講演の雑感。

これだけGC様のご機嫌を伺いながらトリッキーなコード書かされるとC++の方が生産性高いんじゃないかと本気で思うことがある

以前のエントリでパーミッションって細分化されればされるほど人力で見るのがきつくなる代わりに機械は読みやすくなるって言ったでしょ。パーミッションをチェックするサポートアプリが作りやすくなるよ、とも。
それってもっと進めて考えると、その機能がAndroid Marketそのものに内蔵されてていいわけ。
パーミッションのゴールってここのはず。

ちょっと難しいのはGPSあたりだね。
地図アプリとか乗り換え案内アプリとかだとGPSって必要。これはstandardなユーザでも欲しい。
かといってよからぬ使い方が出来ちゃうのもGPSで、カレログ騒動は言うに及ばず、Android以外でもGPSは無法地帯筆頭になってる(ほんの半月前までは無法地帯筆頭はUDIDだったけど)

ここがねー、難しい。一応考え方としては、特定のカテゴリでだけGPSパーミッションを持つアプリをstandardから可視にする、みたいなのが基本になる。例えば「アプリ→交通、旅行」でだけGPSをstandard可視にする、みたいな感じね。
でもこれだと乗り換え案内アプリくらいならいいけど、例えばマクドアプリで一番近所のマクドを探すとかなんて機能がstandardユーザに提供できなくなっちゃう。ちょっと寂しい。
余所もGPS周りがグダグダになってるのって利便とセキュリティの落としどころが難しいせいだよね。

とするとGPSのパーミッションを2つに分けて、「GPSがONならアプリ側が任意のタイミングでGPSを使えるGPSパーミッション」と「測位の度に確認を出さないと使えないGPS」を作っちゃうとかかなぁ。地図アプリは常時測位してないと困るけど、マクド探しとかは後者で十分なはずだから地図絡みのカテゴリ以外では後者を使わせる。これで裏で測位されることは無くなる。
うーん、でもなんかぱっとしないね。何かいいアイデアあったらGoogleに教えてあげて。

あとは例によってインターネットとSDカードなわけだけど、ここはもう細分化するしかないね。
情報本体へのアクセスをきっちり統制すればインターネットの方はある程度緩やかでも何とかなりそうだけど、SDカードはほんと現状ヤバイ。Androidのセキュリティで一番ヤバイのどう考えてもSDカードだよ。
本家でもissueにはなってんだけどもっとユーザから声を上げるべきだと思う。

それ以外については概ね適切に区分されていると思うし、standardならサーチ不可、expertにすると解禁、でいいんじゃないかな。
あとはGoogleが明らかに身元を保証できるようなメーカーやキャリアやそれに準ずるような企業に対してだけ、Googleがきっちり契約結んだ上で強力なパーミッションを使っていてもstandard可視にする、ってのはありかもね。

ここまでやると、もう人手で審査するとかは出る幕無くなる。人力の審査ってUIガイドラインへの準拠とかをチェックする(いわゆる「クオリティを上げる」)のには良いんだけど、セキュリティ的にはあんまり役に立たないんだよね。どんなシステムでも人力でやるのに向いてるものと向いてないものがあるわけよ。
まあがっつり「解析」すればより踏み込むことも出来るけど、それをバイナリ提出されるたびに全アプリに対してやると審査の人件費で年間何億ドルみたいな世界になりかねない。現実的じゃない。

これ以上踏み込んで規制したいなら結構な犠牲がいる。てゆーかまあ要するに、Googleのパートナー企業以外出品不可、とかになる。この場合でも個別のアプリを審査する必要はない。企業に対していつでもGoogleが訴訟起こせる状態にしておけばいい。
ガラケーがこういう枠組みでやってて、別に個別のアプリが不審な動作してないかとかチェックしてないけど安全なのはそういうことだね。
ただねぇ、これやると法的に拘束しにくい発展途上国の人(例えば中国人)はアプリ公開が困難になっちゃう。保証金でも積ませればいいのかもしれないけど、途上国の人に1万ドル積んで下さいみたいなのも無茶だよね。
Android以外でもそうなんだけど、国際展開しているアプリマーケットだとこういう法的拘束力を担保に安全を保ちましょうみたいな枠組みはちょっと難しい。そこはある程度割り切るしかないんじゃないかな。
日本限定で法人登記なり公的身分証明を前提とするなら別建てのものを日本ローカルでやるのは可能。つまりドコモマーケットとかau one marketとかだね。でもグローバルに適用できる手法じゃあない。

えーと、うん、まとめ。
GoogleはAndroid Marketにパーミッションによるフィルタリング機能を追加して、デフォルトでフィルタリングONにするといいんじゃないかな。
そんだけ。

にわかに話題になっていますが、「どういう時に何の情報が抜かれるのか」が分かっていない人がかなり多そうなので簡単に解説。

(*最後に追記しましたが、仕様が追加されたので以下の問題・攻撃シナリオは(恐らく)解消したと思われます)

・一般のアプリが無許可でIMEIを抜くこと
IMEIへのアクセスにはREAD_PHONE_STATEという許可が必要で、アプリインストール時に許可を取っていないとIMEIにアクセスした途端にアプリがエラーで落ちます。ユーザがREAD_PHONE_STATEを承認しなければ抜けません。
(ただしREAD_PHONE_STATEの説明文が分かりにくいとか、承認範囲をもっと細分化すべきといった指摘はあります。とりあえず今回の問題とは別です)

(追記)ドコモのアプリがインストールされていると、それを踏み台にすることでREAD_PHONE_STATEを無視してIMEIが抜けるという指摘を受けました。その手法を取ればIMEIは抜けます。

・ドコモ製メディアプレイヤーがインストールされていないAndroid端末でウェブアクセスしてきた人のIMEIを抜くこと
本件はドコモ製メディアプレイヤーの仕様バグですので他のAndroid端末は無関係です

■ドコモ製メディアプレイヤーの仕様バグ(セキュリティホール)とは何か

件のメディアプレイヤーは、(ドコモ以外の)外部サイトにアクセスする際、HTTPヘッダにIMEI(端末固有番号)を問答無用で付加して送ってしまう仕様です。
このメディアプレイヤーはOSの制限としてインストール時にREAD_PHONE_STATE承認が必要になるわけですが、困ったことにプリインストールなので出荷時点でドコモが勝手に承認してしまっていることになってしまいます。

■どんな「悪さ」が出来るか(情報漏洩編)

Androidのブラウザアプリは(当然)IMEIを送ったりはしないのですが、ドコモの仕様を見る限りデフォルトで音楽や動画の関連付けがドコモ製メディアプレイヤーに設定されていると考えられます。
つまり、悪用法はこうです。
悪意あるサイトは、Androidでサイトにアクセスされた時に、音楽コンテンツのURLにforwardします。これによりドコモ製メディアプレイヤーを起動しそのURLにアクセスされる(ここまではまともな動作である)わけですが、ドコモ製メディアプレイヤーがHTTP通信する時にヘッダにIMEIを付けて送ってしまう欠陥が存在するため、サイト側はそのアクセスを記録することでIMEIを回収することが出来てしまうわけです。

■どんな「悪さ」が出来るか(なりすまし編)

ドコモはIMEIを使って「悪意のないサイト」に何をさせたかったのでしょうか。それは恐らくガラケーでよくある「簡単ログイン」を意図したものであると思われます。しかしこれは意図そのものが既に重大な欠陥を抱えています。
実はAPIから見える(*後述)IMEIは端末側で変更可能ですし、そもそもhttpヘッダである以上は俺俺Proxyを立ち上げて書き換えることも容易なんです。
しかるにこの欠陥は以下のように悪用可能です。
・まず「情報漏洩編」の手法で他人のIMEIを回収する
・次に「IMEIによるかんたんログイン」を使用して(しまって)いるサイトに対して、盗んだIMEIを自機に設定してアクセス
・その人の権限でアクセスできてうめえｗｗｗｗ
この問題が存在するため、善意のサイトではIMEIを利用しようがないのです(利用するとサイトにセキュリティホールが出来てしまうため)

■つまり?

このメディアプレイヤーのIMEI送信仕様は、悪意あるサイトには多大な利用価値があり、善意のサイトには何の恩恵もない、という壮絶に頭の悪い代物であり、全くのゴミです。

■ユーザサイドの対応策

・ドコモの端末を買わない(あくまでドコモ製プレイヤーの問題であるため)
・ドコモ製メディアプレイヤーをアンインストールする(が、恐らく正常な手法では削除できないと思われる)
・ドコモ製メディアプレイヤーの関連付けを解除し、起動ダイアログが出ても絶対触らない
・ドコモ製メディアプレイヤーの代わりに別の(ダミーの)アプリを関連付けてしまう

3でもいいが単純な解除はできないかもしれません。
4の手法なら恐らく可能で確実性も高いと思われます(実物見ないと分からないですが)
ドコモのプレイヤーと同じIntentに反応する無害なアプリを作ってそれをデフォルトにしてしまえば、勝手に起動することも、起動しようと確認ダイアログが出ることもない......はず。

(追記)
指摘があったので追記。
3/4の方法は悪意のある「サイト」からの攻撃は防げますが、悪意のある「他のアプリ」からの攻撃は防げません。
つまり、悪意あるアプリがREAD_PHONE_STATEを持たないと思って油断してたら、そこからドコモ製メディアプレイヤーを直指定でキックされてしまうと、(悪意あるアプリの作者が管理する)悪意あるサイトにアクセスされてIMEIが抜かれる、という多段式のやり方です。
本当にどうしようもないアプリです。胴元が馬鹿だと手の打ちようがない。

■これはどの程度の「危なさ」なの

これをもって「Android"が"危ない」と勘違いしている人が多いので補足しておきます。

端末またはユーザ固有の番号が確認無しに送られてしまう問題は一般のガラケーに共通する欠陥として既に広く知られています。ガラケーの特性上成りすましはしにくいですが、デフォルトのブラウザで送りまくるためプライバシー問題は完全死亡です。

iPhoneの場合、ブラウザからのアクセスは安全ですがアプリの方でiOS4までUDID(端末固有番号)が確認無しで取得可能で、「悪用禁止だからな!!悪用禁止だからな!!」と言われながらかといってこれで審査落とされません。あまりに悪用されたため遂にiOS5から使用禁止になりました。
ソフトバンク製アプリがUDIDをかんたんログインに使って成りすまし放題になり、高木先生に突っ込まれまくったのも今や懐かしい思い出です。

Androidの場合、ブラウザからのアクセスは安全で、アプリの方もOS1.6から確認が必須です。
ところがこの確認はプリインストールのアプリに対しては適用外なので、「ドコモが」致命的なセキュリティホールを持つアプリをプリインストールしてしまうなどという状況は想定外です。
この結果、ガラケー脳丸出しのドコモのせいで、ガラケーどころか成りすませるだけガラケーよりなお悪い、という素敵な状況になろうとしています←いまここ

ドコモ担当者の方は、何故Android端末でアプリがIMEIを取得するのにユーザに承認を必要とするのか考えて下さい。先人の失敗を繰り返さないためにわざわざ施された布石を見て、なんか邪魔なものがあるからどけよう、としか思わなかったのですか?
まだプリインストール端末がリリースされていないので、今のうちに仕様が変更される必要性を強く訴えます。

(更に追記)
(Q)IMEIって変更できるの?
(A)ハードウェアに記録されているIMEIを書き換えることは(通常は)困難です。
しかしメディアプレイヤーはAndroid FrameworkのAPIを介して取得しているわけですから、ベースバンドが返すIMEIが変更できなくとも、rooted端末やカスタムROMでAPIが嘘のIMEIを返すようにしてしまえば事足ります。
こうなると古いiOS JB端末のUDID偽造問題と同程度まで落ちてしまいます。
もっともドコモの仕様を見る限りAPIを騙すよりHTTPヘッダを透過Proxyなどで改変した方が話は早そうですが。

(10/20追記)
先ほど

ただし、PlayReadyRのライセンス取得を行う通信では、以下となります。（ライセンス取得には、都度ユーザの許諾が必要です。）

以下長文なので引き返すなら今だ。

まあ実を言うとだね、ネットワークを使用するアプリはまず多かれ少なかれあなたをトラッキングしてる。AdSenseにしてもGoogle Analyticsにしてもまあ何にしても。
これはブラウザのトラッキングクッキー並くらいに留めるのが良心的なやり方なんだけど、まー結構線引きギリギリだよね。一歩踏み外したらIMEIとか電話番号とかメールアドレスとかに行っちゃう悪い子もいるし、そういうのってAppLogみたいに自分からいちいち取ってますとか言わないもん。

それはそれとしてAppLog的なるものに戻るけど、ちゃんとやるなら結構良心的な部類だと思うんだよね。
この辺の「乞食向けアプリのマネタイズ方法」としては古典的には、オプトインでメールマガジン(と称する要するにSPAM)に同意させるとか、ブラウザにスパイウェア(JWORDとか)を仕込むことを同意させるとかいうのが「合法な」手段として確立している。でもこれってかなり「うざい」よね。そういう意味ではAppLogのように統計情報の提供というのはある種の視聴率調査みたいなものでダメージは比較的少ないし楽な方だと思う。
ああ返す返すもちゃんと同意取ってたらの話だよ。ここ誤読されたくないから何度も言います。

逆に、AppLogくらいの「ぬるい」取り方の情報でどの程度金になるのか?という点の方が気になるんだけど、その辺何か目途は立ってたんすかね。
で、こういうのがちゃんと軌道に乗れば、少なくとも秘密裡に情報抜いてマネタイズしよう、という奴らをギリギリ合法の世界に押し返すことが出来る。だってAppLogだか何だかに任せれば違法なことしなくても乞食向けアプリで開発費が回収できることになるわけだから。そういう意味ではJWORDなんかも社会的な意義はあった(あ?俺?JWORD入りアプリなんて使うわけねーだろ。乞食用だってばよ)

じゃあ何が本質的問題なのかというと、要するに「ユーザの意思に反して」やること。何が悪ってこれが悪。
AppLogについてはなんつーか、純粋に間抜けなだけだと思うんだよね。だって本当に悪さする気があったら最初からこっそりやるもん。技術があまりに未熟で、企画があまりに未熟だった。とてもじゃないけど個人情報なんて劇物で合法に火遊びできるような能力をミログ社は持っていなかった。これ自体は批判されて然るべきだけど、でもそれは「お前は馬鹿だ」であって「お前は悪党だ」とは違う。ああ、まあ、事後対応が不誠実だったってのも問題だけど。
むしろ深刻に問題なのはapp.tvの方でこっちはほとんど弁護の余地がない。
AppLog問題を語る人の少なからずがこの辺の区別が出来ていない=根本的に理解していないのは頭の痛いことだ。
そしてもっと頭が痛いのは、app.tvみたいなアプリがスマフォ界ではフツーにはびこってるので、app.tv単体の問題に矮小化しても事態は悪いままってことなんだけどね。

技術的な話に移る。AndroidはOSとしてどうあるべきか。

根本的にこの問題はスマートフォンなら必ず付いて回る問題。
でもって解決法なんだけど、まずバイナリに対して静的な審査で何とかするとかいうのは論外。これはもう技術的に無理。そんな静的監査があったらプログラミング界の賢者の石だよ......。で、それで何とかなると(非技術者には)思われている某フォンについては横に置こう。
なので真っ当なメカニズムを考えるんだけど、とりあえずどう転んでも必要になるのが動的なAPI監査いわゆるサンドボックス化。まあくだけた言い方をするとOSレベルでセキュリティソフトが内蔵されてるようなもんだね。不正な動作は究極的には実行時にブロックするしかない。

Androidでは既にサンドボックス化は行われている。これ「Javaだからサンドボックスなんだ」と思ってる人が時々いるけど、ネイティブ処理も含めて全部サンドボックスの保護下にあるよ。ネイティブコード書けばパーミッション突破できるんじゃ意味ないからね。
ところがこのサンドボックス、他の例えばiアプリとかと比べると結構ユルい。いや禁止された処理が出来ちゃうって意味ではないよ。そこはちゃんと堅牢。問題は、禁止されてるんだけどユーザの許可(パーミッション)を得れば出来てしまうって処理が結構ヤバイもの多くて、しかもその許可の取り方が非常に大味なことにある。
まあこの辺、許可さえ取ればヤバイ処理も出来てしまうってのはスマフォという特性上仕方ない面もある。そういう強力な便利アプリが使えなきゃガラケーでiアプリでいいじゃんって話になっちゃうからね。

で、パーミッションが大味な問題なんだけど、これは結構テキトーな作りになってる。インターネットの使用許可と言ったらサーバにもクライアントにもなれるしどことも通信出来てしまう、3G通信の状態を取ろうとするだけで電話番号まで取れるような許可を出さないといけない、SDカードアクセスは書き込み許可を出すと全領域許可になりしかも読み出し不可にする設定が出来ない、などなど。なんかもう深く考えて設計されたんだろうかという疑問を禁じ得ないところが散見される。プロセスリストが取れちゃうのはUNIXだと結構仕方ない気がするけど......。

特に問題とされているのはインターネットの使用許可があまりにall or nothingすぎること。開発者の間でも昔からGoogleに要望上がってるネタとして、通信先に応じて許可不許可を出せるような仕組みにして欲しいってのがあって、平たく言うとパーソナルファイアウォールを搭載(っつかLinuxに内蔵されてるのを有効化)してそれをパーミッションシステムと連結してくれたらサイキョーじゃんって話なんだけど、なんかずっと黙殺されてる。みんなも騒ごうぜ。
これがあると、twitterアプリなのでtwitterサーバとだけ通信→セーフ、広告入りFacebookアプリなのでFacebookサーバとAdMobサーバとだけ通信→セーフ、mixiアプリだけどmixiサーバと良く分からない中国のサーバに通信→アウト!!、みたいに出来るんだよね。

他には実は、アプリが他のアプリに対してパーミッション付きで機能を公開するって機能があって、これはすごく強力な機能なんだけどイマイチ使われてない。
これだと例えば、Google謹製のAdMobアプリを端末に1個だけ入れて、AdMobアプリはネットワークの使用許可を取り、かつAdMobアプリは「広告の表示」というパーミッションを(他アプリに対して)パーミッション付きで公開、AdMobを利用するアプリはネットワークの使用許可を「取らず」に、AdMobアプリに対する「広告の表示」というパーミッションで確認を出す、みたいなことが出来る。
これだと何が嬉しいか。AdMobアプリがGoogle謹製ってとこだけ確認しておけばAdMobアプリの通信はまあ信用できるよね。一方AdMobの広告を表示するアプリの方はGoogleと比べれば信用度は落ちるのが実情。でも上記方式だと「AdMobアプリ経由で広告を取得する」許可しか出さないので、アプリの挙動としてAdMobサーバとしか通信しないことを保証できる。そしてアプリは悪いことしてませんという潔白を示せるわけだ。

ただこれ結局使われてない。多分今後もあんまり使われないと思う。MOTTAINAI......。
使われない理由としては、まず別途AdMobアプリを(最初の1回だけとはいえ)インストールしないといけないこと、これは今のAndroid Marketのメカニズムとして「このアプリが必要なので先に入れてね」という依存性解決が出来ない(1個ずつ明示的にインストールすることしか出来ない)こと。
早々にインターネットアクセスを求めるアプリが氾濫してしまい、インターネットアクセスを求めるアプリが忌諱されないような文化が出来てしまったこと。
この辺が挙げられると思う。うーん、残念。

パーミッションを細かくしすぎると見るのがきつくなるって意見もあるんだけど、それって実はあんまり本質的じゃない。
何故かというと、パーミッションが細分化されればされるほど、ヤバいパーミッションは機械的に判断付くようになるから。動的監査項目に対して静的チェックが出来る、みたいな。
つまり、平たく言うとパーミッションを大ざっぱに眺めて「この組み合わせやばそうだよ」とか「この通信先の中国のサーバ、ブラックリストに入ってるからアウトだよ」とか「このアプリは電話帳アクセスするけど有名なアプリで署名もあってるから大丈夫そうだよ」とかをチェックしてくれるようなサポートアプリが簡単に作れるようになる。
っていうか実は今よくあるAndroid用のセキュリティアプリってまさしくこういう動作をしているんだけどね。あれって平たく言えば「あなたの代わりにパーミッションを確認してくれるアプリ」だよ。

長々と書いちゃったけど総括。
AppLogについては「あんな難しいサービスは馬鹿には無理」というのが俺的結論。ただ、(セキュリティの専門家が懸念することも分かるけど)個人的にはビジネスとして「ユーザを騙さない」という鉄則を守るのならば、有意義な(少なくとも必要悪の)サービスとして許されるべきだと思う。
Androidのセキュリティ機構については開発者の間では常識的な話だけどざっくりと書いてみた。まあ一応サンドボックスはあるしそれなりに頑張ってる機構ではあるんだよ。Marketがあれだけフリーダムなのに実被害の事例がほとんどないとか、BlackHatでの報告で審査のあるはずの某Storeの方が倍ほど酷いとかは、まあ今の仕組みでもそれなりの防御にはなっているということではある。
一方でじゃあAndroidのセキュリティ機構が十分かというと正直まだまだ上が狙えるはずなのも確か。そして問題点に対してGoogleの動きもイマイチ鈍いことも確か。エンドユーザ各位におかれましては、Marketに審査を導入しろみたいな愚かなことを主張するのではなく、パーミッションをより徹底的に細分化すべきであるといった方向で騒いで頂ければ幸い。

おまけ。
上記ではフレームワークレベルの話しかしてないけど、実はシステムにバグがあった時に任意コードの実行に繋がりやすい問題についてはAndroidはあまり優秀ではない。というかだいぶ悪い。最近はちょっと改善してきてるけど根本的にメモリ節約機構が権限昇格耐性低い構造になってる。
この辺はえらい人の講演がトゥギャられてるはずなので興味ある人はググってちょ。
そういえばWindows8でも重複メモリ節約機構が入るらしいけどどうやって問題を回避してるだろうね(もしくはそもそも回避していないのか)

(追記)
なんかiPhoneに喧嘩売ってるみたいに取られたので蛇足な記述を削除。
審査が無意味であるという考え自体は変わってません(というか色々話を聞くとその確信は深まった......)

それとAndroidでは、現在実行中のプロセスを取得する、という処理をするアプリはインストール時に確認が出ます。AppLogなりapp.tvなりでもインストール時に怪しい確認は出ます。「Androidの」セキュリティホールだと思ってる人がいるようなので一応追記。
むしろ許可項目ゼロで通報君Zが作れてしまうことの方が実はAndroid的には問題だったりする......。インストール済みアプリの一覧は許可なしに取得できてしまうんだよね。

このため、Honeycombアプリでは以下の3通りの対応から選択する必要がある。
(1)ActionBarを必ず表示する
(2)ActionBarを非表示にした画面ではOptionsMenuを使わない
(3)targetSdkVersionを11以上にしない(SystemBarにMenuボタンが出る)
各所でも(3)のwork aroundが公然と勧められている。
Honeycomb APIの重大な失敗の一つに数えて良いだろう。

ださい。

intent.setFlags(Intent.FLAG_ACTIVITY_SINGLE_TOP);

protected void onNewIntent(Intent intent)

1つのアプリが複数の種類のIntentを持つ場合、notifyの第一引数(int id)によって区別される。

PendingIntentを更新したい時はPendingIntent.getActivityの第4引数(int flags)にPendingIntent.FLAG_UPDATE_CURRENTを設定すると同じidの通知を上書き出来る。

intent1.putExtra("id", 1);
PendingIntent pending1 = PendingIntent.getActivity(... //intent1をセット
Notification notif1...//notif1にpending1をセット
notif_manager.notify(1, notif1);
intent2.putExtra("id", 2);
PendingIntent pending2 = PendingIntent.getActivity(... //intent2をセット
Notification notif2...//notif1にpending2をセット
notif_manager.notify(2, notif2);

こうすると、通知ID1と2の通知が作られて2つの通知が表示されるが、pending1とpending2は同じものとみなされてpending1の情報は2で上書きされてしまう。このため、通知1も2もpending2が起動されてしまう。
なんだそりゃ。

解決法。
putExtra以外で区別できる情報を付けてやる。
具体的にはIntentにsetDataで異なる(IDを含むダミーの)Uriをセットしてやると区別してくれるようになる。
同一性チェックにExtraも使っていると思っていたので結構はまってしまった。
考えてみればここには様々なObjectが入る、つまりequalsが実装されているものしかないとは限らないわけで、仕様としては分からんでもない。どっかに書かれてるのかもしれないけど見つけられなかった。

以前こんなエントリを書いたわけだけど、大体Honeycombの概要が表に出てきていて、その次のIceCreamの話題も出てきているので俺内中間反省会をしてみる。

ほぼ外れ。
厳密に言うとHoneycombはタブレット限定というわけではなくメーカー判断でスマートフォンに搭載することも当然ありなわけなんだけど、今のところ出てきている情報ではGoogleはスマートフォンについてはHoneycombを載せずにGingerbreadで待ってIceCreamまで飛ぶことを推奨するようなので、まあ外れと言っていいかな。
俺の見立てでは、新APIに合わせてタブレット・スマフォ両対応の標準アプリをHoneycomb時点でリリースがプラン1、タブレットのみ先行対応した標準アプリをリリースしスマフォ向けには旧標準アプリをそのまま添付して選択式にしてHoneycombとするのがプラン2、で進捗が遅れてもプラン2かなと思ってた。
Honeycombも2.x以下のアプリはそのまま上位互換とされているし、Gingerbreadで待たせるまでもなく上記プラン2の方がメンテ効率も良いはず。

そうなっていないのはそれなりの理由があると思われる。まぁ、Honeycombの完成度が相当低くて不安定だとか上位互換に問題が残っているとか、そういうことなんだろうと予想する。それでもタブレットでGingerbread動かすよりは標準アプリの強化の分だけ良好なエクスペリエンスになるが、スマフォではそれなりに安定したGingerbreadを使った方がマシ、なのだろう。

その間を埋めるために出てくるのが恐らくStatic Fragment Libraryで、結果的に見れば穏当なマイグレーションプランを選んだとも言えるかもしれない。

この辺の予想が外れたのは俺が想定していたよりもGoogle内でHoneycombの進捗が思わしくなかったのだろうなと。

■Honeycomb新UIに関する予想
◆OSの根幹部分は完全互換で共通となるであろう

これは当たったというかなんというか。当たり前のとこしか当たってないというか。
当時GIZMODOなんかは2.xと3.xが別々のブランチになるとか言い張ってたけど、もちろん技術者視点で見ればそんな展開あるわけないのは自明で、それ以上でもそれ以下でも無かったな。

◆標準アプリはブランチするのか　→　予想「しない」

これはまだ確定ではないけど多分当たってると思う。
Fragment APIが出たので1ソースでスマフォとタブレット両対応した統合リリースにしてくると思われる。ただその統合時期はIceCreamということになるけど。

■新API予想
◆マルチカラムUIのための新Activity機構
◆シングルカラムUIとマルチカラムUIの単一ソース管理

Fragment APIがまさにそれだけど、これは当たって当たり前のものが当たったくらいかな。まだFragment APIを細かく追ってないのでどの程度使い勝手がいいのかは分からない。

■予想される問題
新APIが3.0以上になることで2.xとの間に重大な非互換が発生するのではないかという懸念があったのだけど、Static Fragment Libraryがリリースされるようなので何とかなりそう。
これは俺が想定していたよりも良い対応で、逆に言うとこれが出るのならAndroid 3.0標準の新APIを使う意味ってどんだけあるねんという疑問すら沸く。

そこで、どの部分で落ちているかを追ってみたわけですよ。

意味わかんないのでAOSP最新ソースを追ってみました。
PreferenceActivityを初期化する時にListPreferenceのgetSummaryを呼んでSummaryの表示内容が更新されています。
ところがなんとListPreferenceのgetSummaryには既にsetSummaryされた文字列をString.formatのフォーマットと見なして第一引数にgetEntry()の内容を渡すというロジックが既に存在していたのです。
これは明らかにおかしい。
公式ドキュメントによるとListPreferenceのgetSummaryはオーバーライドされておらずPreferenceからそのまま継承されていると明記されているし、そもそもformat文字列とstatic文字列は全く別物であり混同することは厳禁である(インジェクションの元になる)ものなのだから、俺はたいそう混乱しました。

ちなみに、getEntry()を差し込んでくれるのは初期化時だけで設定変更時に反映してくれないという驚くべき糞実装で、これを見た瞬間に俺は支配人を呼べとtweetしたんですが、他の点でもっと論外すぎたので今となってはどうでもいいです。

さて、とりあえず公式ドキュメントが古くてコードが正しいのだろうと、AOSPコードに合わせてTuboroidを修正してみたわけですよ。
ところがですね、Honeycombエミュでちゃんと動くようになったかと思ったら、Gingerbreadエミュでは公式ドキュメント通りの動作をしてしまって思うように動作しないんですね。
すごく嫌な予感がしますよね。

AOSPのヒストリを追ってみました。
このパッチは2010/07/13にmasterにコミットされていました
いやちょっと待てよ、ますますおかしい。まず第一にこんな糞非互換パッチが半年も前に平然とコミットされるとかレビュアーは何をしていたんだということ、第二にGingerbreadより遥かに前なのに何故Gingerbreadエミュには入っていないのかということ。
更に追うと、Gigerbreadのツリーにはこのパッチは含まれておらず(ハァ?)、またエミュのListPreferenceをリフレクション使って探ってみたところgetSummaryはListPreferenceでオーバーライドされていない(=パッチが含まれていない版でビルドされている)ことが分かりました。
更にHoneycombエミュでも同様にリフレクションで探ってみると、こちらは確かにListPreferenceでオーバーライドされていました。つまりパッチを含む版でのビルドでした。

Nexus Sでも、またCyanogenModでも、このパッチはどうやら意図的に外されているようで、ListPreferenceでのオーバーライドは有りません。
ただ、当時のCyanogenModでmasterを取ってきてしまったせいかこのトラップを踏んづけてIssue投げられた形跡が有ります。
現在のCyanogenModでは外されているようです。

つまりこういうことなのでしょうか。
この非互換の糞パッチはレビュアーの目をかいくぐって半年前にmasterにコミットされ、当時のCyanogenModにIssueを発生させるという被害を出しました。
ところが何故か(......まあ糞パッチとみんなが気付いたのでしょうが......)この糞パッチはエミュでも実機でもリリースバージョンには含まれませんでした。当時は2.2がリリースされたばかりでしたが、2.2にも2.3にもブランチに含まれていません。
公式ドキュメントでもこのパッチは完全に黙殺しており、パッチのない状態でドキュメントがリリースされています。
ところが今の今になってHoneycombをビルドした際に、恐らく特に疑いもなくmasterからビルドしてしまったのでしょうね、この忘れ去られた糞パッチが混入してしまったのでしょう。

結論。
Googleはmaster上からこのパッチをrevertすべきだと思います。

ほんとは
Android " Honeycomb " はデュアルコアのタブレット限定、既存製品からアップグレード不可？
この記事を誤報ではないかと大予想してやろうと思ってたんだけど
Android 3.0 Honeycomb に必須プロセッサ要件なし、開発者が証言
俺がブログに書く前にGoogleの中の人に否定されて誤報確定してしまった。ちぇ。

以下、繰り返しになりますが内部情報とか全く持ってない一般のAndroid開発者・ウォッチャーの意見です。

その理由
(1)ブランチする利点が見当たらない
　タブレット用とスマフォ用にブランチするとGoogle側の開発コストが大幅に増大する。また、もちろん開発者側のコストも増大する。
　Honeycombの「タブレット向け新UI」部分はコード全体で見ると極一部であり、恐らく98%だの99%だのが結局共通になる。つまり、同じコードベースでビルドオプションとしてタブレット向けとスマフォ向けの切り替えを行う方が簡単である。

(2)既にGingerbreadにタブレット向け対応が入り始めている
　「Honeycomb=タブレット専用説」では「Gingerbread系列」がスマフォ専用となるとされているが、実のところGingerbreadで既にタブレットを想定した対応が追加されている。具体的には従来7インチまでの対応だったマルチ解像度対応APIが10インチ強まで拡張されている。このためGingerbreadはスマフォ専用ではなくスマフォ・タブレット両対応のOSのロードマップ上にいると考えられる。
　ちなみに俺的にはHoneycombでは13～14インチ(xx-large?)まで拡張されると予想している。

(3)先月、Andy Rubin神がHoneycombは両対応であると明言している
　ここ1か月でブランチが決まったとするとロードマップは破滅的な変更に見舞われたはずで、逆説的に考えると順調に進んでいるHoneycombの状況から見てそんな激震が起こったとは考え難い。

(4)総括
　以上から、GingerbreadとHoneycombは単一のロードマップ上に位置しており、Gingerbreadは単にHoneycombの前身である、と予想する。
　経緯から見てもGingerbreadでの更新内容から見ても、開発が遅れたため先行リリース出来る部分だけ切り出してGingerbreadとしてリリースし、(本来Gingerbreadとして出すつもりだった)Honeycombを後から出す、という流れと考えた方が自然だと思われる。

■Honeycomb新UIに関する予想
(1)アプリ単位での対応である
　動画で新ホームや新ブラウザや新Gmailが出てきているが、これらは元々OSそのものというよりバンドルされた単なる標準アプリである。
　恐らく多くの標準アプリが新UIに合わせてリライトされるが、OSの根幹部分は完全互換で共通となるであろう。

(2)標準アプリはブランチするのか
　これらのアプリの作り方は2通り考えられる。
　1つはスマフォ用アプリとタブレット用アプリを別々に開発してどちらかを標準バンドルするという形。これはつまりOS基幹部は共通であるが標準アプリはブランチするということになる。
　もう1つはスマフォ用もタブレット用も単一ソースで開発してビルドオプションやリソース設定で切り替えるという形。iPhone/iPadで言うところのユニバーサルアプリに似ている(それにしてもこの呼び方はどうかと思う......)

　「Androidらしい」のは後者であると考える。
　多解像度対応などで単一ソースのリソース切り替え対応というのは今でも常套手段である。各アプリもUI部分を除けば内部処理はどうせ共通のはずでブランチして2倍のメンテコストが掛かるより、ユニバーサル化して1.2倍くらいのメンテコストになった方が幸せである。
　標準アプリはAOSPベースでも30個くらいあるのでこれを全部ブランチして二重メンテする愚は犯さないのではないだろうか。
　また後述の新API予想にも関係する。

■新API予想
　これはGingerbreadの予想を書いた時の蒸し返しになる。

(1)マルチカラムUIのための新Activity機構
　これは今度こそ必須になる。現在のActivity機構では新Gmailのようなアプリは(シングルカラムアプリが楽勝なのと比べると)作りにくい。
　これはActivity機構の根幹に関わるため、大幅な強化が来ると思う。というか、来てくれないと即ち「力技で書いてね☆」という意味になるので、アプリ開発者としては大変困る。
　現行でも複数のActivityを管理する(タブなどで使われている)ActivityGroupというクラスはあるが非常に使いにくいので、マルチカラムを「ちゃんと」管理するためのActivity機構は必須であると思われる。

(2)シングルカラムUIとマルチカラムUIの単一ソース管理
　上で述べた標準アプリを単一ソース管理する場合、Activity部分のソースを二重管理するというのは筋が良くないしAndroidらしくもない。賢明なGooglerの皆さんがそのような愚かな管理方式を採用するはずがない(ことを期待する)
　どうせActivity機構に新流儀が出来てしまうとどうせUI周りはリライトになる。となるとシングルカラム・マルチカラムを単一ソースで管理するなら、Activityを別々で用意するより、layout xmlで切り替えられるレベルまで統合されている方が開発効率は良くなる。何よりその方がAndroidらしい。
　きっとAOSPの標準アプリのMailあたりを見るとヒャッホーって感じになってくるに違いない(ことを期待する)

■予想される問題
　上記予想が当たった場合、タブレット・スマフォ両対応アプリを書くために、従来なら1.6以上対応として開発されていたようなアプリまでが新規開発だと3.0以上対応(3.0未満切捨て)になるケースが増えてくると思う。となると3.0未満端末は色々と不幸な目に遭うかもしれない。
　まあスマフォでは1.6の切捨てもまだ進んでないくらいだし、3.0未満まで切捨てになるのはスマフォでの3.0シェアが最低8割は超えてからになるのだろうけど。
　......というかその場合、過渡期の開発者は色々めんどくさいことになるね。

半年ほど前の蒸し返しになるけど、Androidのタスク管理について。もうあんまり内部の細かいこと書いても分からないだろうから書かないよ。

■何故TaskKillerを使わない方が良いか
Androidでは一度起動したプロセスはなるべく再利用しようとする。これは重い起動処理をなるべく減らすための一種のキャッシュである。
一旦終了してしまうと起動からやり直しになってしまうし、2.2以降ではせっかくコンパイルしたJITキャッシュも全部ご破算になってしまう。ブラウザのキャッシュをしょっちゅう消しまくるようなものだ。

プロセスリストにプロセスが残っているとバッテリを食っていると思う人がいるが、リストに載っていても処理がない限りプロセスは止まっているしバッテリも食ってない。この点に関する勘違いが一番多い。
バックグラウンドでも処理をするアプリは一部にあるが、普通は必要な処理だけ時々起きてまた寝る、というような動作をするようになっている。

一方、バックグラウンドに回ったのに処理をちゃんと止めないとか、電波を出しっぱなしにするとか、そういう「お行儀の悪い」アプリも一部には存在する。これは要するにバグであり、たいていコメントでぼろくそに書かれている。とはいえ最近は開発者にノウハウが普及しているのでそこまで酷いアプリはかなり稀になった。

またメモリが非常に少ない端末では新しいアプリが立ち上がると古いアプリがどんどん終了されてしまう。これ自体は正しい挙動なのだが「ホーム」もアプリであるためこれが終了するとホームに戻る=ホームアプリ起動になって非常に遅くなる。これに対してホームが殺されないために別のアプリを先回りして殺してしまうという手法が(昔は)あった。

TaskKillerを使うと損な点
・タスク切り替えが毎回起動になるためかえって遅くなる
・更に2.2以降ではJITキャッシュが頻繁に捨てられてしまってかえって遅くなる
・TaskKillerそのものがプロセスであるためメモリとCPU時間を食う
・まともなアプリの寝ているプロセスで動作速度は下がらないし、殺しても上がらない

TaskKillerを使うと得かもしれない点
・運が良ければバックグラウンド処理の腐ったアプリを殺してくれることがある
・メモリが非常に少ない(旧世代の)端末ではホームが殺される頻度が下げられるかもしれない

2010年以降の端末ならメモリ圧迫によりホームが殺される心配はあまりないと思うので、問題は腐ったアプリをどうするかになる。

■設定見直し
昨今ではアプリの品質はかなり良くなっているので、アプリを疑うより先に端末設定を疑った方が良い。

典型的にバッテリを食いやすくかつ設定で何とかなるのは「バックライト」と「電波」
バックライトは輝度を下げればてきめんに消費電力が抑えられるので、必要が無ければなるべく低めにしておいた方が良い。「設定」→「表示」から変更できる。
電波は「WiFi」「Bluetooth」「GPS」があり、使わない時はオフにしておいた方がいい。GPSも意外と電池食いだ。

設定の切り替え方だが、Androidには標準で「電源管理ウィジェット」というのがあって、これを使うとホーム画面からワンタッチで各種無線と画面輝度を切り替えられる。
ホーム画面で「Menuボタン」→「追加」→「ウィジェット」→「電源管理」とやると貼り付けられる。
設定切り替えツールは色々あるけど標準の電源管理ウィジェットが簡単でオススメ。
端末によっては通知バー(ステータスバーを引き摺り下ろすと出る奴)に統合されている場合もあるので、そういう端末ならわざわざウィジェットを貼る必要はない。

■バッテリ食ってるアプリの特定
腐ったアプリを1個動かすと一気にバッテリを食うし、行儀のよいアプリだけなら何個立ち上がっていても問題ない。
つまり実は腐ったアプリを特定してアンインストール出来るなら上で挙げたTaskKillerを使う利点は結局なくなる。しかしこの特定は意外と難しくてちょっと困る。

アプリごとのバッテリ消費状況は「設定」→「端末情報」→「電池使用量」で見られる(端末によるかも)

ディスプレイが食ってるなら画面輝度上げすぎ。
Android OS、Androidシステム、セルスタンバイ、メディアサーバー、あたりはシステムが使ってる分。
よっぽど立ち上げっぱなしにしているわけでもないアプリ名が食ってるならそいつが戦犯。

システムが使ってる場合は厄介。これはアプリ呼び出されて食ってる分が含まれているため、どのアプリが悪いか戦犯が特定しにくい。
メディアサーバーは割と仕方ない。これは音楽プレイヤーとして使ってたりするとどうしても使ってしまう。音楽聞きまくった場合のバッテリ消費は元々特化端末であるiPhone/iPodに比べるとやはり不利。

その他のシステム系が異常に食ってる場合は......難しい。
各アプリを見ていって「部分起動状態」(「スリープモードにしない」とか書いてるかも)が長いもの、GPS使用時間が長いもの、通信量が多いもの、などが疑われる。
これらが使用頻度や使用時間に比べてやたら長いものはバグっている可能性があるので、必要が無ければ消すか、同機能の他のアプリを検討する。

■そこまで詰めてもバッテリ食うんだけど
これ以上は結構厳しいかなぁ。
ここでTaskKillerに手を出すのは意味がない。ほんとにちゃんと詰めた後だとTaskKillerを入れてもバッテリ消費は多分かえって増える。
ここまで来ると要するに端末長時間触りまくってるのが原因。端末を触っている状態ではバッテリはどうしても食ってしまう。端末弄ってるってことはバックライトがずっとついてるわけだしAndroidアプリは通信を使うものが多いし動画とかFlashとか使うとなおさら。
バックライトの輝度を下げてみるとか、Flashをオフにしてみるとか、頑張る余地はあるにはあるけど、最終的には予備のバッテリ(eneloopのアレとか)を持っておくしかないんじゃないかなぁ。