akaiho St.

ついにオープンソース化されましたー。
http://source.android.com/

ソースだけで2.1Gあります。 ビルドには6GBほどの空き容量が要るようです。

そして、新たにディスカッションの場としてメーリングリスト(Google Groups)が追加で新設されました。

Android platform
Androidプラットフォームに関する一般的な話題

Android framework
アプリケーション開発のためのフレームワークの拡張や開発について（kernelより上層の話題）

Android porting
さまざまなハードウェアにAndroidをポーティングする事について

Android kernel
Android kernelについて

既に以前から運営されていたMLに関しては引き続きという形のようです。
ソース読むの時間かかりますが、楽しくなって参りました…！

MacでEclipseを使用してAndroidアプリケーションを作成しているのなら、eclipse3.3(Europa)からeclipse3.4(ganymede)にすると日本語インライン入力できていいですよ、という心温まるお話。

ただ、ADTなど、各種プラグインは再度入れ直すことになるんですけど。（設定は引き継いでくれる）

当社のarmadillo-500くんです。

レゴられてます。

グーグル、Android搭載携帯電話アプリを配信する「Android Market」開設

公にGoogleがAndroidアプリケーション配信システムの発表をしました。
やはりオフィシャルなものがあると安心感が違いますね。 Google Gadgetのように簡単に登録できるようなものなら良いのですけど（有料になるとまた色々あるでしょうけど）。

さて、もう一つ、ADC (Android Developer Challenge I)の受賞者発表が行われました。
http://code.google.com/android/adc_gallery/index.html

いくつかは動いてるところを動画で見ることができますので、YouTubeあたりで探してみると面白いですよ。

少なくとも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は非力なので十分ではないのです。この構成は効率的にベクタ画像を描画できないのです。