先のエントリでは問題なさそうと書いておきながら、いざデバッグと思いAVDを起動しようとしたらエラーに遭遇。

2011/10/20 23:35 なんとか解決できたか。対応についてはエントリの末尾に記述有り。
マシン環境は関係なかった。
トラブっている環境はWindows7 64bit Home Premium、AMD Phenom II x6、メモリ8GB、Java6 u27、Eclipse Indigo、Android sdk r14(インストール先はC:\Android\android-sdk)。
次の環境ではどうやら大丈夫そう。
MacBook 2008 later、Lion、Java6、Eclipse Indigo、Android sdk r14


AVDにパッケージを転送しようとするフローの中で次のようなメッセージのエラーが発生した。
Error generating final archive: java.io.FileNotFoundException: C:\devel\MyProject\bin\resources.ap_ does not exist
パッケージ再構成時にファイルが不足しているようだ。
ところがこのエラー、プロジェクトのリフレッシュやクリーンを行っても解決しない。

素直に検索したところ、いつものごとくstackoverflow.comがヒット。
第一に行うべきはプロジェクトのクリーンという回答だったが先述したとおり自分の環境では駄目。
先を読み進めていくと次のような回答があった。
I created an empty text file under C:\Users\me\workspace\project\bin\resources.ap_
単純な話でファイルが足りないと言われているから同名の空ファイルを作成するという対応だ。
手順も簡単なので試してみる…ビンゴ!
見事に解決。
(結果的にはこの対応は見当違い、というか発生していた事象が別の原因の結果だったと思われる。)

喜んでいたら次なる罠が。
AVDがANDROIDロゴを表示する段階から先へ進まない。動かない。
10分ほど放置してみたが変わらず。
SDK自体はクリーンインストールなので、古いSDKの時の設定ファイル等が悪さをしているのかも。
これから調査。

2011/10/20 13:18
ログを見ると、どうもapkファイルの作成で問題が出ているらしい。
その結果としてAVDへ転送するファイルが不正であると判断されているっぽい。
なんと実機への転送もできない。
プロジェクトのクリーンを行うと先述のファイルが足りないエラーが再度発生する。

他の方のブログを見ると動いているようなので、環境依存のようだ。
悩ましい。

r14の変更点を見ると確かにビルドフェーズの仕様変更が行われているようなので、その影響が出ていると思われる。引き続き調査。

14:36
SDKをいったん削除の上、再インストール中。
今度はインストール先を「Program Files (x86)」の下では無く、ルート直下に「\Android\android-sdk」としてみた。
ログを見ていたらダウンロードファイルのサイズエラーが発生している。一度目も確かに何かの表示があったのをよく確かめもせずにスルーしていたわけだが、何か影響しているのかもしれない。

14:59
エラーが出ていたパッケージはリスト上インストールされていることになっていたので一度削除。
その後、再ダウンロードしたら今度はエラー無くインストールできた。
AVDのプロファイルも一度削除の上で作り直し。
起動するかどうか確認中。…どうやら駄目な気配。
ネットではAVDが重くなったという報告もあるのでしばらく待つか。

ホーム画面までは進むが、その直後にリセットがかかりANDROIDロゴの表記に戻って進まなくなる状態に陥った。
相変わらずapkが正しく生成されていないようでもあるので別原因か。

16:23
またまたr14をアンインストール。
手元に残っていたr12のインストーラを使いsdkフォルダを用意。マネージャを起動。
リストにはr14への更新パッケージの表示…結局r14を落とすしか無いらしい。orz
仕方が無いのでr14に更新したうえで各種パッケージを導入という手順を踏む。

う〜ん困った。
ant関連の設定ファイル名とかが変わっていることは影響しているのだろうか?

20:02
相変わらず駄目。
一つ分かったこと2.2ベースのAVDはANDROIDロゴ表示で固まる感じだが、4.0ベースのAVDはホーム画面までこぎ着ける。

ライブラリを参照するケースでおかしいかもと、試しにHello Worldな新規プロジェクトを作成しAVDの起動を試みるもエラー。
やはりパッケージの作成で問題が発生している模様。

20:27
MacBookの方で試してみたがAVDは普通に起動する。
まさかとは思うがAMDのCPUと相性が悪いなんてことはないだろうな。そんなことはなかった。
eclipse自体をインストールし直してみるかな。

21:35
環境変数をミスっていることを発見し修正。
するとadb関連でエラーが出始めた…。インストール時にどこかで情報を掴んでしまっているらしい。
いきさつ不明なのでsdkを再インストール。時間節約のためチェックに使うAPIレベルのみをインストールするよう選択。
そして再度AVDの起動。…やはり駄目だ。
少なくとも2.2ベースのAVDは動かない。
相変わらずapkが正しく生成されていないというのが問題っぽい。

手詰まり感が出てきたがクリーンな状態のEclipseへプラグインを入れるところから再度試すことにする。

21:50
くっ。駄目だ。
ひとまず実機転送を試したが、次のようなエラーがでる。
Installation failed due to invalid APK file!

ネットを検索したが、今のところ関連しそうな回答を見つけ切れていない。
ウィルス対策ソフトが関係しているか?結果的に自分の環境では関係なかった。

22:23
進展あり
比較検証は基本。最初に試せよという話になってしまうが、新規ワークスペースを用意してHelloWorldなプロジェクトを作成。
その結果は
  • 2.2ベースのAVDで問題なく可動
  • 実機転送も問題なく可動
といったところ。つまり期待通り動作している!
次のステップはこのワークスペースに既存のプロジェクトをコピーして試してみようと思う。

22:32
既存のプロジェクトを先ほど用意したワークスペースへコピーして試してみた。
その結果
  • 2.2ベースのAVDで問題なく可動
  • 実機転送も問題なく可動
どうやらワークスペースが保持している情報に何か問題があるようだ。
地道に違いを探していくことにする。

22:42
既存のワークスペースから当面必要ないプロジェクトを削除する。
そして前項で使用した新規ワークスペースにて動作を確認出来たプロジェクトを実行してみる。
結果、実機転送アウト。というかやはりパッケージの作成に失敗しているようだ。
このプロジェクトをそのままコピーしただけで新規ワークスペース側で動かすことが出来ている。つまりプロジェクトが保持する情報には基本的には問題がないと推測する。

22:59
Eclipseを終了した上で、トラブっているワークスペースの「.metadata」を別フォルダへ移動、つまりこのワークスペースの設定を初期化するわけだ。(移動であって削除していないのは後で元に戻すため)
Eclipseを立ち上げる。「.metadata」が無いためプロジェクトが何も登録されていない状態で起動することになる。
ここに検証対象のプロジェクトをインポートして起動する。(ワークスペースの情報が初期状態になっているわけだからインポートが必要)
その結果
  • 2.2ベースのAVDで問題なく可動
  • 実機転送も問題なく可動
期待通り動作した!
うむ、sdkの更新により何かしらワークスペースの設定が不整合を起こしていたのが原因らしいことがほぼ確定。

このワークスペースはHelios環境から引き継いだもので、今や使用していないプラグイン情報も残ってしまっているというもの。「.metadata」の中はかなりごちゃごちゃとしていた。

ひとまず回避策が見えたので、ワークスペースの設定を変えることで復旧が出来ないかどうか試してみよう。

23:29
移動していた.metadataを復活させてEclipseを再起動してPreferencesをいくつか確認してみる。

次の手順を踏むと.metadataを削除せずとも回復できるようだ。
  • Window→Preferences→Java→Compiler→JDK ComplianceのCompliance levelを一度「1.5」へ変更してApply。
  • Auto buildに設定されている場合はおそらくビルドエラーが発生するが気にせずlevelを再び「1.6」へ変更しApply。(Java7の人は1.7を選ぶことになるのかな?)
  • OKを押してPreferencesダイアログは閉じる。
私の環境ではこの手順で従来のワークスペースのまま、無事にアプリケーションのデバッグができる状態を復元できた。
上記の手順はなんと言うことは無い、違うワークスペースにプロジェクトを読み込んでエラーが発生した場合と同じ対応だ。なぜこの対応で問題が解決するのかはよく分からないが、ひとまず対応完了とする。

なんだか勘所が悪いせいですごく長い戦いになってしまった。

r14ではant関連のファイル名が変更になっていたりするため、後日コマンドラインでのビルド手段を再確認したい。