少なくともGoogleは今のところ公式に用意するとは表明してないわけですが、評価システムは入れたい意向のようですね。一方では、最初にAndroid端末を発売する予定であるT-Mobileは、自社で取り扱っているスマートフォン機種に限定した形でのApp Storeのようなものを用意していると言っています。
ところで、iPhoneの場合、XBox Liveなどと同様に、動作機種がかなり限定されてるんで(iPhoneかiPod Touch)、ユーザーにも開発者にもプロバイダにも特別負担なく運営できますが、Androidの場合、載る機種はいったいいくつぐらいあるのか検討もつかないので動作確認機種がずらずらと羅列されるような、ケータイアプリのページだとよく見るような感じになるんでしょうか。
GetJarなんか見てても、なかなか壮観な機種一覧ですけど。
アプリ開発側はどこまでカバーするべきなのか、気になりますね。
以前のSDKからセキュリティホールが発見されていたりしたAndroidですが、セキュリティに関する報告、情報を広く受け付ける窓口と、ディスカッションの場を公式に設置したようです。（共に英語）
セキュリティアナウンス
http://groups.google.com/group/android-security-announce
セキュリティディスカッション
http://groups.google.com/group/android-security-discuss
皆さんのご想像のとおり、安全なモバイルプラットフォームの実装、管理は非常に難しいです。 自ら発見したり、あるいは報告していただいたバグや問題を数多く修正してきましたが、これだけ大きくかつ複雑なシステムにおいて今後もさらなる問題が起こることは不可避であると感じました。 そういった経緯により、我々（Androidセキュリティチーム）を紹介したく、かつセキュリティ研究コミュニティに我々とともにどうやりとりするのかをお知らせしたかったのです。
securityあっとandroid.com
宛に、発見した問題を報告していただくと、すでに解決済みの問題であれば対処法を丁寧に教えてくれますし、そうでない場合は対処作業の進捗を逐一報告いただけるようです。
Androidは数多くのデバイスに載る予定であるため、これだけ大きくかつ複雑なシステムである以上、パッチの調整にも多くの労力がかかります。それ故、多くの信頼できる開示を期待し、また感謝します。
とのことです。
SDK更新されましたねー。
Ver 0.9ベータです。
http://android-developers.blogspot.com/2008/08/announcing-beta-release-of-android-sdk.html
アップグレードは以下から。英語ですが手順も書いてあります。実際はたいして面倒でもないです。
SDKをダウンロード、展開して、そのディレクトリをeclipseのAndroid設定で指定。あとはADTを更新するだけです。
場合によっては、エミュレータの内部設定をワイプしなければならないですが。
http://code.google.com/android/intro/upgrading.html
m5からの変更点はこちらに記載されてます。
http://code.google.com/android/migrating/m5-0.9/changes-overview.html
今後のロードマップも公開されています。
http://code.google.com/android/roadmap.html
UIがGoogle I/OやGoogle Developer Dayでデモをしていたものになっていますね。
結構変更点が多いです。 ボクのプロジェクトもことごとく赤×だらけです。とはいえ、だいたい簡単な修正で済みましたが。
まだまだ変更点を総ざらいしてるところなので具体的にどう改善されたかはこれから調べますが、完成に近づいてるということでwktkしますねー。
8月9日に、オープンソースカンファレンス2008 Nagoyaに参加してきました。
Android勉強会の枠でAndroid-SDK-Japanの紹介をしつつ、展示ブースの方で色々な方とお会いしてきました。
名古屋でもAndroidの注目度は高いようで、結構な人数の方に見にきていただきました。
FLOSS桜山Android分科会の富永さんには大変お世話になりました。名古屋でもAndroid勉強会を開催しているのは心強いですね。
しかし会場の名古屋市立大学 山の畑キャンパスは少々駅から解りづらく、たどり着くのに苦労しました…。ナビウォークのお世話になってしまった。
次週、Android Developers Challenge(ADC I) の最終結果が発表される予定です。
そして、これはただの個人的な予想ですが、それを皮切りにAndroid関連のニュースが色々出てくるのではないかと思われます。
OHAという形式で様々な企業が参画している中での開発であるため、Google側もかなりAndroidに関する情報の取り扱いには慎重で、Googlerはただの思いつきであったり感想であったりしてもどこでどう伝わるかわからないため、ほとんど何も言えない、という状況です。
それでも最近様々なAndroid（主に端末に関する）情報は目にする様になってきました。
最近だと、HTCが端末年内リリースを予定している事であったり、QualcommもAndroid向けに開発をしている意向であったりといった内容ですね。
SDKも、一般に配布こそされてはいないものの、アップデートされたものが存在しているのは確かですし、今後公開されるのが楽しみです。
Android Developers (Google Groups)で、「スケーラブルな画像もサポートしてないのはなぜなんだ」という意見があり、議論が起こったのですが、
Googleで実際にAndroidの開発にあたっているDianne Hackborn(hackbod)氏による返答が非常に面白かったので、勝手に訳してみました。
（多少意訳です。あえて文体は柔らかめにしてあります。）
原文は以下よりどうぞ。
scalable vector graphics scalable vector graphics scalable vector graphics
６年前、以前勤めていた会社では、開発していた携帯のリファレンスモデルは200MHz ARMの32-64MB RAMでした。
現在、AndroidプラットフォームのリファレンスはARM 200-400MHz、64-128MB RAMです。そして、ターゲットは以前と同様、ハイエンドモデルです。
携帯電話のマーケットはPCのそれとは異なります。これは紛れもない事実です。価格やサイズ、バッテリーの持続時間等は、純粋なハードのパフォーマンスより重要になる事が多く、それらは（PCと比べ）ハードウェアのデザインに大きく関与します。
「640Kもあれば、誰でも十分だろう。」という文は誇大に使われています。（訳注:3D機能よりも、2Dを充実させて欲しい、ベクタを使わせて欲しいという事に関して引き合いに出されていた。かつてビルゲイツが言った言葉。）
スケーラブルなグラフィック機能を持たない事は、プラットフォームにとって致命的な事ではありません。実際、あなたの書いた原文は非常に大げさです。AndroidとX-WindowのAthena toolkitとの比較はおかしなことです。Androidの合成エンジン（compositing engine)はX-WindowというよりもずっとMac OS Xに近いのです。
iPhone UIに関するコメントも疑わしいです。私はiPhoneのアーキテクチャに関して詳しくありませんが、あれは3Dハードウェアアクセラレーションを促進しています。（iPhoneで使われているビットマップテクスチャの合成や変形は、OS XでかっこいいアニメーションやUIのトリックに使われているものであるため。）
これは、今日広く使われているグラフィックスアクセラレーションハードは、ビットマップテクスチャの変形や合成が非常に得意であり、2Dのスケーラブル画像のレンダリングには特化されていないから、という理由があります。iPhone UIとAndroidのクオリティの比較はスケーラブルグラフィックスとは何の関係もありません。 iPhoneのソフトは全て統一された画質の単一のデバイス(iPhone)で動作するので、スケーラブルなグラフィックスによる恩恵はほとんどないでしょう。ウェブブラウザでズームインやズームアウトをしたいときにはスケーリング機能は便利ですね。二つとも丁度WebKitですし。
でも、スケーリングや変形効果を使ったアニメーションに関しては、スムーズに見せる為のベストな方法はビットマップ（ベクタではなく）を使うことです。iPhoneが滑らかな動作を見せる原因の一つは、それらのアニメーションを60fpsで動かすために非常に時間を費やしているから、そしてそれらは全てを3Dハードウェアアクセラレーション上のテクスチャレンダリングで行っているのです。Androidは、レイアウトレベルでの画質解像度情報が組み込まれているので、開発者が様々な単位（実際のピクセル数、実際のインチ、スケールされたピクセル数、フォントスケールの単位等）で指定できます。 そうすれば、レイアウトで1ピクセルの厚さのラインが欲しいすると、それは実際の画面に合わせたサイズに(1ピクセルや2ピクセル等)に自動的に変換されます。
Appleには、「多少ピクセルがぼける事を犠牲の上で、アンチエイリアスを大量に使うことで線のポジションをよりきれいに表示する」という美学があり、UIはそうデザインされています。
しかし、非常に多くの人々がこれを好む一方で、また多くの人々が、ヒンティングとアライニングを用いた事でアンチエイリアスのインパクトを減衰させたレンダリングを好んでいます。ここで「どちらが正しい方法か」を提案するのは非常に難しいです。ともかくAndroidに関しては、いくらかのヒンティングをフォントレンダリングに用いたことでクッキリしたテキストを表示する事にしています。そして同様に、解像度調整がビューレイアウト、実2Dレンダの順に行われるので、ピクセル境界が調整できます。実際のところ、私の知る限りでは、モバイル開発者の欲求は以下の三つです。
1. 可能な限り高解像度。
2. 必要最低限のCPU。(価格やバッテリーの為)
3. 3D ハードウェアアクセラレータこのような環境においては、スケーラブル（ベクタ）グラフィックスのものよりラスタ（ビットマップ）ベースのUIの方がはるかに優先されます。それはあらゆる滑らかなレンダリングにおいて3Dアクセラレータを使用することになるからです。CPUは非力なので十分ではないのです。この構成は効率的にベクタ画像を描画できないのです。
もうモバイル関連の仕事に携わっている方々ならご存知の事だとは思いますが、世界で広く携帯用のOSとして用いられているSymbian OSの開発提供元であるSymbianが、OHAのようにいくらかの携帯関連企業とアライアンスを組織し、かつOSをオープンにするという予定を発表しました。
そしてその直後に、Nokiaが買収。
Symbianは世界的にシェアはかなりもので、今ケータイ用のアプリ等作ってる開発者でも馴染みになっている方が多いと思います。それがオープンになる、ということで、当然の様にビッグニュースとなったわけですが、行動そのものは確かにGoogleによるAndroidと似ています。
しかし意味合いが違うのは、Symbianは既にシェアを確立しているという点。つまり既存の開発者には既にノウハウが貯まっています。
こういった様相から、私がこれまでオンオフ共にお会いしてお聞きしたり、あるいはただ目にしただけの意見等を見ていると、日本では概ね「Androidだいじょうぶ？」とか「OHA終了」とか、Android劣勢的な意味合いの意見が多かったです。
一方で、アメリカのAndroidコミュニティを見ていると、悲観的な意見はあまりないのです。むしろ「GoogleによるAndroidの効果が早速出たね。」「統一されてくるのはありがたい」等、より良くなるねという楽天的な意見をよく見かけました。
Googleのミッションが世界をより良くするという事であるならば、既に大きな効果が現れたと言えます。それでもなお、UIや実効速度等において、競争相手がいることで開発ペースに向上が見られるなら面白い事になりますね。今後に期待せざるを得ないし、ボク自身も貢献していきたいです。
少し前の話ですが６月２日（月）に、早稲田大学主催のAndroid勉強会で話す機会をいただいたので少ししゃべってきました。
実際、画面上で細かく動かす各オブジェクトに多くの機能を求めない限りは、少なくとも現状ではSurfaceViewがベストです。
Web Pageの場合、画面上で１秒以内に何度も変化するような物を置く事は、flashでもない限り滅多にないので素直にViewで良いと思いますが、一方でゲームなど、画面上の絵がフレーム単位で描き変わるような場合、UIスレッドから描画スレッドが独立している方が高速です。
前回も告知しましたが、今週はGoogle Developer Day 2008ということで、パシフィコ横浜へ行きます。
よろしくよろしく！