http://developer.android.com/sdk/ndk/index.html

の内容を意訳してみました↓

Android NDKはAndroid アプリでネイティブコードで作られたコンポーネントを組み込むためのツールセットです。AndroidはDalvikVM上で動作します。NDKは、アプリをCやC++で記載されたネイティブコードで実装することができます。このため、既存のライブラリを再利用することができ、開発効率の向上にも貢献します。

NDKが提供するものは

• CやC++で記述されたソースコードから、ネイティブコードライブラリを生成するためのビルドファイルとツールセット。
• Androidデバイスにデプロイ可能なAPKファイルに固有のライブラリを埋め込む方法。
• Android１.５以降の全てのプラットフォームでサポートされるネイティブのシステムヘッダとライブラリセット。
• ドキュメント、サンプル、チュートリアル。

現状バージョンのNDKでサポートしているのは、ARMアーキテクチャで

• ARMv5TE (including Thumb-1 instructions)
• ARMv7-A (including Thumb-2 and VFPv3-D16 instructions, with optional support for NEON/VFPv3-D32 instructions)

今後のリリースで

• x86 instructions (see CPU-ARCH-ABIS.TXT for more information)

がサポートされます。

ARMv5TEのマシンコードであれば、ARMベースのAndroidデバイス全般で動作するでしょう。ARMv7-Aの場合は、Verizon DroidやGoogle Nexus Oneなどの互換CPUをもつデバイスで動作するでしょう。
ARMv5TEと ARMv7-Aの大きな違いは、ARMv7-AがハードウェアFPU（浮動小数点処理装置）、Thumb-2（ARMの拡張命令セット）、およびNEON（メディアおよびデジタル信号の処理に向いた64ビットと128ビットの命令セット）をサポートします。
ARMv5TEと ARMv7-Aの両方でもどちらかでも利用することができ、ARMv5TEをデフォルトとして、ARMv7-Aに切り替えるのは簡単で、Application.mkファイルに１行追加するだけです。
また、ARMv5TEと ARMv7-Aの両方のアーキテクチャ用にビルドすることができ、apkファイルに全て格納できます。詳細については、NDKパッケージのドキュメントに含まれるCPU-ARCH-ABIS.TXTを参照。

NDKは、libc(Cライブラリ)、libm(Mathライブラリ)、OpenGL ES(3Dグラフィックスライブラリ)、JNIインタフェース、および他のライブラリ用に安定したヘッダを提供します。

NDKはほとんどのアプリケーションには効果が無いでしょう。開発者としては、利益と欠点のバランスを取る必要があるでしょう。ネイティブコードを使用することは、著しい自動的なパフォーマンス向上がもたらされることは無く、アプリケーションは複雑化します。
NDKの効果的な使用例としては、多くのメモリを割り当てずにCPU負荷の高い操作 する場合や信号処理、物理学のシミュレーションなどです。単純に既存のメソッドをCで最コーディングしただけでは、大きなパフォーマンス改善には至りません。しかし、既存のC/C++コードを再利用する分には、効果的な方法と言えます。

NDKはネイティブコードだけのアプリケーションを開発するためのものではありません。AndroidのプライマリランタイムはDalvikVMのままです。

・Restlet Edition for Androidをダウンロード
　Restletのダウンロードページから、2.0の「Available editions」→「Edition for Android」の「Zip archive」からダウンロードします。

・使用するjarを取り込む
　ダウンロードしたzipを解凍し、「/lib/」ディレクトリ内にある、「org.restlet.jar」と「org.restlet.ext.json.jar」をAndroidプロジェクトのassets内に入れ、プロジェクトを右クリック→プロパティ→ビルドパス→ライブラリ→jarの追加から、上記の２つのjarを取り込む。

・GET通信

import org.restlet.Client;
import org.restlet.Request;
import org.restlet.data.Method;
import org.restlet.data.Protocol;
import org.restlet.ext.json.JsonRepresentation;
import org.restlet.representation.Representation;

(中略)

Client client = new Client(Protocol.HTTP);
String url = "http://www.example.com/";
Request request = new Request(Method.GET, url);
try {
	String jsonStr = client.handle(request).getEntity().getText();
	JsonRepresentation json = new JsonRepresentation(jsonStr);

} catch (IOException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
}

・POST通信

import org.restlet.Client;
import org.restlet.Request;
import org.restlet.data.Form;
import org.restlet.data.Method;
import org.restlet.data.Protocol;
import org.restlet.ext.json.JsonRepresentation;
import org.restlet.representation.Representation;

(中略)

Client client = new Client(Protocol.HTTP);
String url = "http://www.example.com/";
Form form = new Form();
form.add("name", "value");
Representation rep = form.getWebRepresentation();
Request request = new Request(Method.POST, url, rep);
try {
	String jsonStr = client.handle(request).getEntity().getText();
	JsonRepresentation json = new JsonRepresentation(jsonStr);

} catch (IOException e) {
	// TODO Auto-generated catch block
	e.printStackTrace();
}

・参考
Restlet edition for Android
Restlet edition for Android – Sample application

・受付
　受付開始時間ぴったりくらいに着いたんですが、すでに50人待ちくらいになってました。しばらくすると100人くらいの大行列に進化し、受付作業が終わらず開始が10分押しという事態になったりと、前回の2009Fallからさらに大規模なイベントになったようです。後で聞いた話ですが、参加者が4桁いったとのこと。androidに対する世間の関心がどんどん高まってきている証拠ですね。

以下、twitterのログから抽出のため、箇条書きでいきます。

・講演前

• 司会進行は女子部部長の矢野りんさんと副部長のあんざいゆきさん
• なぜかfroyoコールをもとめる矢野りんさん

基調講演「Androidの現在とメディアの未来」 丸山 不二夫先生

• 現在６０種類のandroid端末が発売されている。日本も３つのキャリアがandroid端末を発売、世界では59のキャリアが採用。この一年は激動の年だったといわれている。
• WWDC2010でのSteeb Jobsが示した数字ではandroidのshareは４位だが、別の調査によると一位になっているとも言われている。
• EVOはDROIDを上回る勢いで売れているし、GalaxySは110カ国・地域で発売されるとか。キャリア・メーカは今Android端末を準備中。これからもどんどん増えていくだろう。
• froyoではMSのExchangeサーバもサポートするらしい。 アプリデータをばっくあっぷするAPIも用意されている。クラウドからデバイスへのメッセージ送付のAPIの提供、テザリング、javascriptの性能が２倍～３倍（モバイルブラウザ最速）など。
• あと、HTML5のサポートとFLASH、AIRのサポートもやってゆく。adobe側もandroidのサポートを今がんばっているところ。（iphoneから蹴られたしね）。マーケットの機能の強化、フレキシブルな広告フォーマット対応。froyoは新規対応が満載。
• 世界の携帯は５０億を超えようとしている。これがトラフィックの爆発的な増大に繋がっている。ただ、携帯端末とPCには大きなギャップがある。これを埋めるのがクラウドデバイスであり、スマートフォンである。
• これからは携帯の端末数が増えるだけではなく、PCのトラフィックを携帯端末が追い越すだろう。たとえばAT&TがiPhoneの導入で３年でトラフィック量が50倍に跳ね上がったように。 （このためAT&Tは定額制をやめちゃいました・・・）
• 日本でもいずれ定額制が廃止されるかもしれないね。
• iPad、３ヶ月で３００万台売れました。ただ、Android版とWindows7版もそのうちでます。ASUS,HP,Sony,BiglobeのCamangi、DellなどがAndroid版タブレットを作成中。googleもandroidタブレットを出す。
• ただ、売り方や見せ方はアップルからまだまだ学ぶべきことはたくさんある。アップル信者というのも、マーケット的には非常に価値がある。
• Microsoftの２画面タブレットCourier開発中止。UIはかなりよかったと思ったのだが、、、残念。これからはAndroidの主戦場が携帯端末だけでなく、もっとグローバルになるだろう。
• メディアがばらばらだったからマルチメディアと呼ばれていたが、今は一つのデバイスで全ての情報にアクセスできるようなネットワークが変わっていく。つまりUni-Mediaへと変わっていく。
• 実はアップルもクラウドを作っていて、ノースカロライナ州にて建設中。アップルのUSB動機がこのクラウドセンターの出現によってやり方が大きく変わる可能性がある。ただし、まだ何に使われるかは不明。
• applestoreの売り上げは今までゲームが一位だったが、今は書籍が一位になった。appleはe-bookに注力しようとしている。日本はまだまだ動きが弱い。
• 今年はオンライン販売がCDの販売を追い越すだろう。AppleはLaLa(音楽の会社）を買収したのは非常にほっとな話題。
• あと１０分といわれてあわてる丸山先生ｗ
• googleの音声認識はすばらしい。ああいうものが機械と人との間を埋めていくものだと思う。 radikoの登場もクラウドという観点からみると非常に大きな一歩といえる。
• MSの３Screens + 1 Cloud ３ScreensというのはPC,携帯、テレビ。テレビはXBOX使ってごねごねするらしい。この３つをクラウドで連携させるという構想を描いている。
• sonyもMSと同じ構想で闘うことは可能。日本の企業だしがんばってほしい。
• クラウドと繋がるデバイスとしてのAndroid、これからもっとおもしろくなるだろう。

招待講演：「Android Updates and Q&A」 Google Chris Pruett氏

• 一日あたりのandroidの世界販売台数は16万台。で、さっきの丸山先生の話にもあったように端末数は60種類。Androidマーケットに登録されているアプリは6万5千ほど。
• Androidのバージョンシェア率。1.5=25%, 1.6=25%, 2.1=50%。2.1は去年の冬にでたのにもう半分。
• froyoの話。変わった点は、スピード、新API、ブラウザ、Androidマーケット。
• スピードの話。JITコンパイラが導入され、Javaコードが2～5倍速くなる。2.1と2.2を実際に同一アプリで比較してみると、2.2の方がフレーム数で１．５倍くらいでてる。
• 新APIの話。 Cloud to Device Messaging。 appサーバからクラウドにメッセージを投げると、クラウドから端末にメッセージがプッシュされる。例えば、PCのgoogle mapで検索した結果を端末に表示させることができる。
• 自動的にアプリのデータをクラウドで保存（Aplication bakup API）、アプリをSDカードで保存、端末がWifiのホットスポットになるなどなど。（さっきの丸山先生の講演でも紹介されてた内容ですね。 ）
• ブラウザの話。V8 Javascript Engineが導入され、Javascriptの実行速度が2～3倍早くなる。デモでみてみるとかなり違う。
• Androidマーケットの話。自動更新設定が入る。これはアプリケーションのDL履歴がマーケットが覚えているので、自動でアップデートしてくれる機能。また、一つ一つ確認するのがめんどくさい場合は全部更新する、といったようなこともできるようになる。
• マーケットの話その２。エラーレポートシステム。今すでに使われている機能だが、スタックとレースつきでDeveloper Consoleにユーザのアプリでエラーになったデータが登録されている。
• その他。 Native Development Kit r4リリース（Rhodesだと動かないんだよねorz）、GoogleTV発表、つい先日にFroyoコードリリースされましたよ！GDD2010Japan September28th 東京・京都で開催。
• ここからQ&A。
• OSバージョンのシェア率の数字はどこから？ → androidマーケットから6/24日前後２週間くらいのログを集計して出した。なのでマーケットにアクセスしてない端末は分からない。
• 日本の端末は今後も1.6ベースが多い点をどう思うか。→1.5の時点で重要な機能はすべてもりこまれている。2系の方が魅力的な機能が多いが、特に大きな問題ではないと考えている。またOSはバージョンアップされていく可能性もある。
• ジンジャーブレッドの情報を教えてください → まだ明確に決まってないのでなんもいえないです。すみません。情報はやっぱりコミュニティ経由で手に入れるのがいいと思う。英語が苦手なひとは特に。android-sdk-japanのMLや、書籍などなど。
• froyoのアプリのSDカードインストールはファクトリリセットしたとしても大丈夫？ → 実はSDカードにいれるときにちょっと暗号化してる。でもファクトリリセットしても問題ないです。
• ネットにつなげないタブレットなんかはマーケットがアプリとして入ってないのはなぜ？ → よくわからない端末からのアクセスはコピープロテクションも正常に動くかあやしい。また、マーケットは国や端末を対象にしてフィルタをかけてる。
• スクリーンショットを取れないのはなぜ？ → セキュリティのため。 ただ、アプリでスクリーンショットを取ることができる。第三者のもがんばればとれるかも。
• ポーティングの負担が大きいがそれに対してなにかしら取り組みを行っているか。 → がんばれ。

「未来を開く鍵：Smart & Application」 NTT DoCoMo 山下 哲也氏

• スマートフォンは技術の進化というだけではなく、スタイルを変えようとしているという点に着目したい。それこそ「Smart」に。
• 「Smart」の本質、Applicationの可能性、Complexityについてが今回のテーマ。
• 「Smart]とは？→感覚・直感に訴えるもの。調和されたもの。そして一見シンプルだが、中には複雑系がきっちり作りこまれていて、使いやすいもの。t魔r極限まで磨かれたものであり、むだではなく、必要なものだけが美しいもの。お茶の作法に通じるものがあるらしい。
• 次のSmart化はきっとTV。SonyがGoogleTVの放送を発表している。そして、TVといえば、リモコン。今はボタンのお化け（たくさんボタンがありすぎる）。こんなのじょぶずが許すわけがない・・・・
• Smartはなぜ過去に実現できていないのか。→個々に独立、共通実行環境の不在、接続の複雑さがあった。 これからは・・・ → 多様な相互接続環境などを実現。それにAndroidが寄与する。
• Smartのまとめ。 Smart それは、ライフスタイルを変え、産業を変え、社会を変える。
• 次はアプリの話。 アプリはユーザに一番近いUIそのものであるともいえる。
• これまでの”想像”は・・・ → 実現手段の制約、配布手段の限界、コストの問題などが大きな障壁となっていた。さらに実現しても、「単独・孤立」、「断片的・離散的」であった。つまり、個々の想像は独立・制約ががあり、連続する創発が生まれにくい。
• この10年で情報環境は大きく進化した。処理能力の向上、ネットワークの進化、データをシェアできるクラウドの登場などがあげられる。次は実行環境の進化。マウス・キーボードというハードに縛られているものが、スマートフォンではタッチパネルによって表現が自由になっている。
• 今、全ての要素が動機し、進化が猛烈に加速している。タイム・スケールを考え直す必要すらある。（実現速度が飛躍的に向上している。）
• Applicationの特徴について。 必要性（役に立っているか？）、持続性、成長性（変化し続ける環境に対応できているか？）。例えば、Evernote。いろんなデバイスから自由に情報を取り出せる。Applicationの特徴をきれいに抑えている。
• そして、既存メディアも「アプリ化」は免れない。新聞・雑誌など、どんどんアプリ化が進んでいる。なぜならその方が「Smart」だから。
• これまでは・・・ → 個別最適化を重視・利用環境や形態は一定。 そしてこれからは・・・ → 全体最適化 利用環境や形態は不定。 全ての要素の再構成が始まる。（車も含めて。）
• これからは創造のプロセスも変化する。坂本竜馬の時代も世界が変わったことでやり方を帰る必要があった。過去のやり方を見直し、進化する必要がある。そこには競争、闘争が発生する。
• 「斬」：因習を斬り、斬新な価値観を。 「創」：最高の経験の創造を含めて。 「挑」：可能性を信じ挑戦する。
• 今年の秋にスマートフォンの課金を対応する。開発者にもエンドユーザに対しても使いやすいものを、ということを目指している。ドコモマーケットはあくまで「１つのショップ」である。ただ、競争が生まれるような仕組みにしたいと思っている。アドバイスがあれば聞きたい。
• ブラウザ上でのアプリ提供は開発がらくだが、一定のボーダーを越えられない。公平普遍的にどうしても出さなければならないというものであれば、ブラウザアプリもひとつの解だが、より魅力的なものにしたいというのであればやはりアプリにすべきだと思う。
• ドコモマーケットのUIは使いにくい。ドコモこそ過去を振り切れて居ないのではないか？→ブラウザでやってるのでブラウザの壁が越えられず、妥協している箇所がある。マーケットをアプリ化していく必要があると認識している。今までの使い方から大きく変えないよう意図的にしてる
• スマートフォンがこれからデジタルイメージの世界をどこまで侵食していくか → カメラ、携帯電話、というカテゴリを勝手に作ってしまっている。行いたい事ができればカテゴリはなんでもいい。カテゴライズすることにはあまり意味がない（ただしマーケティングでは重要）

「KDDIのAndroidへの取り組みについて」 KDDI 上月 勝博氏

• IS01から初めてCDMA２０００（C2k）に対応してて、この対応に時間がかかった。日本のC2kは２G帯を使っているため、結構特殊。周波数の置き換えを進めている。今後はスムーズに発売できると思う。
• Android端末展開の考え方。 ・日本市場のより多くのお客様に受け入れられるよう機能を追加したモデル。 海外初の新しいモデル。 この二つをベースにバリエーションとして色々な組み合わせ方をして展開していく予定。
• 機能追加の考え方。 Googleのデバイス規定に従って、AndroidMarketを活用できるというのは必須。国内ニーズに対応するための機能追加は、必要最小限にとどめる。できるだけアプリで対応する。機種個別の開発コストの共有化を意識している。
• 日本定番・安全機能の搭載：Eメール、ワンセグ、LISMO、Felica、緊急自身速報、遠隔ロックなど。使いやすい環境を提供：AndroidMarket、AuoneMarket、事業者課金（auかんたん決済）、
• 新しいコミュニケーションを創造：Share!、Sekai Camera、hotpepperなどなど。（felica、決済くらいしかめぼしいものがないかな・・・）
• IS01のUIのデモ。（凝っててぬるぬる動いて綺麗。ただ、作りこみすぎるとOSのバージョンアップがしにくくなるからあまりやってほしくないっていう気持ちもある。）
• UIのベースはスウェーデンの会社が作ったらしい。
• DalvikVM上にKDDI拡張UIライブラリ、拡張UIアプリケーションを新しく追加して作成した。（ここがきっちりモジュール化できてるならバージョンアップもしやすいとおもうんだけど、どうなんだろう・・・2系にアップデートできるのかな？）
• au one Marketの特徴：キャリア課金、多様な切り口（ランキング、記事型、リコメンド）によるアプリの提案、事前検証を経た安全なアプリ（mustではない。選択式）
• au one Marketは8月から。
• AndroidMarketの中にAUカテゴリを作ってもらい、そこからau one Marketがみれるようにする。au one Marketアプリも用意している。
• IS01はめがねケース、めがねケースと散々言われて、営業もちょっと弱気になっている（苦笑）が、実際にデモ機を触っていただいたお客様にはかなり好印象で、当初の予定の倍の発注をかけているところ。
• A32010Winterへ協賛します。ユニークなアプリを募集します！
• QAに移行。SDKのバージョンアップはどうなるの？ → シャープさんと考えます。前向きに考えます。

ここでPCバッテリが底をつき、ログがなくなったのでこれ以降は記憶を頼りに書きますｗ

「Sensing with Android : AndroidをSink nodeにした無線センサネットワーク」 日本Androidの会 学生部 石塚 宏紀氏

• アンドロイドをsink node にした無線センサネットワーク
• センサネットワークを正しく構成して色んなものを見える化する。
• 例えばヘルスケア、任天堂のwiiとか構造物モニタリングとかアメダスとか。
• センサネットワークの課題は、密度。センサノードをたくさん容易するとコストが高くなる。
• people centric sending人がセンサーをもってあちこちを収集するのも一つの手。
• irismodeというのがあって、世界でもっとも流行った端末の後継機がmica mote(マイカモートと読むらしい）
• mica moteは結構日本にあふれている。でも独自にデバイス作るようになってお役御免。
• というわけで余っているmica moteのセンサネットワークのデータをアンドロイドで扱って見た。
• gps温度湿度照度などのセンサを繋いで、色々情報を取得してみた。
• →できた。バイナリでデータがとれて解析して表示させられた。
• Live E! センシングの実験を行う。→http://www.live-e.org/

「Bluetoothで動かす！Android時代のミニ四駆＆Androidロボットのつくりかた」 たけいひでゆき氏

• はんだこてをあてたときに発生するゆげをかぐと気分がやわらぐというはんだテラピー行ってます。
• アンドロイドとデバイスはbluetooth(spp)で通信できる。smasuiさんありがとう。
• ハードウェア側が触れると、作れるものの幅がかなり広がる。敷居高いけどおすすめ。
• ミニ四駆制作費合計一万くらい。
• もなか（Androidロボット）は外装が数万だが中身は一緒（一万程度）。
• 開発期間ミニ四駆で一週間。もなかは一ヶ月。

「Mobile 2020 ～スマートイノベーションで激変するモバイルビジネス最前線～」 株式会社GClue 佐々木 陽氏
資料：google waveに飛びます

• 2020というのは、この時期にはもろもろの競争が決着してるはず、という時期。
• ソニーエリクソンの予測によると、2020年にはスマートフォンが五十億台にあなる。
• プラットフォーム on プラットフォームが、これからのキーワードの一つになる。Admobがいい例。
• 加速する3スクリーン+クラウド。TV,タブレット、スマートフォンとクラウド。
• Google,Apple,RIM等がこの3スクリーン＋クラウドを構成するために様々企業の買収を行っている。

LT

• twirecoのできるまで。＠山崎利崇氏
  懇親会のじゃんけん大会でNexus Oneが当たったのでtwitpicの音声版を作って見ました。
• ゴルフアプリ、キャディー君@小林　誠（sharakova）氏
  コースをGoogleMap上から見れるようにしてみました。
• CircuitLogger for Android＠加藤剛史氏
  時速100km/hの中でGPS機能を駆使してログをとってみました。
• もうやだこのデザイン環境@Nkzn氏
  iPhoneやWindowsMobileにはデザイン作成環境がきっちり整備されているのにAndroidときたら・・・orz
• レッツゴーハッカソン！@ニシオカ氏
  ゴリラ語でモールス信号やってみました。
• DOROKURIと賞金百万円について@タオソフトウェア(谷口岳氏)
  A3で大賞頂きました。

Ustream

• A会場
• B会場
• C会場

・発表資料
発表資料はそのうち日本Androidの会のページに張られるかと思います。
イベント/Android Bazaar and Conference 2009 Fall – 日本Androidの会（日本アンドロイドの会）
ついでにgoogle waveへのリンクも張っておきます。

参考ページ

解決方法としては、いまのところ以下の2点しかなさそうです。
・host名ではなくIP指定にする。
・UnknownHostExceptionが起こったら再起動する

・04-29 15:50:59.641: WARN/ActivityManager(74): Timeout executing service: ServiceRecord{4368f438 jp.co.haw.mixiclient/.proxy.HTTPRequestProxy}
・DeadObjectException

どちらもAlartManagerからServiceコールした際に、httpリクエストやtextのparse、DBへのinsert処理を行った際に発生しました。（処理時間は20秒～30秒）

DeadObjectExceptionはその後何故か再現しなくなったため、なんともいえないのですがTimeoutの方は再現性があったため、いろいろと調べて見たところ以下のようなメールを発見。

The activity manager assumes that your code has died, because it did
not return from the broadcast receiver in a “reasonable” amount of
time. In general, receivers should execute very very quickly, and any
long-term operations (such as *any* network operations) should be on
their own thread(s).

　呼び出し元のActivityManagerは応答を早く返してくれないと死んだものとして取り扱うため、早めに応答を返す必要があり、通信処理などの時間のかかる処理は別スレッドを立てて行うべきだとのこと。
　今回の現象では、「Timeout executing service」メッセージが出た後の処理は継続されていなかったため、おそらく応答が無かったときの「死んだものとして見なす」というのは処理が継続していようとしてなかろうと応答が無かったらそのスレッド（？）をkillしているのではないかと思います。
　実処理を別スレッドに行うようにするとTimeoutしなくなりました。

BroadCastReceiverのOnReceive()メソッドにも以下のように書かれています。

so you should never perform long-running operations in it (there is a timeout of 10 seconds that the system allows before considering the receiver to be blocked and a candidate to be killed).

長くても10秒くらいがベター、ということでしょうね。

　それにしても気になるのはDeadObjectException。
　プロセスを隔てたものにアクセスする際（Service呼び出しやContentProvider経由など）はthrowするExceptionとしてDeadObjectExceptionが指定されているので、
このメソッドの発生条件と発生した際の対応は気にかけておく必要があるのですが、
google先生に聞いてもあまり有用な情報が見つからず一旦ペンディング状態。

何か判明したら追記していこうと思います。

Android Marketのアプリの最大サイズはわかりません。明示的に何MBまで
という制限はないのかもしれませんね。
以下全くの想像ですが、Android Marketアプリもひとつのアプリなので、
デカイapkを検証するために大量のヒープが必要、というようなことがあれば、
ダウンロードできるファイルサイズは端末のヒープサイズに依存しそうな気が
しないでもないです。

ということで手元にあるHT-03Aで試してみました。

試した結果
15M(コピープロテクトで30M)・・・マーケットへの登録及びダウンロード、インストール、起動まで確認
20M・・・マーケットへの登録及びダウンロード、インストール、起動まで確認
27M・・・マーケットへの登録時のアプリチェックが終わらない

　どうやらダウンロードサイズの限界よりマーケットへの登録時のデータサイズ限界の方が低そうです。（25M付近でしょうか？）

また、コピープロテクトを使うと以下の理由により二倍のデータサイズになるのですが、アップロード時のデータサイズはapkファイルのデータサイズなので15Mのapkをコピープロテクトにしてダウンロード時に30Mにしても問題ないようです。

Why is the market listing my app as exactly twice the size of the APK I uploaded?
http://groups.google.com/group/android-developers/browse_thread/thread/9c195fc69e8b853a/857bad840711d77d

If you look at what the copy protection is doing – it dumps your
normal .apk to /data/app-private then puts a .zip in /data/app

The .apk is your originally signed one – and the .zip is you manifest,
resources and res folder. So that res folder basically doubles your
size since it contacts copies of all of the resources you also contain
in your .apk

　どちらにしてもあまりに大きいデータサイズになるのであれば、リソースはアプリ起動後に逐次SDカードの方に落としてもらう方がいいでしょうね。アプリに含めてしまうと本体に入ってしまうので元々少ない容量を圧迫してしまいます。

　実際に表示された色はswitch文のそれぞれのcaseにコメント文として書いてあります。

Notification notif = new Notification();
Spinner spinner = (Spinner)findViewById(R.id.spinner);
int index = spinner.getSelectedItemPosition() + 1;
switch (index) {
case 1:
	//赤
	notif.ledARGB = 0xffff0000;
	break;
case 2:
	//緑
	notif.ledARGB = 0xff00ff00;
	break;
case 3:
	//青
	notif.ledARGB = 0xff0000ff;
	break;
case 4:
	//点滅しない
	notif.ledARGB = 0xff000000;
	break;
case 5:
	//本来は黄色のはずだが・・・朱色？
	notif.ledARGB = 0xffffff00;
	break;
case 6:
	//紫
	notif.ledARGB = 0xffff00ff;
	break;
case 7:
	//水色
	notif.ledARGB = 0xff00ffff;
	break;
case 8:
	//白のはずだけど、青紫。
	notif.ledARGB = 0xffffffff;
	break;
case 9:
	//case 1の赤と変わらず。
	notif.ledARGB = 0x99ff0000;
	break;
case 10:
	//case 1の赤と変わらず。
	notif.ledARGB = 0x33ff0000;
	break;
default:
	break;
}
notif.ledOnMS = 300;
notif.ledOffMS = 1000;
notif.flags |= Notification.FLAG_SHOW_LIGHTS;
notif.defaults |= Notification.DEFAULT_LIGHTS;

NotificationManager nm = (NotificationManager)getSystemService(Context.NOTIFICATION_SERVICE);

nm.notify(R.string.app_name, notif);

　結果としては、基本的な色は大丈夫なんですが何故か黄色が駄目で、白色もやっぱり駄目でした。また、ARGBなのでアルファ値も変更してみたんですが、変化が見られません。

　LEDで表現できる色はデバイスによるので、どの端末でも同じ色で表現したいのであれば、なるべく3原色に限定して使用した方がいいのかもしれません。

・AndroidTestCase
　Focus2AndroidTestのjavadocには以下のように書いてあります。

/**
* This exercises the same logic as {@link Focus2ActivityTest} but in a lighter
* weight manner; it doesn’t need to launch the activity, and it can test the
* focus behavior by calling {@link FocusFinder} methods directly.
*
* {@link Focus2ActivityTest} is still useful to verify that, at an end to end
* level, key events actually translate to focus transitioning in the way we expect.
* A good complementary way to use both types of tests might be to have more exhaustive
* coverage in the lighter weight test case, and a few end to end scenarios in the
* functional {@link android.test.ActivityInstrumentationTestCase}. This would provide reasonable
* assurance that the end to end system is working, while avoiding the overhead of
* having every corner case exercised in the slower, heavier weight way.
*
* Even as a lighter weight test, this test still needs access to a {@link Context}
* to inflate the file, which is why it extends {@link AndroidTestCase}.
*
* If you ever need a context to do your work in tests, you can extend
* {@link AndroidTestCase}, and when run via an {@link android.test.InstrumentationTestRunner},
* the context will be injected for you.
*
* See {@link com.example.android.apis.app.ForwardingTest} for an example of an Activity unit test.
*
* See {@link com.example.android.apis.AllTests} for documentation on running
* all tests and individual tests in this application.
*/

　要約すると、ActivityInstrumentationTestCase2よりライトなテストを行うのがAndroidTestCaseであり、Activityをlaunchすることなく、テストを行えるのが特徴で、FocusFinderクラスを使用することにより、UIに対して直接フォーカス移動等のテストが行える、ということのようです。

　まず、setUpメソッドを見てみます。
・com.example.android.apis.view.Focus2AndroidTest

public class Focus2AndroidTest extends AndroidTestCase {

    private FocusFinder mFocusFinder;

    private ViewGroup mRoot;

    private Button mLeftButton;
    private Button mCenterButton;
    private Button mRightButton;

    @Override
    protected void setUp() throws Exception {
        super.setUp();

        mFocusFinder = FocusFinder.getInstance();

        // inflate the layout
        final Context context = getContext();
        final LayoutInflater inflater = LayoutInflater.from(context);
        mRoot = (ViewGroup) inflater.inflate(R.layout.focus_2, null);

        // manually measure it, and lay it out
        mRoot.measure(500, 500);
        mRoot.layout(0, 0, 500, 500);

        mLeftButton = (Button) mRoot.findViewById(R.id.leftButton);
        mCenterButton = (Button) mRoot.findViewById(R.id.centerButton);
        mRightButton = (Button) mRoot.findViewById(R.id.rightButton);
    }

　ここで行っているのは、FocusFinderのインスタンスを作成し、コンテキストからテスト対象のActivityのViewGroupのレイアウトを設定することです。Activityのライフサイクルを通さないので全部自前でやる必要がある、ということですね。

　テストは以下のようになります。

    @SmallTest
    public void testGoingRightFromLeftButtonJumpsOverCenterToRight() {
        assertEquals("right should be next focus from left",
                mRightButton,
                mFocusFinder.findNextFocus(mRoot, mLeftButton, View.FOCUS_RIGHT));
    }

　FocusFinderによって次のフォーカスに移動させ、その移動先がLeftButtonであることを確認しています。

・ということで。
　フォーカスの簡単な確認であればAndroidTestCaseでテストできますが、Activityのライフサイクルもテストしたい場合はActivityInstrumentationTestCase2でテストする、という形ですね。

　まずクラス関係は以下のようになってます。

　この中でActivityクラスのテストに用いるのが、

1. ActivityTestCase
2. ActivityInstrumentationTestCase2
3. ActivityUnitTestCase

あたりの様子。今回はActivityInstrumentationTestCase2に注目してみます。

・com.example.android.apis.view.Focus2ActivityTest

　ApiDemosのFocus2ActivityTestはActivityInstrumentationTestCaseを継承したテストクラスです。ただ、現状ActivityInstrumentationTestCaseはdeprecatedになっているため、本来はActivityInstrumentationTestCase2にすべきですね。

public class Focus2ActivityTest extends ActivityInstrumentationTestCase<Focus2> {
    public Focus2ActivityTest() {
        super("com.example.android.apis", Focus2.class);
    }

Focus2クラスに対してのテストのため、上記のように宣言します。
Focus2は「leftButton」、「centerButton」、「rightButton」の３つのボタンが並んでいるAcitivityです。

・AndroidManifest.xml

    <application>
        <uses-library android:name="android.test.runner" />
    </application>
    <instrumentation android:name="android.test.InstrumentationTestRunner"
                     android:targetPackage="com.example.android.apis"
                     android:label="Tests for Api Demos."/>

Manifestファイルにテスト対象のパッケージを登録します。

※InstrumentationTestRunnerについてはリファレンスにしっかり書いてあるので、ここでは特に書かないことにします。

    @MediumTest
    public void testGoingRightFromLeftButtonJumpsOverCenterToRight() {
        sendKeys(KeyEvent.KEYCODE_DPAD_RIGHT);
        assertTrue("right button should be focused", mRightButton.isFocused());
    }

　右キーを押下したときにフォーカスがrightbuttonに移動していることを確認するテストです。
　ここで使用しているsendKeysメソッドはInstrumentationTestCaseのメソッドです。
　実はメインスレッドでActivityを操作することはできないらしく、このsendKeysメソッドを呼び出したとき、内部でUI操作用のスレッドを立て、そのスレッドでイベントキーを発行し、処理が終わり、アイドル状態になるまでwaitしています。

　それが分かるのが次のテストケースです。

    @MediumTest
    public void testGoingLeftFromRightButtonGoesToCenter()  {
        // Give right button focus by having it request focus.  We post it
        // to the UI thread because we are not running on the same thread, and
        // any direct api calls that change state must be made from the UI thread.
        // This is in contrast to instrumentation calls that send events that are
        // processed through the framework and eventually find their way to
        // affecting the ui thread.
        getActivity().runOnUiThread(new Runnable() {
            public void run() {
                mRightButton.requestFocus();
            }
        });
        // wait for the request to go through
        getInstrumentation().waitForIdleSync();

        assertTrue(mRightButton.isFocused());

        sendKeys(KeyEvent.KEYCODE_DPAD_LEFT);
        assertTrue("center button should be focused", mCenterButton.isFocused());
    }

　このテストケースでは、イベントキーを送るのではなく、直接rightbuttonにフォーカスをあてますが、その処理をUI用スレッドにて行っています。

        // affecting the ui thread.
        getActivity().runOnUiThread(new Runnable() {
            public void run() {
                mRightButton.requestFocus();
            }
        });

　別スレッドにて操作を行っているため、操作が完了しアイドル状態になるまで、下記メソッドをコールして同期させています。

        // wait for the request to go through
        getInstrumentation().waitForIdleSync();

　Activityに対する操作は別スレッドにて行うというのを意識しておかないと、単体テスト時に泥沼にはまりそうですね。

1. アイコンの変更
2. コミュニティ（トピック）の内部ブラウザ化
3. コメント機能（コミュニティのイベントを除く）

です。
コメントは各記事にてメニューボタンを押下し、「コメントを書く」を選択してください。