色々と話題になっているAndroid 0.9 SDK beta ですが、Android Developers Blogの“Some information on APIs removed in the Android 0.9 SDK beta”を、日本語にしたものを参考までに載せます。
Android 0.9 SDK betaから削除されたAPIについて 2008/8/25 Dan Morrill
今週の初めに、我々はAndroid SDKのベータ版をリリースしました。以下の（前回の）投稿では、Android1.0に向けていくつかのAPIを削除しなければならなかったこと、そしてその結果として、それらのAPIは0.9 beta SDKにも含まれていないし、1.0互換のSDKにも含まれないであろうことについて触れました。今回は、何故そのようにしたのか、その理由について少し説明したいと思います。
・GTalkService
「XMPPService（当初はそう呼んでいました）」が初回のearly-look版SDKに含まれたことは、とてもエキサイティングなことでした。しかしながら、セキュリティをレビューするチームに評価を依頼したところ、彼らはすぐに気付きました。GTalkServiceは、エキサイティングであるのと同じくらい、いくつかの基本的なセキュリティ上の問題を抱えているということに。我々のセキュリティ研究者の一人であるRich Canningsは、この点について以下のように述べています。
GTalkServiceに初めて触れたとき、私はとてもエキサイティングな気持ちになりましたが、それと同じくらい怖い気持ちにもなりました。開発者としては、シンプルなインタフェースでGoogle Talkの友達（以下GTalk friends）との間でメッセージを送ることができる機能が提供されていることに興味を持ちました。メッセージは受信側のデバイスでは扱いが容易な標準のIntentとして取り扱うことが出来ます。なんてシンプルで美しいことでしょうか。しかし残念なことに、Tin Foil Hatをかぶった人（ヤヴァイ人）としてみたときには、このことはそれほど単純なことではないと認識しました。
我々は、以下に述べる理由により、GTalkServiceのデータメッセージングの機能を延期することに決めました。
- GTalk friendsに複数の意図を持たせてしまうことについて
GTalk friendsの目的（意図）は、GTalkServiceによって実現しようとしていることと異なります。あなたのGTalk Friendsは、いつでもIMを使ってあなたとコンタクトを取ることが出来ます。彼らはあなたのメルアドを知ることができますし、あなたの本名も知ることが出来るかもしれません。しかし、GTalk Friendsについての考え方は、必ずしもAndroidアプリケーションによってインタラクトしたい人々に対する考え方と合致しているとは言えないでしょう。例を挙げます。例えば、GTalkServiceを使った、とてもクールなモバイルの、大規模多人数参加型オンラインロールプレイングゲームがあると想像してみて下さい。あなたは、一緒にプレイするために、すべてのプレイヤーをあなたのGTalk Friendsに加える必要があるでしょう。そして、別のあるときに、あなたはWEBかデスクトップPCでGTalkにログインしたとします。あなたはたくさんの新しい「friends」がいることに気付くでしょう。あなたは彼らとチャットをしたいわけではないでしょう。そしてさらに悪いことに、彼らにあなたのメルアドや本名を知られたくないでしょう。Androidユーザーは、他のAndroidユーザーと、匿名で、かつ（特にゲームのシナリオのような）短い間だけインタラクトしたいのだと我々は気付きました。残念ながら、インスタントメッセージングがこのことに対する良い手段ではないと思います。
- Intentの送信元を検証することについて
Intentは、デバイス内でメッセージを送信するように設計されました。Intentサブシステムは、同じデバイスからIntentが生成され送られたときのみIntentの送信元を確実に解決することが出来ます。異なるデバイスからIntentが送られてきたときは、Intentサブシステムは、どのようなアプリがそのIntentを送ったのかを解決できません。このことは様々な問題を生み出す可能性があります。当初は、リモートのアプリケーションは任意のインテントを送信することが出来ました。このことはあなたのGTalk Friendsが、あなた自身と殆ど同じくらいあなたのデバイスを制御できたということです。この問題が解決されなければ、我々はリクエストの送信元となるアプリの身元を信頼することが出来ないだろうと判断しました。我々はそのユーザーの身元を信頼することが出来るだけです。つまり、あなたの友達のデバイスにインストールされている「悪い」アプリが、あなたのデバイス上の「よい」アプリにメッセージを送り、害をなすことが出来たということです。結局、Intentはローカルユースのために設計されており、RPCの伝達手段としては役に立たないものであると結論付けました。
- セキュリティ面でのあまりに多くの負担を開発者に強いていることについて
当初の設計では、GTalkServiceはセキュリティ面での欠陥を除去することや、ユーザーとのリレーションの管理をおこなうことをアプリ開発者に委ね、多くの負担を強いていました。GTalkServiceを使ったアプリには、すべてのGalk Friendsからアクセス可能です。そしてアプリに欠陥があれば、悪意を持った「friend」や、自動化されたマルウェアに対して恰好の標的となってしまいます。脆弱なアプリを保護したり、マルウェアの繁殖を防ぐことのできる自動化の仕組みは存在します。しかしこれらのテクノロジーの開発は最初のAndroidハンドセットを提供するまでには間に合いませんでした。
我々は、本当にこのサービスを提供したかったんです。しかし最終的に、Androidチームは、ユーザーを危険にさらしたり、将来提供されるよりセキュアな機能との互換性を弱めるのではなく、APIを取り除くことに決めました。我々はこのような機能が信じられないほど便利だということを十分承知しています。だから、いずれ開発者の方々にはたくさんの新たな扉を開くつもりです。最初のデバイスを提供した後の我々の最優先事項は、デバイス間（あるいはデバイスとサーバー間）の高速で、信頼でき、開発者やユーザーを保護できるRPCメカニズムを開発することです。
最後に、いずれにせよGTalkServiceはGoogleによって「価値が付けられた」サービスなので、全てのAndroidデバイスで動作することは保証していたわけではないということに私は言及したいと思います。つまり、GTalkServiceは決してAndroidのコア機能ではなかったということです。結果として、この変更は、Androidの将来のバージョンのコアの一部となる新しいシステムを我々が構築する可能性を開いたと言えます。
・Bluetooth API
Androidの1.0バージョンと、最初のデバイスはBluetoothをサポートする予定です。たとえばAndroidはBluetoothハンドセットをサポートするでしょう。early-look版のSDKでは、Bluetoothの基本機能は不完全なドラフト版のAPIとして開発者に晒されていました。しかし残念なことにこのAPIは1.0のリリースからは削除せざるを得なくなりました。その理由を知るために、私はNick Pellyとコンタクトを取りました。Nick Pellyはこの機能に対する責務があるAndroidエンジニアのうちの一人です。彼は以下のように語りました。
理由は、我々に検討する時間が無くなってしまった事です。Android Bluetooth APIは順調に進捗していましたが、SDKにコミットするまでにはいくつか整理する必要があります。Bluetooth APIを1.0 SDKに組み込むためには長い時間を必要とするということを心に留めておいて下さい。
APIの抱える問題の例を挙げます。クライアント側のコードでは、非同期でのコールバックを受けるためにIBluetoothDeviceCallbackオブジェクトを回す必要があります。しかしIBluetoothDeviceCallbackは内部的なインタフェースなはずです。新たなコールバックをIBluetoothDeviceCallback.aidlに加えた瞬間クライアントコードは破壊されてしまいます。これは将来的な運用に耐えるものではありません。
さらに慎重を期すことになった要因としては、最近発表されたbluez 4.xシリーズでは新たにAPIが追加されているという点です。Androidとbluezのインタフェースに似ている点があることからも想像がつくでしょうが、Android Bluetoothでは、GAPとSDPのためにbluezを利用しています。bluez 4.xの変更によって、我々は将来的にAndroid Bluetooth APIをどう構築するかを慎重に考える必要に迫られています。また、インタフェースを一旦決定してしまったら、我々はそれをずっとサポートしなければならないということを考えて下さい。
たくさん変更が入るだろうとわかっていながら、破綻したAPIを提供するよりは、それを含めないことを我々は選択しました。我々は、いつか必ずBluetooth APIをサポートするつもりです。しかしそれがいつになるのか、正確なことは言えません。以下は含むべきいくつかの便利な機能の一例です。
- GAPとSDP機能とのバインド
- RFCOMMとSCOソケットとのアクセス
- JavaでのL2CAPソケットのサポート（これは検討段階です）
- 我々のハンドセットとハンズフリープロファイルとのAPI
個人的な発言として、Nickは付け加えています。「私はちゃんとしたサードパーティのアプリやゲームがBluetoothを使って動くのを見ることが何よりも大好きです。私は、Bluetoothは多くのモバイルプラットフォームでもっと十分に活用されてしかるべきだと思います。そして開発者コミュニティがAndroidを使って何をするかについてとても興味を持っています。」
私は、今回のAPIの削除については非常にがっかりしました。特にGTalkServiceによって提供されるP2Pの機能を楽しみにしていました。しかし、いつでもユーザーのセキュリティとプライバシーは最優先に考えなければなりません。いかなる場合でも、我々はこれらの関心事とバランスを取れた素晴らしいAPIを作るために開発者コミュニティとともに活動していきます。