Android* x86 アプリケーションのデバッグ方法とツール

2014年3月17日

Cocos2d-x を使用してマルチプラットフォーム・ゲームを開発する

この記事は、インテル® デベロッパー・ゾーンに掲載されている「How to debug an App for Android* x86 and the tools to use」(http://software.intel.com/en-us/android/articles/how-to-debug-an-app-for-android-x86-and-the-tools-to-use) の日本語参考訳です。

1. はじめに

Android* 開発者は、設計からコーディング、トラブルシューティングまでさまざまな役割をこなしています。コードにバグはつきものです。そのため、適切なデバッグツールを使って迅速に効率良く修正することが重要です。Android* 開発者にとって、効果的なデバッグ手法は不可欠でしょう。この記事は、Android* SDK および関連ツールを初めて使用される開発者向けに Android* アプリケーションのデバッグツールの概要を説明し、Android* x86 プラットフォーム上で迅速に不具合を解決できるように支援します。

2. Android* SDK のアプリケーション・デバッグ・ツール

Android* SDK には、アプリケーションのデバッグに必要なほとんどのツールが含まれています。コードのステップ実行、変数値の確認、アプリケーション実行の中断などを行う場合は、JDWP 互換デバッガーが必要になります。Eclipse* を使用している場合は、すでに JDWP 互換デバッガーが統合されているため、追加の設定は不要です。ほかの IDE を使用している場合は、IDE に統合されているデバッガーを使って特定のポートにアタッチすることで、デバイス上のアプリケーション VM と通信できます。

Eclipse* と ADT (Android* Development Tools) プラグインで開発する場合は、ビルトインの Java* デバッガーと DDMS (Dalvik Debug Monitor Server) によりアプリケーションをデバッグできます。Eclipse* 上で、デバッガーと DDMS はパースペクティブとして表示されます。パースペクティブとは、作業内容に応じてタブやウィンドウを切り替えて表示する Eclipse* のカスタムビューです。ADB (Android* Debug Bridge) ホストデーモンは Eclipse* により起動されるため、手動で起動する必要はありません。ほかの IDE でデバッグする場合は、Android* SDK に含まれる ADB、DDMS、Java* デバッガーなどのさまざまなツールを利用できます。

図 1. DDMS (Dalvik Debug Monitor Server)

開発者は DDMS を使って、プロセスのヒープ使用量の確認、オブジェクトのメモリー割り当ての追跡、エミュレーターの操作やデバイスのファイルシステムの操作、スレッドに関する情報の検証、メソッド・プロファイリング、ネットワーク監視ツール (Android* 4.0) の使用、LogCat によるコードメッセージのトレース、端末操作と場所のエミュレーションを行えます。詳細は、http://developer.android.com/guide/developing/debugging/ddms.html (英語) を参照してください。Android* SDK の Hierarchy Viewer とレイアウトツールは、レイアウト関連の問題をデバッグする上で役立ちます。

Hierarchy Viewer は、ユーザー・インターフェイス (UI) のデバッグと最適化を行います。レイアウトの View 階層が視覚的に表現され (View Hierarchy ウィンドウ)、画面が拡大表示されます (Pixel Perfect ウィンドウ)。

図 2. Hierarchy Viewer

View Hierarchy ウィンドウには、デバイスまたはエミュレーターで実行中のアクティビティーの UI を構成する View オブジェクトが表示され、 View ツリー全体の中で個々の View オブジェクトを確認できます。また、各 View オブジェクトのレンダリング・パフォーマンス・データも表示されます。ノードをクリックすると、イメージ、表示回数、レンダリング時間に関する情報を確認できます。

図 3. View オブジェクトに関する情報ウィンドウ

Pixel Perfect は、ピクセル・プロパティーを確認したり、設計図から UI をレイアウトするツールです。Pixel Perfect ウィンドウには、エミュレーターまたはデバイスの表示画面の拡大イメージが表示され、画像の個々のピクセルのプロパティーを確認できます。また、ビットマップ・デザインでアプリケーションの UI をレイアウトすることもできます。

図 4. Pixel Perfect ウィンドウ

layoutopt ツールは、アプリケーションの UI を定義する XML ファイルを解析し、View 階層の非効率的な部分を特定します。このツールを実行するには、ターミナルを開いて、SDK の tools ディレクトリーから layoutopt <xmlfiles> と入力します。<xmlfiles> 引数には、解析するリソース (未コンパイルのリソース xml ファイルまたはそれらのディレクトリー) をスペースで区切って指定します。layoutopt ツールは、指定された XML ファイルを読み込み、事前定義されたルールに応じてその定義と階層を解析します。以下は、このツールによる出力例です。

$ layoutopt samples/ samples/compound.xml 
7:23 The root-level <FrameLayout/> can be replaced with <merge/> 
11:21 This LinearLayout layout or its FrameLayout parent is useless samples/simple.xml 
7:7 The root-level <FrameLayout/> can be replaced with <merge/> samples/too_deep.xml 
-1:-1 This layout has too many nested layouts: 13 levels, it should have <= 10!
20:81 This LinearLayout layout or its LinearLayout parent is useless 
24:79 This LinearLayout layout or its LinearLayout parent is useless 
28:77 This LinearLayout layout or its LinearLayout parent is useless 
32:75 This LinearLayout layout or its LinearLayout parent is useless 
36:73 This LinearLayout layout or its LinearLayout parent is useless 
40:71 This LinearLayout layout or its LinearLayout parent is useless 
44:69 This LinearLayout layout or its LinearLayout parent is useless 
48:67 This LinearLayout layout or its LinearLayout parent is useless 
52:65 This LinearLayout layout or its LinearLayout parent is useless 
56:63 This LinearLayout layout or its LinearLayout parent is useless samples/too_many.xml 
7:413 The root-level <FrameLayout/> can be replaced with <merge/> 
-1:-1 This layout has too many views: 81 views, it should have <= 80!samples/useless.xml 
7:19 The root-level <FrameLayout/> can be replaced with <merge/> 
11:17 This LinearLayout layout or its FrameLayout parent is useless

Traceview は実行ログのグラフィカル・ビューアです。実行ログは Debug クラスを使って作成され、コードのトレース情報を記録します。Traceview はアプリケーションのデバッグとパフォーマンスのプロファイルに役立ちます。ログファイルを読み込み、データを図 5 と図 6 に示す 2 つのパネルに表示します。

図 5. 各スレッドとメソッドの開始と停止のタイミングを示す Timeline パネル

図 6. メソッドで費やされた時間のサマリーを提供する Profile パネル

dmtracedump を使って、トレース・ログ・ファイルからグラフィカル・コールスタック・ダイアグラムを生成することもできます。このツールは、グラフィカルの出力に Graphviz Dot ユーティリティーを使用しているため、dmtracedump を実行する前に Graphviz をインストールする必要があります。dmtracedump は、すべてのスタックデータを、各呼び出しをノードとするツリー・ダイアグラムとして生成します。呼び出しフロー (親ノードから子ノード) は矢印で示されます。図 7 は、dmtracedump の出力例です。

図 7. dmtracedump

3. Android* NDK のアプリケーション・デバッグ・ツール

GCC* ツールをベースにしている Android* NDK には GDB (GNU* デバッガー) が含まれており、開発者はこれを使ってプログラムを開始、中断、検証、変更することができます。Android* (および組込み) デバイス上では、GDB はクライアント/サーバーモードで構成されます。プログラムはデバイス上でサーバーおよびリモートクライアントとして動作します。開発者のワークステーションは、プログラムに接続してローカル・アプリケーションと同様のデバッグコマンドを送ります。GDB 自体はコマンドライン・ユーティリティーなので、手動で使用するのはやや面倒です。幸い、ほとんどの IDE、特に CDT は GDB に対応しています。そのため、Eclipse* から直接ブレークポイントを追加したり、プログラムを検証することができます。ただし、適切な設定が必要です。

Eclipse* では、テキストエディターの左余白をクリックすることで、Java* や C/C++ ソースファイルにブレークポイントを容易に挿入できます。Java* ブレークポイントは、Android* Debug Bridge によりデバッグを管理する ADT プラグインでそのまま動作します。もちろん、Android* に対応していない CDT では動作しません。このため、NDK の GDB を使用してネイティブ Android* アプリケーションをデバッグするように CDT を設定しない限り、ブレークポイントを挿入しても何も起こりません。デバッガーのサポートは、NDK のバージョンが上がるたびに向上しています (例えば、以前はネイティブスレッドのデバッグができませんでした)。NDK R5 は (そして R7 も) まだ完全とは言えませんが、以前よりも使いやすくなっています。ここでは、NDK を使ってネイティブ・アプリケーションをデバッグする方法を示します。

最初に、次のステップに従って、アプリケーションでデバッグモードを有効にします。

Android* プロジェクト (アプリケーションのマニフェスト AndroidManifest.xml) でデバッグフラグを有効にします。これは重要なことですが、忘れやすいので注意してください。また、ネイティブコード用の適切な SDK バージョンを使用してください。
```
<?xml version="1.0" encoding="utf-8"?> 
<manifest ...> 
<uses-sdk android:minSdkVersion="10"/> 
<application ... android:debuggable="true"> 
... 
```
マニフェストでデバッグフラグを有効にすると、ネイティブコードで自動的にデバッグモードになります。ただし、APP_OPTIM フラグもデバッグモードを制御します。このフラグを Android.mk に手動で設定した場合、値が (リリースではなく) デバッグに設定されていることを確認するか、フラグを削除します。
```
APP_OPTIM := debug  
```
次に、デバイスに接続する GDB クライアントを設定します。プロジェクトを再コンパイルして、デバイスを接続するかエミュレーターを起動します。そして、アプリケーションを実行します。アプリケーションがロードされていることを確認します。次のコマンド (Windows* の場合は cygwin) を使用してプロセスをリストし、アプリケーションの PID が利用可能であることを確認します。
```
$ adb shell ps |grep gl2jni
```
次のような 1 行の結果が返されます。
```
app_75 13178 1378 201108 68672 ffffffff 80118883 S com.android.gl2jni
```
ターミナルウィンドウを開いてプロジェクト・ディレクトリーに移動し、 ndk-gdb コマンドを実行します (Android* NDK フォルダー、例えば android-ndk-r8 に含まれています)。
```
$ ndk-gdb  
```
obj\local\x86 ディレクトリー (ARM デバイスの場合は obj\local\armeabi ディレクトリー) に 3 つのファイルが作成されます (メッセージは表示されません)。
- gdb.setup: GDB クライアント用に生成された構成ファイルです。
- app_process: このファイルはデバイスから直接取得されます。システム実行形式ファイルで、システムのスタートアップ時に起動され、新しいアプリケーションを開始するためにフォークされます。GDB がマークを検索する場合は、この参照ファイルが必要です。この場合は、アプリケーションのバイナリー・エントリー・ポイントです。
- libc.so: このファイルもデバイスから取得されます。GDB によって使用される Android* 標準 C ライブラリー (bionic) で、実行時に作成されるすべてのネイティブスレッドを追跡します。
プロジェクト・ディレクトリーで obj\local\x86\gdb.setup をコピーして名前を gdb2.setup に変更します。ファイルを開いて、次の行を削除します。
```
target remote :5039  
```
Eclipse* のメインメニューで [Run (実行)] > [Debug Configurations… (デバッグ構成…)] を選択して、C/C++ アプリケーション項目に新しいデバッグ構成 GL2JNIActivityDefault を作成します。この構成は、コンピューター上で GDB クライアントを開始して、デバイス上で実行している GDB サーバーと接続します。
[Main (メイン)] タブで、[Browse (参照)] ボタンを使用して [C/C++ Application (C/C++ アプリケーション)] が obj\local\ x86\app_process を指すように設定します (絶対パスまたは相対パスを使用できます)。

図 8. C/C++ アプリケーション用のデバッグ構成
ウィンドウ下部にある [Select other… (ほかを選択…)] リンクを使用してランチャータイプを Standard Create Process Launcher (標準作成プロセスランチャー) に変更します。

図 9. お気に入りのランチャーの選択
[Debugger (デバッガー)] タブに移動して、[Debugger (デバッガー)] を gdbserver に、[GDB debugger (GDB デバッガー)] を android-ndk-r8\toolchains\x86-4.4.3\prebuilt\windows\bin\i686-android-linux-gdb.exe (ARM の場合は android-ndk-r8\toolchains\arm-linux-androideabi-4.4.3\prebuilt\linux-x86\bin\arm-linux-androideabi-gdb) に、そして [GDB command file (GDB コマンドファイル)] を \obj\local\x86 (ARM の場合は obj\local\armeabi\ ) にある gdb2.setup ファイルに設定します (絶対パスまたは相対パスを使用できます)。

図 10. デバッガー設定パネル
[Connection (接続)] タブに移動して、[Type (タイプ)] を TCP に設定します。[Host name or IP address (ホスト名または IP アドレス)] および [Port number (ポート番号)] のデフォルト値 (localhost, 5039) は変更しません。

図 11. デバッガー設定パネルの接続設定
デバイス上の GDB サーバーを実行するように Eclipse* を構成します。android-ndk-r8\ndk-gdb をコピーしてテキストエディターで開き、次の行を探します。
```
$GDBCLIENT -x `native_path $GDBSETUP`
```
Eclipse* で GDB クライアントを実行するため、この行をコメントアウトします。
```
#$GDBCLIENT -x `native_path $GDBSETUP`
```
Eclipse* のメインメニューで [Run (実行)] > [External Tools (外部ツール)] > [External Tools (外部ツール)] > [Configurations… (構成…)] を選択して、新しい構成 GL2JNIActivity_GDB を作成します。
この構成は、デバイス上の GDB サーバーを起動します。
[Main (メイン)] タブの [Location (位置)] に、変更した android-ndk-r8 の ndk-gdb を指定します。作業ディレクトリーをアプリケーションのディレクトリーに設定します。
必要に応じて、[Arguments (引数)] テキストボックスを設定します。
- verbose: Eclipse* コンソールに詳細な情報を表示します。
- force: 以前のセッションを自動的に kill します。
- start: アプリケーションにアタッチする代わりにアプリケーションを開始します。このオプションは、Java* ではなくネイティブコードをデバッグする場合に設定します。
図 12. 外部ツールの設定
通常どおりにアプリケーションを起動します。
アプリケーションが起動したら、コンソールから直接または外部ツール構成 GL2JNIActivity_GDB を起動して、デバイス上の GDB サーバーを起動します。GDB サーバーは、リモート GDB クライアントから送られたデバッグコマンドを受け取り、アプリケーションをローカルにデバッグします。
jni\gl_code.cpp を開き、テキストエディターの左余白をダブルクリックして (または右クリックして [Toggle breakpoint (ブレークポイントの切り替え)] を選択して) setupGraphics にブレークポイントをセットします。

図 13. ブレークポイントの設定
最後に、デフォルトの C/C++ アプリケーション構成 GL2JNIActivity を起動して GDB クライアントを開始します。Eclipse* CDT から GDB サーバーにソケット接続でデバッグコマンドが渡されます。開発者から見ると、ローカル・アプリケーションをデバッグしているように見えます。

グラフィックスのパフォーマンスをデバッグする特殊なツールもあります。インテル® GPA システム・アナライザーは、インテル® アーキテクチャー・ベースの Android* デバイスに対応したインテル® グラフィックス・パフォーマンス・アナライザー (インテル® GPA) の 1 つで、OpenGL* ES のワークロードを最適化するアプリケーション・エンジニアとドライバー・エンジニア向けのツールです。

このセクションでは、インテル® GPA と USB 接続された Android* デバイスの構成および使用方法について説明します。Android* デバイスに接続されると、インテル® GPA システム・アナライザーは OpenGL* ES API、CPU、および GPU のパフォーマンス要件を提供します。また、OpenGL* ES アプリケーションのパフォーマンス解析を支援するため、複数のグラフィックス・パイプライン・ステートのオーバーライドも提供します。

Android* x86 ベースのデバイス上でインテル® GPA システム・アナライザーを使用するには、ドキュメントでターゲットマシンとファームウェア/バージョンを確認する必要があります。

要件の収集を開始するには、インテル® GPA システム・アナライザーをクライアント・システムにインストールしてターゲットデバイスに接続する必要があります。

Windows*/Linux* クライアント・マシンにインテル® GPA 2012 R3 をインストールします。
インテル® GPA システム・アナライザーを起動します。
Android* デバイスが USB ケーブルを使用してクライアント・システムに接続されていることを確認します。
クライアント・システムがターゲットデバイスを検出するまで、10 秒ほど待ちます。検出したデバイスがダイアログに表示されます。ターゲットデバイスのリストは 5 ～ 6 秒ごとに更新されます。
接続するデバイスを選択して、[Connect (接続)] をクリックします。必要なコンポーネントがターゲットデバイスにコピーされ、インストールされたアプリケーションのリストが生成されます。接続プロセスを中断するには、[Stop (停止)] をクリックします。

図 14. 接続されているデバイスの選択
リストからアプリケーションを選択します。アプリケーション・リスト画面には、Android* デバイスにインストールされているすべてのユーザー・アプリケーションとシステム・アプリケーションが表示されます。

図 15. アプリケーションのリスト
アプリケーションが起動され、インテル® GPA システム・アナライザーのウィンドウにデータが表示されます。
別のアプリケーションに切り替えるには、[Back (戻る)] をクリックします。実行中のアプリケーションは強制的に閉じられることに注意してください。
別のターゲットデバイスに切り替えるには、[Back (戻る)] をクリックします。
PowerVR* グラフィックス・アーキテクチャーは、3D アプリケーションのデータをレンダリングされたイメージに変換する、タイル・アクセラレーター (TA)、イメージ合成プロセッサー (ISP)、テクスチャー & シェーディング・プロセッサー (TSP) の 3 つのコアモジュールから構成されます。[GPU] グループのインテル® GPA の要件は、これらのコアモジュールの 1 つに対応します。また、リストの要件の順序は、グラフィックス・パイプラインのコアモジュールの順序に依存します。

図 16. インテル® GPA システム・アナライザー

Perf は、Linux* 2.6.30 以降で利用できる便利なツールで、ハードウェアおよびソフトウェア関連のパフォーマンス解析を行います。Android* は Linux* 上でビルドされていますが、Android* にはほかの多くのコンポーネントやライブラリーと同様に perf が含まれていません、そのため、静的にビルドされた perf を /system/bin/ 以下に配置する必要があります。perf の概要、基本操作、チュートリアルについては、https://perf.wiki.kernel.org/index.php/Main_Page (英語) を参照してください。
Traceview で Java* コードのパフォーマンス情報を取得し、perf で図 17 に示すネイティブ/システムレベル・コードのパフォーマンス情報を取得できます。

図 17. パフォーマンス統計

図 18. 関数呼び出しスタック

UxTune は pyTimeChart ツールを拡張したもので、Android* ユーザー・インターフェイスの解析と最適化を支援します。
UxTune は、以下の機能を提供します。

垂直相関: 複数のレイヤーにわたるシステムイベントをユーザーレベルのアクティビティー (イベント、ジェスチャー、フレームなど) に関連付けます。
水平相関: 異なるシステム・エンティティー間のランタイム・アクティビティー (スレッドによるガベージ・コレクションの起動など) を関連付けます。
pyTimeChart に基づいて可視化します。

UxTune で応答性を解析する場合、以下に示す Android* システムの重要なプロセス (pyTimeChart の行に表示される) について理解しておく必要があります。

InputReader 行: すべてのタッチイベントとその座標を表示します。これらのイベントは InputDispatcher に送られます。
InputDispatcher 行: シリアル・タッチ・イベントをパックして、アプリケーションの uiThread に送ります。
uiThread 行: InputDispatcher から受け取ったパッケージの先頭のタッチイベントを表示します。uiThread は、特定のアクションに応じて Surface を描画 (レンダリング) します。“D” は、描画プロセスを表します。
Surface 行: uiThread は、描画の開始時に Surface をロックし、描画の終了時にロックを解除します。“S” と “E” は、アプリケーション・レンダリングの開始と終了を表します。
SurfaceFlinger 行: レンダリングが完了すると、アプリケーションは SurfaceFlinger に画面の合成と更新を通知します。“S” は、SurfaceFlinger がアプリケーション要求の処理を開始したことを表し、“E” は合成処理が完了したこと (フレームバッファーの入れ替えが終わったこと) を表します。

図 19. UxTune 解析ウィンドウ

Meter-FPS はシステムの FPS 値を測定するツールです。グラフィックス処理用のパスから、最大フレーム時間、フレーム時間の差異、時間のかかるフレームの数、フレーム・ドロップ・レートなどのほかの指標を含む各フレームのログを採取します。FPS モニターには 2 つのパターンがあります。リアルタイム・パターンは、実行中のすべてのアプリケーションのリアルタイム表示 FPS です。測定パターンは、ユーザー定義の開始/終了のタイミングで FPS とほかのパラメーターを測定します。このツールを使用するには、デバイスのルートを指定する必要があります。
環境変数を設定します。

setprop debug.graphic_log 1
stop zygote
start zygote

図 20 の設定画面で、デバッグターゲットの設定を行います。

図 20. Meter-FPS の設定

リアルタイム・パターンのモニターボタンをクリックすると、 FPS ツールは実行中のすべてのアプリケーションをモニターして、画面上のフローティング・ウィンドウに FPS 情報を表示します。

図 21. Meter-FPS のリアルタイム・パターン

測定パターンのモニターボタンをクリックすると、 “Click to start …” というメッセージを示すフローティング・ウィンドウが表示され、これをクリックするとモニターが開始されます。

図 22. Meter-FPS の測定パターン 1

測定パターンが実行されます。

図 23. Meter-FPS の測定パターン 2

フローティング・ウィンドウをクリックすると、モニターが停止し、結果が表示されます。

図 24. Meter-FPS 解析結果のリスト

各項目をクリックすると、詳細なログが表示されます。

図 25. Meter-FPS 解析の詳細なログ

参考文献 (英語)

http://developer.android.com/guide/developing/debugging/index.html
http://www.eclipse.org/sequoyah/documentation/native_debug.php
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-development/
http://mhandroid.wordpress.com/2011/01/23/using-eclipse-for-android-cc-debugging/
http://packages.python.org/pytimechart/userguide.html
https://perf.wiki.kernel.org/index.php/Main_Page

著者紹介

Xiaodong Wang
インテルコーポレーションのソフトウェア & サービスグループのアプリケーション・エンジニア。インテル・ベースの Android* OS プラットフォーム向け ISV イネーブリングに従事しています。PRC Plus プロジェクト (Android* タブレットの ISV イネーブリング) をサポートし、テクニカル・インターフェイス分野における Top 50 NDK アプリケーションへと導きました。最近は、インテルの革新的なプロジェクトの数々に取り組んでおり、開発プロセスで重要な役割を担っています。そのうちの 1 つは IDF の基調デモンストレーションに選ばれ、技術サポートを通してプロジェクトの成功に貢献しました。前職は、MediaTek 社でフレームワークおよびアプリケーション開発に従事していました。北京大学で修士号を取得し、シンガポールの南洋理工大学で客員学者として研究中に「IEEE Transactions on Computers」という技術論文を発表しています。LBS、NFC、AR などのモバイル・インターネット・テクノロジーと革新的な設計に興味を持っています。

著作権と商標について

本資料に掲載されている情報は、インテル製品の概要説明を目的としたものです。本資料は、明示されているか否かにかかわらず、また禁反言によるとよらずにかかわらず、いかなる知的財産権のライセンスを許諾するものではありません。製品に付属の売買契約書『Intel’s Terms and Conditions of Sale』に規定されている場合を除き、インテルはいかなる責任を負うものではなく、またインテル製品の販売や使用に関する明示または黙示の保証 (特定目的への適合性、商品適格性、あらゆる特許権、著作権、その他知的財産権の非侵害性への保証を含む) に関してもいかなる責任も負いません。

インテルによる書面での合意がない限り、インテル製品は、その欠陥や故障によって人身事故が発生するようなアプリケーションでの使用を想定した設計は行われていません。

インテル製品は、予告なく仕様や説明が変更される場合があります。機能または命令の一覧で「留保」または「未定義」と記されているものがありますが、その「機能が存在しない」あるいは「性質が留保付である」という状態を設計の前提にしないでください。これらの項目は、インテルが将来のために留保しているものです。インテルが将来これらの項目を定義したことにより、衝突が生じたり互換性が失われたりしても、インテルは一切責任を負いません。この情報は予告なく変更されることがあります。この情報だけに基づいて設計を最終的なものとしないでください。

本資料で説明されている製品には、エラッタと呼ばれる設計上の不具合が含まれている可能性があり、公表されている仕様とは異なる動作をする場合があります。現在確認済みのエラッタについては、インテルまでお問い合わせください。

最新の仕様をご希望の場合や製品をご注文の場合は、お近くのインテルの営業所または販売代理店にお問い合わせください。

本資料で紹介されている資料番号付きのドキュメントや、インテルのその他の資料を入手するには、1-800-548-4725 (アメリカ合衆国) までご連絡いただくか、http://www.intel.com/design/literature.htm (英語) を参照してください。
性能に関するテストに使用されるソフトウェアとワークロードは、性能がインテル® マイクロプロセッサー用に最適化されていることがあります。SYSmark* や MobileMark* などの性能テストは、特定のコンピューター・システム、コンポーネント、ソフトウェア、操作、機能に基づいて行ったものです。結果はこれらの要因によって異なります。製品の購入を検討される場合は、他の製品と組み合わせた場合の本製品の性能など、ほかの情報や性能テストも参考にして、パフォーマンスを総合的に評価することをお勧めします。

本資料に含まれるソフトウェア･ソース･コードはソフトウェア･ライセンス契約に基づいて提供されるものであり、その使用および複製はライセンス契約で定められた条件下でのみ許可されます。

Intel、インテル、Intel ロゴは、アメリカ合衆国および / またはその他の国における Intel Corporation の商標です。

* その他の社名、製品名などは、一般に各社の表示、商標または登録商標です。

コンパイラーの最適化に関する詳細は、最適化に関する注意事項を参照してください。

x86 上で Android* アプリを最適化するためのヒントとコツこの記事は、インテル® デベロッパー・ゾーンに掲載されている「Tips and Tricks to Optimize Android Apps on x86」 […]
インテル® INDE によって Android アプリケーションを作成する 6 つの方法この記事は、インテル® デベロッパー・ゾーンに公開されている「6 Ways Intel® INDE Makes the Android App a Snap」 […]
Android* OS 上でのリモート・アプリケーション・デバッグこの記事は、インテル® デベロッパー・ゾーンに掲載されている「Remote Application Debug on Android* OS」(http://software.intel.com/en-us/articles/application-debug-android/) の日本語参考訳です。 Android* OS […]
インテル® アーキテクチャー・ベースのプラットフォームで NDK ベースの Android* ゲーム・アプリケーションを開発および最適化するこの記事は、インテル® デベロッパー・ゾーンに掲載されている「Development and Optimization for NDK-based Android Game Application on Platforms based on Intel® Architecture」の日本語参考訳です。 Android* […]
インテル® プロセッサー・ベースのプラットフォームにおけるサードパーティー Android* アプリケーションのデバッグ・リファレンス – パート 2 この記事は、インテル® デベロッパー・ゾーンに掲載されている「Third-Party Android* Application Debug Reference on Intel® Processor-based Platforms Part […]