diff options
Diffstat (limited to 'docs/html-intl/ja')
13 files changed, 2534 insertions, 0 deletions
diff --git a/docs/html-intl/ja/guide/publishing/app-signing.jd b/docs/html-intl/ja/guide/publishing/app-signing.jd new file mode 100644 index 0000000..2d2acfa --- /dev/null +++ b/docs/html-intl/ja/guide/publishing/app-signing.jd @@ -0,0 +1,336 @@ +page.title=アプリケーションへの署名 +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + +<h2>署名の概略</h2> + +<ul> +<li>Android アプリケーションはすべて<em>署名する必要がある</em></a></li> +<li>自己署名キーで署名可能</li> +<li>アプリケーションの署名方法は重要です。このドキュメントをよくお読みください</li> +<li>開発プロセスの初期段階で署名戦略を決定します</li> +</ul> + +<h2>このドキュメントの内容</h2> + +<ol> +<li><a href="#overview">概要</a></li> +<li><a href="#strategies">署名戦略</a></li> +<li><a href="#setup">署名の基本設定</a></li> +<li><a href="#debugmode">デバッグ モードでの署名</a></li> +<li><a href="#releasemode">公開リリースへの署名</a> + <ol> + <li><a href="#releasecompile">リリース向けのコンパイル</a></li> + <li><a href="#cert">適切な秘密鍵の取得</a></li> + <li><a href="#signapp">アプリケーションの署名</a></li> + <li><a href="#ExportWizard">Eclipse ADT によるコンパイルと署名</a></li> + </ol> +</li> +<li><a href="#secure-key">秘密鍵のセキュリティ設定</a></li> + +</ol> + +<h2>関連項目</h2> + +<ol> +<li><a href="{@docRoot}tools/publishing/versioning.html">アプリケーションのバージョニング</a></li> +<li><a href="{@docRoot}tools/publishing/preparing.html">公開の準備</a></li> +</ol> + +</div> +</div> + +<p>このドキュメントでは、Android アプリケーションを携帯端末ユーザーに公開する前に署名する方法について説明します。</p> + +<h2 id="overview">概要</h2> + +<p>Android システムでは、インストールするすべてのアプリケーションに対してデジタル署名されて証明書を必要とします。この証明書の秘密鍵は、アプリケーションのデベロッパーが所持するものです。Android システムは証明書をアプリケーションの作成者の識別手段、およびアプリケーション間の信頼関係の確立手段として使用します。証明書は、ユーザーがどのアプリケーションをインストールできるかを制御するものではありません。証明書は認証機関によって署名される必要はありません。通常の Android アプリケーションは自己署名証明書を使用して正常に機能します。</p> + +<p>Android アプリケーションの署名について、次の点を理解することが重要です:</p> + +<ul> + <li>すべてのアプリケーションは<em>署名される必要があります</em>。署名されていないアプリケーションはシステムにインストールされません。</li> + <li>アプリケーションの署名に、自己署名証明書を使用できます。認証機関は不要です。</li> + <li>アプリケーションをエンド ユーザーにリリースする準備ができたら、適切な秘密鍵を使用してアプリケーションに署名する必要があります。SDK ツールで生成されたデバッグ キーで署名されたアプリケーションは、公開できません。 + </li> + <li>システムが署名証明書の有効期限を確認するのは、インストール時のみです。アプリケーションのインストール後に署名者証明書が期限切れになった場合、アプリケーションは正常な動作を継続します。</li> + <li>標準ツールである Keytool と Jarsigner を使用してキーを生成し、アプリケーションの .apk ファイルに署名できます。</li> +</ul> + +<p>Android システムは、適切に署名されていないアプリケーションをインストールせず、実行もしません。この規則は、実際のデバイスでもエミュレータでも、Android システムが実行されるすべての状況で適用されます。このため、エミュレータまたはデバイス上で実行またはデバッグする前に、アプリケーションの署名を設定する必要があります。</p> + +<p>Android SDK ツールは、デバッグ時のアプリケーション署名を支援します。「ADT Plugin for Eclipse」と「Ant ビルド ツール」では両方とも、<em>デバッグ モード</em>と<em>リリース モード</em>の 2 種類の署名モードを利用できます。 + +<ul> +<li>開発およびテスト中は、デバッグ モードでコンパイルできます。デバッグ モードでは、ビルド ツールは JDK に付属の Keytool ユーティリティを使用して、キーストアとキーを既知のエイリアスとパスワードで作成します。コンパイルのたびに、ツールはデバッグ キーを使用してアプリケーションの .apk ファイルに署名します。パスワードは既知のものなので、コンパイルのたびにツールにキーストア/キー パスワードを入力する必要はありません。</li> + +<li>アプリケーションをリリースする準備ができたら、リリース モードでコンパイルして、.apk に<span style="color:red">秘密鍵</span>で署名する必要があります。次の 2 通りの方法があります: + <ul> + <li>Keytool と Jarsigner をコマンド ラインで使用する方法。このアプローチでは、まずアプリケーションを<em>署名されていない</em> .apk にコンパイルします。次に、Jarsigner（または類似のツール）を使用して秘密鍵で .apk に手動で署名します。適切な秘密鍵を所持していない場合は、Keytool を手動で実行して独自のキーストア/キーを生成し、Jarsigner でアプリケーションに署名できます。</li> + <li>ADT Export Wizard を使用する方法。ADT プラグイン搭載の Eclipse を使用して開発している場合、Export Wizard を使用してアプリケーションをコンパイルし、秘密鍵を生成して（必要な場合）、.apk に署名できます。この作業をすべて Export Wizard を使用して 1 つのプロセスで実行できます。 + </li> + </ul> +</li> +</ul> + +<h2 id="strategies">署名戦略</h2> + +<p>アプリケーションの署名は、開発アプローチに一部影響します。特に、複数のアプリケーションをリリースする予定の場合、高い影響を与えます。 </p> + +<p>一般に、すべてのデベロッパーに推奨される戦略は、アプリケーションの予期される使用期間を通じて同じ証明書ですべてのアプリケーションに署名することです。このようにするには、複数の理由があります: </p> + +<ul> +<li>アプリケーションのアップグレード - アプリケーションのアップグレードをリリースするとき、ユーザーが新バージョンにシームレスにアップグレードできるように、アップグレードされたアプリケーションにも同じ証明書で署名します。システムがアプリケーションのアップデートをインストールする際は、新バージョンの証明書のいずれかが旧バージョンの証明書と一致する場合、システムがアップデートを許可します。一致する証明書を使用せずに署名する場合は、アプリケーションに別のパッケージ名を割り当てる必要があります。この場合、新しいバージョンがまったく新しいアプリケーションとしてインストールされます。 </li> + +<li>アプリケーションのモジュール性 - Android システムでは、アプリケーションが要求する場合、同じ証明書で署名されたアプリケーションを同じプロセスで実行できます。これにより、システムはこれらを単一のアプリケーションとして取り扱います。このようにすればアプリケーションをモジュールとして配備でき、ユーザーは必要に応じて各モジュールを個別に更新できます。</li> + +<li>許可によるコード/データ共有 - Android システムでは、署名ベースの権限付与を実施しているため、アプリケーションは指定された証明書で署名されている別のアプリケーションに機能を提供できます。同じ証明書で複数のアプリケーションに署名し、署名に基づいた権限のチェックを行うことで、アプリケーションはコードとデータを安全な方法で共有できます。 </li> + +</ul> + +<p>署名戦略を決定する際のもう 1 つの重要な検討事項として、アプリケーションの署名に使用するキーの有効期間の設定方法があります。</p> + +<ul> +<li>アプリケーションのアップグレードをサポートするには、キーの有効期間は、アプリケーションの予定される試用期間以上である必要があります。有効期間は、２５年以上であることが推奨されます。キーの有効期間が切れた場合、ユーザーはアプリケーションの新バージョンにシームレスにアップグレードできなくなります。</li> + +<li>同じキーで複数の異なるアプリケーションに署名する場合、キーの有効期間が、今後のアプリケーション スイートに追加される依存アプリケーションを含め、<em>すべてのアプリケーションのすべてのバージョンの</em>予定される使用期間を超えることを確認してください。 </li> + +<li>アプリケーションを Android マーケットに公開する予定の場合、アプリケーションの署名に使用するキーの有効期間を、2033 年 10 月 22 日以降の期限に設定する必要があります。マーケット サーバーは、新バージョンが公開されたときにユーザーがマーケット アプリケーションをシームレスにアップグレードできるよう、この要件を義務付けています。 </li> +</ul> + +<p>アプリケーションの設計時にこれらの点を考慮し、アプリケーションの署名に<a href="#cert">適切な証明書</a>を使用してください。 </p> + +<h2 id="setup">署名の基本設定</h2> + +<p>キーストアとデバッグ キーの生成をサポートするため、SDK ビルド ツールで Keytool を使用できることを初めに確認してください。たいていの場合、「JAVA_HOME」環境変数を設定して適切な JDK を参照させることで、SDK ビルド ツールで Keytool を認識できます。または、JDK バージョンの Keytool を PATH 変数に追加しても認識できます。</p> + +<p>Linux バージョンに付属されている GNU Java コンパイラで開発している場合は、gcj バージョンではなく、JDK バージョンの Keytool を使用していることを確認してください。Keytool が既に PATH に指定されている場合は、<code>/usr/bin/keytool</code> の symlink を指していることがあります。この場合は、symlink ターゲットが JDK の Keytool を指していることを確認してください。</p> + +<p>アプリケーションを公開する場合は、Jarsigner ツールをコンピュータで使用できるようにする必要があります。Jarsigner と Keytool の両方が JDK によって提供されます。 </p> + +<h2 id="debugmode">デバッグ モードでの署名</h2> + +<p>Android ビルド ツールにはデバッグ署名モードがあり、アプリケーションの開発とデバッグがスムーズに行えます。また、.apk をエミュレータまたはデバイスにインストールする際の、署名に対する Android システム要件を満たします。デバッグモードでは、SDK ツールは Keytool を呼び出してデバッグ キーストアとキーを作成します。</p> + +<p>SDK ツールは事前に指定された名前とパスワードを使用してデバッグ キーストア/キーを作成します。</p> +<ul> +<li>キーストア名 – 「debug.keystore」</li> +<li>キーストアのパスワード – 「android」</li> +<li>キーのエイリアス – 「androiddebugkey」</li> +<li>キーのパスワード – 「android」</li> +<li>CN – 「CN=Android Debug,O=Android,C=US」</li> +</ul></p> + +<p>必要に応じて、デバッグ キーストア/キーの場所および名前を変更できます。また、自分で作成したデバッグ キーストア/キーを指定することもできます。Eclipse/ADT で、[[]<strong>ウィンドウ（Windows）</strong>] > [[]<strong>設定（Prefs）</strong>] > [[]<strong>Android</strong>] > [[]<strong>ビルド（Build）</strong>] を選択します。ただし、自分で作成したデバッグ キーストア/キーは、デフォルトのデバッグ キー（上述）と同じキーストア/キー名とパスワードを使用する必要があります。</p> + +<p class="note"><strong>注:</strong> デバッグ証明書で署名した場合は、アプリケーションを<em>公開できません</em>。</p> + +<h3>Eclipse ユーザー</h3> + +<p>Eclipse/ADT で開発し、Keytool を上記のように設定してある場合は、デバッグモードにおける署名はデフォルトで有効になっています。アプリケーションを実行またはデバッグするときに、ADT は .apk にデバッグ証明書で署名し、エミュレータにインストールします。ADT が Keytool にアクセスできる場合は、ユーザーは特に操作する必要はありません。</p> + +<h3>Ant ユーザー</h3> + +<p>Ant を使用して .apk ファイルを構築する場合、デバッグ署名モードは <code>debug</code> オプションを使用することで有効になります（<code>android</code> ツールで生成された <code>build.xml</code> ファイルを使用していることが前提となります）。<code>ant debug</code> を実行してアプリケーションをコンパイルする際、ビルド スクリプトはキーストア/キーを生成し、.apk に署名します。ユーザーは操作する必要はありません。詳細は、<a href="{@docRoot}guide/developing/other-ide.html#DebugMode">その他の統合開発環境での開発: デバッグモードにおけるビルド </a> をお読みください。</p> + + +<h3 id="debugexpiry">デバッグ証明書の有効期限</h3> + +<p>デバッグ モード（Eclipse/ADT と Ant ビルドのデフォルト）でのアプリケーション署名に使用した自己署名証明書には、作成日から 365 日の有効期限が設定されます。</p> + +<p>証明書の期限が切れると、ビルド エラーが発生します。Ant ビルドでは、エラーは次のようになります:</p> + +<pre>debug: +[echo] Packaging bin/samples-debug.apk, and signing it with a debug key... +[exec] Debug Certificate expired on 8/4/08 3:43 PM</pre> + +<p>Eclipse/ADT では、Android コンソールに同様のエラーが表示されます。</p> + +<p>この問題を解決するには、<code>debug.keystore</code> ファイルを削除します。AVD のデフォルトの格納場所は、OS X と Linux の場合は <code>~/.android/avd</code>、Windows XP の場合は <code>C:\Documents and Settings\<user>\.android\</code>、Windows Vista の場合は <code>C:\Users\<user>\.android\</code> です。</p> + + +<p>次にビルドを行うと、ビルド ツールは新しいキーストアとデバッグ キーを再度生成します。</p> + +<p>開発コンピュータがグレゴリオ暦以外のロケールを使用している場合、ビルド ツールが誤って期限切れのデバッグ証明書を生成することがあります。このため、アプリケーションをコンパイルしようとするとエラーが発生します。解決策については、トラブルシューティング トピックの <a href="{@docRoot}resources/faq/troubleshooting.html#signingcalendar">ビルド ツールが期限切れのデバッグ証明書を生成するため、アプリケーションがコンパイルできない</a> をご覧ください。 </p> + + +<h2 id="releasemode">公開リリースへの署名</h2> + +<p>アプリケーションを他のユーザーに公開する準備ができたら、次のことを行う必要があります:</p> +<ol> + <li>アプリケーションをリリース モードでコンパイルする</li> + <li>適切な秘密鍵を取得する</li> + <li>アプリケーションに秘密鍵で署名する</li> +</ol> + +<p>以下のセクションでは、これらの手順を実行する方法について説明します。</p> + +<p>ADT プラグイン搭載の Eclipse を使用している場合、これらの手順を実行する代わりに Export Wizard を使用して .apk をコンパイルして秘密鍵で署名できます。Export Wizard では、処理過程で新しいキーストアと秘密鍵の生成も可能です。<a href="#ExportWizard">Eclipse ADT によるコンパイルと署名</a>を参考にコンパイルを行ってください。</p> + + +<h3 id="releasecompile">リリース向けのコンパイル</h3> + +<p>アプリケーションのリリースを準備するには、リリース モードでコンパイルする必要があります。リリース モードでは、Android ビルド ツールはアプリケーションを通常どおりにコンパイルしますが、デバッグ キーで署名しません。</p> + +<p class="warning"><strong>注:</strong> 署名されていないアプリケーション、またはデバッグ キーで署名されたアプリケーションはリリースできません。</p> + +<h4>Eclipse ユーザー</h4> + +<p><em>署名されていない</em> .apk ファイルを Eclipse からエクスポートするには、パッケージ エクスプローラー（Package Explorer）でプロジェクトを右クリックして、[[]<strong>Android ツール（Android Tools）</strong>] > [[]<strong>署名されていないアプリケーション パッケージのエクスポート（Export Unsigned Application Package）</strong>] を選択します。次に、署名されていない .apk ファイルの場所を指定します（または、<code>AndroidManifest.xml</code> ファイルを Eclipse で開き、[[]<em>概要（Overview）</em>] タブを開いて [[]<strong>署名されていない .apk のエクスポート（Export an unsigned .apk）</strong>] をクリックします）。</p> + +<p>Export Wizard では、コンパイルと署名の手順を一緒に処理できます。<a href="#ExportWizard">Eclipse ADT によるコンパイルと署名</a>をご覧ください。</p> + +<h4>Ant ユーザー</h4> + +<p>Ant を使用している場合は、必要な作業は Ant コマンドでビルド ターゲットとして「release」を指定するだけです。たとえば、Ant を build.xml ファイルがあるディレクトリから実行している場合、コマンドは次のようになります:</p> + +<pre>$ ant release</pre> + +<p>ビルド スクリプトは、アプリケーション .apk を署名せずにコンパイルします。</p> + + +<h3 id="cert">適切な秘密鍵の取得</h3> + +<p>アプリケーションの署名を準備するには、まず署名に使用する適切な秘密鍵があることを確認することが必要です。適切な秘密鍵とは、次の条件を満たすものです:</p> + +<ul> +<li>自分が所有している。</li> +<li>アプリケーションで識別される、個人、法人、または組織の実体を表す。</li> +<li>アプリケーションまたはアプリケーション スイートの予期される使用期間を超える有効期間を持っている。有効期間として、25 年以上を推奨します。 +<p>アプリケーションを Android マーケットに公開する予定の場合、2033 年 10 月 22 日までの有効期間が必要です。有効期間がこの日付以前に期限切れになるキーで署名されたアプリケーションは、アップロードできません。 +</p></li> +<li>Android SDK ツールで生成されたデバッグ キーではない。 </li> +</ul> + +<p>自己署名されたキーを使用できます。適切なキーがない場合、Keytool を使用して生成する必要があります。<a href="#setup">基本設定</a>で説明した手順に従って、Keytool を使用できるようにしてください。</p> + +<p>Keytool で自己署名キーを生成するには、<code>keytool</code> コマンドを使用して以下に示すオプション（および、必要に応じてその他のオプション）を渡します。 </p> + +<p class="warning"><strong>注:</strong> Keytool を実行する前に、<a href="#secure-key">秘密鍵のセキュリティ設定</a>を読んで、キーのセキュリティを確保する方法と、自分とユーザーにとってセキュリティ確保が重要な理由を理解してください。特に、自分のキーを生成する場合、キーストアとキーの両方に強力なパスワードを選択する必要があります。</p> + +<table> +<tr> +<th>Keytool のオプション</th> +<th>説明</th> +</tr> +<tr> +<td><code>-genkey</code></td><td>キー ペアを生成します（公開キーと秘密鍵）。</td> +</tr> +<tr> +<td><code>-v</code></td><td>詳しいメッセージを出力する。</td> +</tr> +<tr> +<td><code>-keystore <keystore-name>.keystore</code></td><td>秘密鍵を含むキーストアの名前。</td> +</tr> +<tr> +<td><code>-storepass <password></code></td><td><p>キーストアのパスワード。</p><p>セキュリティ上の注意として、安全なコンピュータで作業している場合を除き、このオプションをコマンド ラインに指定しないでください。指定しなかった場合、Keytool からパスワードの入力が求められます。このため、パスワードはシェルの履歴に記録されません。</p></td> +</tr> +<tr> +<td><code>-alias <alias_name></code></td><td>キーのエイリアス。</td> +</tr> +<tr> +<td><code>-keyalg <alg></code></td><td>キーの生成時に使用する暗号化アルゴリズム。DSA と RSA の 2 つをサポートしています。</td> +</tr> +<tr> +<td><code>-dname <name></code></td><td><p>キーの作成者を識別する、識別名。値は、自己署名証明書の発行者およびサブジェクト フィールドとして使用されます。 </p><p>このオプションはコマンド ラインで指定する必要はありません。指定しなかった場合、Jarsigner からそれぞれの識別名フィールド（CN、OU など）の入力が求められます。</p></td> +</tr> +<tr> +<td><code>-validity <valdays></code></td><td><p>キーの有効期間（日数）。 </p><p><strong>注:</strong> 10000 以上の値を推奨します。</p></td> +</tr> +<tr> +<td><code>-keypass <password></code></td><td><p>キーのパスワード。</p> +<p>セキュリティ上の注意として、安全なコンピュータで作業している場合を除き、このオプションをコマンド ラインに指定しないでください。指定しなかった場合、Keytool からパスワードの入力が求められます。このため、パスワードはシェルの履歴に記録されません。</p></td> +</tr> +</table> + + +<p>秘密鍵を生成する Keytool コマンドの例を示します。</p> + +<pre>$ keytool -genkey -v -keystore my-release-key.keystore +-alias alias_name -keyalg RSA -validity 10000</pre> + +<p>上記のコマンド例を実行すると、Keytool からキーストアとキーのパスワードと、キーの識別名フィールドの指定が求められます。キーストアが <code>my-release-key.keystore</code> というファイルとして生成されます。キーストアとキーは、入力したパスワードで保護されます。キーストアには 1 つのキーが含まれ、10000 日間有効です。エイリアスは、後で使用する名前で、アプリケーションに署名するときにこのキーストアを参照する名前です。 </p> + +<p>Keytool の詳細は <a +href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security">http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a> のドキュメント（英語のみ）をご覧ください。</p> + + +<h3 id="signapp">アプリケーションの署名</h3> + +<p>リリースする .apk に実際に署名する準備ができたら、Jarsigner ツールを使用して署名できます。<a href="#setup">基本設定</a>で説明したように、Jarsigner をコンピュータで使用できることを確認してください。また、秘密鍵を含むキーストアがあることも確認してください。</p> + +<p>アプリケーションに署名するには、Jarsigner を実行して、アプリケーションの .apk と、.apk の署名に使用する秘密鍵を含むキーストアの両方を参照します。以下の表では、使用できるオプションを示します。 <p> + +<table> +<tr> +<th>Jarsigner のオプション</th> +<th>説明</th> +</tr> +<tr> +<td><code>-keystore <keystore-name>.keystore</code></td><td>秘密鍵を含むキーストアの名前。</td> +</tr> +<tr> +<td><code>-verbose</code></td><td>詳しいメッセージを出力する。</td> +</tr> +<tr> +<td><code>-storepass <password></code></td><td><p>キーストアのパスワード。 </p><p>セキュリティ上の注意として、安全なコンピュータで作業している場合を除き、このオプションをコマンド ラインに指定しないでください。指定しなかった場合、Jarsigner からパスワードの入力が求められます。このため、パスワードはシェルの履歴に記録されません。</p></td> +</tr> +<tr> +<td><code>-keypass <password></code></td><td><p>秘密鍵のパスワード。 </p><p>セキュリティ上の注意として、安全なコンピュータで作業している場合を除き、このオプションをコマンド ラインに指定しないでください。指定しなかった場合、Jarsigner からパスワードの入力が求められます。このため、パスワードはシェルの履歴に記録されません。</p></td> +</tr> +</table> + +<p>Jarsigner を使用して <code>my_application.apk</code> というアプリケーション パッケージに署名する例を、上記で作成したキーストアを使用して示します。 +</p> + +<pre>$ jarsigner -verbose -keystore my-release-key.keystore +my_application.apk alias_name</pre> + +<p>上記のコマンドを実行すると、Jarsigner からキーストアとキーのパスワードの入力が求められます。.apk がその場で変更され、.apk は署名されます。.apk に別のキーで複数回署名できます。</p> + +<p>.apk が署名されたことを確認するには、次のようなコマンドを使用できます:</p> + +<pre>$ jarsigner -verify my_signed.apk</pre> + +<p>.apk が適切に署名されると、Jarsigner から「jar verified」と出力されます。詳細情報が必要な場合は、次のコマンドを使用できます。</p> + +<pre>$ jarsigner -verify -verbose my_application.apk</pre> + +<p>または、次のコマンドを使用します。</p> + +<pre>$ jarsigner -verify -verbose -certs my_application.apk</pre> + +<p>上記の <code>-certs</code> オプションが付加されたコマンドでは、「CN=」行が出力され、キーの作成者が示されます。</p> + +<p class="note"><strong>注:</strong> 「CN=Android Debug」と出力される場合、.apk が Android SDK によって生成されたデバッグ キーで署名されたことを示しています。アプリケーションをリリースする予定の場合は、デバッグ キーではなく秘密鍵で署名する必要があります。</p> + +<p>Jarsigner の詳細は <a href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security">http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a> のドキュメント（英語のみ）をご覧ください。</p> + + +<h3 id="ExportWizard">Eclipse ADT によるコンパイルと署名</h3> + +<p>ADT 搭載 Eclipse を使用している場合、Export Wizard を使用して<em>署名済み</em> .apk をエクスポートできます（必要に応じて、新しいキーストアを作成することもできます）。Export Wizard は、Keytool と Jarsigner のすべての処理を、コマンド ラインを使用せず、グラフィカル ユーザー インターフェースで署名を実行できます。Export Wizard は Keytool と Jarsigner の両方を使用するため、上記の<a href=#setup">署名の基本設定</a>の条件を満たすコンピュータで使用できます。</p> + +<p>署名された .apk を作成するには、パッケージ エクスプローラー（Package Explorer）でプロジェクトを右クリックして、<strong>[[]Android ツール（Android Tools）] > [[]署名済みアプリケーション パッケージのエクスポート（Export Signed Application Package）]</strong> を選択します（または、<code>AndroidManifest.xml</code> ファイルを Eclipse で開き、[[]<em>概要（Overview）</em>] タブを開いて [[]<strong>Export Wizard を使用する（Use the Export Wizard）</strong>] をクリックします）。表示されたウィンドウには、アプリケーションのエクスポート中に見つかったエラーが表示されます。エラーが見つからなかった場合は Export Wizard で処理を続行します。.apk に署名する秘密鍵の選択や、新しいキーストアと秘密鍵の作成など、アプリケーション署名のプロセスを手順を追って実行できます。</p> + +<p>Export Wizard が完了すると、配布可能な署名済み .apk が作成されています。</p> + + +<h2 id="secure-key">秘密鍵のセキュリティ設定</h2> + +<p>秘密鍵のセキュリティ設定は、作成者とユーザーの両者にとって重要です。他人にキーを使用させたり、第三者が見つけて使用できるような安全ではない場所にキーストアとキーを放置したりすると、作成者とユーザー間の信頼が損なわれます。 </p> + +<p>他者が許可を得ずにキーを取得した場合、その人物はアプリケーションに署名して配布し、本物のアプリケーションを故意に置き換えたり破損させたりすることができます。このような人物は、身元を詐称してアプリケーションに署名して配布し、その他のアプリケーションまたはシステム自体を攻撃したり、ユーザー データを破損させたり盗み出したりすることもあります。 </p> + +<p>キーの有効期限が切れるまで、秘密鍵のセキュリティを常に適切に維持できるかは、デベロッパーとしての評価を左右します。キーを安全に保つためのヒントをいくつか紹介します。 </p> + +<ul> +<li>キーストアとキーに強力なパスワードを選択します。</li> +<li>Keytool でキーを生成するとき、<em></em>コマンド ラインで <code>-storepass</code> および <code>-keypass</code> オプションを指定しないようにします。指定すると、パスワードがシェル履歴に記録され、コンピュータのすべてのユーザーがアクセスできるようになります。</li> +<li>同様に、Jarsigner でアプリケーションに署名するとき、<em></em>コマンド ラインで <code>-storepass</code> と <code>-keypass</code> オプションを指定しないようにします。 </li> +<li>秘密鍵を誰にも与えたり貸したりせず、不正なユーザーにキーストアとキーのパスワードを知られないようにします。</li> +</ul> + +<p>一般的には、キーの生成、使用、保管に関して常識的な注意を払っていれば、セキュリティを確保することができます。 </p>
\ No newline at end of file diff --git a/docs/html-intl/ja/guide/publishing/preparing.jd b/docs/html-intl/ja/guide/publishing/preparing.jd new file mode 100644 index 0000000..c7a2950 --- /dev/null +++ b/docs/html-intl/ja/guide/publishing/preparing.jd @@ -0,0 +1,158 @@ +page.title=公開の準備 +@jd:body + +<!-- +<div id="qv-wrapper"> +<div id="qv"> + +<h2>In this document</h2> + +<ol> +<li><a href=""></a></li> +</ol> + +</div> +</div> +--> + +<p>アプリケーションの公開とは、アプリケーションをテストして適切にパッケージし、Android 搭載の携帯端末のユーザーが利用できる状態にすることです。</p> + +<p>アプリケーションを公開して Android 搭載デバイスにインストールするには、いくつかの作業を行ってアプリケーションの準備を整える必要があります。このドキュメントでは、アプリケーションのリリースを成功させるための準備における、重要なチェックポイントを説明しています。 +</p> + +<p>アプリケーションを Android マーケットに公開する場合は、アプリケーションの具体的な準備要件について <a +href="{@docRoot}tools/publishing/publishing.html#market">Android マーケットでの公開</a> もご覧ください。 </p> + +<p>アプリケーションを公開する方法の一般的な情報については、<a href="{@docRoot}tools/publishing/publishing.html">Publishing Your Applications</a> のドキュメントをご覧ください。 </p> + +<div class="special"> + +<p>アプリケーションのリリースを準備する前の作業:</p> + +<ol> +<li>アプリケーションを実際のデバイスで徹底的にテストする </li> +<li>アプリケーションへのエンド ユーザー ライセンス契約の追加を検討する</li> +<li>アプリケーションのマニフェストにアイコンとラベルを指定する</li> +<li>ロギングとデバッグを無効にして、データとファイルをクリーンアップする</li> +</ol> + +<p>アプリケーションの最終コンパイルを実行する前の作業:</p> + +<ol start="5"> +<li>アプリケーションでバージョン管理を行う</li> +<li>適切な暗号化キーを取得する</li> +<li>アプリケーションが MapView 要素を使用している場合は、Maps API キーに登録する</li> +</ol> + +<p><em>アプリケーションのコンパイル</em></p> +<p>アプリケーションをコンパイルした後の作業:</p> +<ol start="8"> +<li>アプリケーションに署名する</li> +<li>コンパイルしたアプリケーションをテストする</li> +</ol> +</div> + +<h2 id="releaseready">アプリケーションのリリースを準備する前の作業</h2> + +<h3 id="test">1. アプリケーションを実際のデバイスで徹底的にテストする</h3> + +<p>アプリケーションをできる限り広範に徹底的にテストすることが重要です。この作業を支援するため、Android では多数のテスト用クラスとツールを用意しています。{@link android.app.Instrumentation Instrumentation} を使用して JUnit およびその他のテスト ケースを実行できます。また、<a href="{@docRoot}tools/help/monkey.html">UI/Application Exerciser Monkey</a> などのテスティング ツールを使用できます。 </p> + +<ul> +<li>ユーザーがアプリケーションを正常に実行できるようにするため、アプリケーションが実行されると予想されるタイプの携帯端末の実機を入手してください。実際のデバイスで、実際のネットワーク条件の下でアプリケーションをテストします。アプリケーションを実際のデバイスでテストすることは非常に重要です。これによって、作成したユーザー インターフェース要素のサイズが正しく（特にタッチスクリーン UI の場合）、アプリケーションのパフォーマンスと電池効率が適正であることを確認できるからです。</li> + +<li>アプリケーションの対象とするタイプの携帯端末が手に入らない場合は、<code>-dpi</code>、<code>-device</code>、<code>-scale</code>、<code>-netspeed</code>、<code>-netdelay</code>、<code>-cpu-delay</code> などのエミュレータ オプションを使用して、エミュレータの画面、ネットワーク パフォーマンス、その他の属性をモデル化して可能な限り対象デバイスに適応させることができます。このようにして、アプリケーションの UI とパフォーマンスをテストできます。ただし、公開する前にアプリケーションを実際の対象デバイスでテストすることを強く推奨します。 </li> + +<li>アプリケーションが <a href="http://www.t-mobileg1.com/">T-Mobile G1</a> デバイスを対象としている場合、UI が画面の向き変更に対応しているか確認してください。 </li> +</ul> + +<h3 id="eula">2. アプリケーションへのエンドユーザー ライセンス契約の追加を検討する</h3> + +<p>個人、組織、知的財産を保護するため、アプリケーションのエンドユーザー ライセンス契約（EULA）を付加することを推奨します。 + +<h3 id="iconlabel">3. アプリケーションのマニフェストにアイコンとラベルを指定する</h3> + +<p>アプリケーションのマニフェストに指定するアイコンとラベルは、アプリケーションのアイコンと名前としてユーザーに表示されるため、重要な要素です。アイコンとラベルは、デバイスの [[]ホーム] 画面や、[[]アプリケーションの管理]、[[]マイダウンロード] などに表示されます。また、公開サービスによってアイコンとラベルがユーザーに表示される可能性もあります。 </p> + +<p>アイコンとラベルを指定するには、<code>android:icon</code> と <code>android:label</code> 属性をマニフェストの <code><application></code> 要素に定義します。 </p> + +<p>アイコンのデザインについては、組み込みの Android アプリケーションのスタイルとできるだけ統一感を持たせてください。</p> + +<h3 id="logging">4. ロギングとデバッグを無効にして、データとファイルをクリーンアップする</h3> + +<p>リリース時にはデバッグ機能を無効にし、デバッグおよびその他の不要なデータ/ファイルをアプリケーション プロジェクトから削除してください。</p> +<ul> +<li><code>android:debuggable="true"</code> 属性をマニフェストの <code><application></code> 要素から削除します。</li> +<li>ログ ファイル、バックアップ ファイル、およびその他の不要なファイルをアプリケーション プロジェクトから削除します。</li> +<li>個人的または自分専用のデータがないか確認し、必要に応じて削除します。</li> +<li>ソース コード内に {@link android.util.Log} メソッドへの呼び出しがある場合は、無効にします。</li> +</ul> + +<h2 id="finalcompile">アプリケーションの最終コンパイルを実行する前の作業</h2> + +<h3 id="versionapp">5. アプリケーションでバージョン管理を行う</h3> + +<p>アプリケーションをコンパイルする前に、アプリケーションにバージョン番号を定義しておく必要があります。定義するには、アプリケーションのマニフェスト ファイルの <code><manifest></code> 要素の <code>android:versionCode</code> と <code>android:versionName</code> 属性の両方に適切な値を指定します。バージョン番号の設定は、全体的なアプリケーションアップグレードの計画を考慮して、慎重に検討してください。 </p> + +<p>これまでにリリースしたバージョンがある場合、最新のアプリケーションのバージョン番号を旧バージョンから増加させる必要があります。アプリケーションのマニフェスト ファイルの <code><manifest></code> 要素の <code>android:versionCode</code> と <code>android:versionName</code> 属性の両方を適切な値を使用して増加する必要があります。 </p> + +<p>アプリケーションのバージョン情報を定義する方法は、<a href="{@docRoot}tools/publishing/versioning.html">Versioning Your Applications</a>をご覧ください。</p> + +<h3 id="cryptokey">6. 適切な暗号化キーを取得する</h3> + +<p>ここまで準備作業をすべて読んで実行していれば、アプリケーションはコンパイルされ、署名の準備ができています。.apk の内部では、アプリケーションは適切にバージョン管理されており、上記のように余分なファイルや非公開データは削除されています。 </p> + +<p>アプリケーションに署名する前に、適切な非公開キーがあることを確認する必要があります。非公開キーを取得（または生成）する方法については、<a href="{@docRoot}tools/publishing/app-signing.html#cert">適切な非公開キーの取得</a>をご覧ください。</p> + +<p>適切な非公開キーを取得（または生成）したら、キーを使用して次の手順を実行します:</p> + +<ul> +<li>アプリケーションが MapView 要素を使用している場合は、Maps API キー（以下をご覧ください）に登録します。</li> +<li>以降の準備プロセスで、リリースするアプリケーションに署名します。</li> +</ul> + +<h3 id="mapsApiKey">7. アプリケーションが MapView 要素を使用している場合は、Maps API キーに登録する</h3> + +<div class="sidebox-wrapper"> +<div class="sidebox"><p> +Maps API キーを取得する方法は、<a +href="http://code.google.com/android/add-ons/google-apis/mapkey.html">Maps API キーの取得（英語のみ）</a> +をご覧ください。</p> +</div> +</div> + +<p>アプリケーションが Mapview 要素を使用する場合、アプリケーションを Google Maps サービスで登録し、Maps API キーを取得する必要があります。その後、MapView で Google Maps からデータを取得できるようになります。この処理を行うため、Maps サービスに署名証明書の MD5 フィンガープリントを提出します。 </p> + +<p>開発中は、SDK ツールが生成したデバッグ キーを登録して一時的な Maps API キーを取得できます。ただし、アプリケーションを公開する前には、非公開キーに基づく新しい Maps API キーで登録する必要があります。 </p> + +<p>アプリケーションが MapView 要素を使用する場合、次の点を理解することが重要です:</p> + +<ol> +<li>アプリケーションをリリース用にコンパイルする前に、Maps API キーを取得する必要があります。<em></em>このキーを、アプリケーションのレイアウト ファイルにある各 MapView 要素の、<code>android:apiKey</code> という特殊な属性に追加する必要があるからです。MapView オブジェクトをコードから直接インスタンス化している場合は、Maps API キーをコンストラクタのパラメータとして渡す必要があります。 +</li> +<li>アプリケーションの MapView 要素が参照する Maps API キーは Google Maps 内で登録され、アプリケーションの署名に使用される証明書に登録される必要があります。これはアプリケーションを公開する際に特に重要です。MapView 要素は、アプリケーションの署名に使用されるリリース証明書に登録されるキーを参照する必要があります。 </li> +<li>SDK ツールが生成したデバッグ証明書を登録して一時的な Maps API キーを取得している場合、リリース証明書を登録して新しい Maps API キーを取得する<em>必要があります</em>。また、MapView 要素を変更して、デバッグ証明書と関連付けられたキーではなく、新しいキーを参照させることも忘れないでください。このようにしないと、MapView 要素には Maps データをダウンロードする許可が与えられません。 </li> +<li>アプリケーションの署名に使用する非公開キーを変更するには、Google Maps サービスから新しい Maps API キーを取得する<em>必要があります</em>。新しい Maps API キーを取得してすべての MapView 要素に適用してください。以前のキーを参照する MapView 要素には、Maps データをダウンロードする許可が与えられません。 </li> +</ol> + +<p>署名と非公開キーについては、<a +href="{@docRoot}tools/publishing/app-signing.html">アプリケーションへの署名</a>をご覧ください。</p> + + +<h2 id="compile">アプリケーションのコンパイル</h2> + +<p>前述のセクションで説明したアプリケーションの準備ができたら、アプリケーションをリリース用にコンパイルできます。 </p> + +<h2 id="post-compile">アプリケーションをコンパイルした後の作業</h2> + +<h3 id="signapp">8. アプリケーションに署名する</h3> + +<p>非公開キーを使用してアプリケーションに署名します。アプリケーションに正しく署名することは、非常に重要です。詳細は、<a href="{@docRoot}tools/publishing/app-signing.html">アプリケーションへの署名</a>をご覧ください。 </p> + +<h3 id="testapp">9. コンパイルして署名したアプリケーションのテスト</h3> + +<p>コンパイルしたアプリケーションをリリースする前に、対象とする携帯端末（および可能ならば対象ネットワーク）上で徹底的にテストする必要があります。特に、UI 部分の MapView 要素がマップ データを正常に受信していることを確認してください。正常に受信していない場合、<a href="#mapsApiKey">Maps API キーに登録する</a>に戻って問題を解決してください。アプリケーションがサーバー側サービスを正しく利用できること、指定データまたは使用データを正しく処理できること、そして認証要件を正常に処理できることも確認してください。 </p> + +<p>これらのテストが完了したら、アプリケーションを携帯端末ユーザーに公開する準備が整ったと言えるでしょう。</p> + + diff --git a/docs/html-intl/ja/guide/publishing/versioning.jd b/docs/html-intl/ja/guide/publishing/versioning.jd new file mode 100644 index 0000000..1928610 --- /dev/null +++ b/docs/html-intl/ja/guide/publishing/versioning.jd @@ -0,0 +1,100 @@ +page.title=アプリケーションのバージョニング +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> + +<h2>バージョン管理の概略</h2> + +<ul> +<li>アプリケーションにはバージョンを設定する必要がある<em></em></a></li> +<li>バージョンは、アプリケーションのマニフェスト ファイルで設定する</li> +<li>アプリケーションのバージョン管理方法は、ユーザーのアップグレード方法に影響 </li> +<li>開発プロセスの初期段階で、今後のリリースの検討事項を含めて、バージョン管理戦略を決定します</li> +</ul> + +<h2>このドキュメントの内容</h2> + +<ol> +<li><a href="#appversion">アプリケーションのバージョンの設定</a></li> +<li><a href="#minsdkversion">最小システム API バージョンの指定</a> +</ol> + + +<h2>関連項目</h2> + +<ol> +<li><a href="{@docRoot}tools/publishing/preparing.html">公開の準備</a></li> +<li><a href="{@docRoot}tools/publishing/publishing.html#market">Android マーケットでの公開</a></li> +<li><a href="{@docRoot}guide/topics/manifest/manifest-intro.html">The AndroidManifest.xml File</a></li> +</ol> + +</div> +</div> + +<p>バージョン管理のコンポーネントは、アプリケーションのアップグレード及びメンテナンスの計画を立てるのに重要です。 </p> + +<ul> +<li>ユーザーは、デバイスにインストールされたアプリケーション バージョンと、インストールが可能なアップグレード バージョンについて、特定の情報が必要です。 </li> +<li>スイートとして公開されたその他のアプリケーションなどでは、アプリケーションのバージョンをシステムに問い合わせて、互換性と依存関係を確認する必要があります。</li> +<li>アプリケーションを公開するサービスでは、アプリケーションにバージョンを問い合わせて、バージョンをユーザーに表示できるようにする必要があります。公開サービスでは、互換性を確認してアップグレードとダウングレードの関係を確立するために、アプリケーション バージョンを確認する必要があります。</li> +</ul> + +<p>Android システム自体は、アップグレードや互換性の制約の実施などのために、アプリケーション バージョン情報をアプリケーションに対して<em>確認することはありません</em>。代わりに、アプリケーションにおけるバージョン制約はユーザーまたはアプリケーション自体によって完全に実施されます。 </p> + +<p>Android システムが確認を行うのは、アプリケーションによってマニフェストの <code>minSdkVersion</code> 属性に指定されたシステム バージョン互換性です。<em></em>この属性によりアプリケーションは互換性を持つ最小システム API を指定できます。詳細は、<a href="#minsdkversion">最小システム API バージョンの指定</a>をご覧ください。 + +<h2 id="appversioning">アプリケーションのバージョンの設定</h2> +<p>アプリケーションのバージョン情報を定義するには、アプリケーションのマニフェスト ファイルで属性を設定します。2 つの属性を使用でき、常にこの両方に値を定義することが推奨されています: </p> + +<ul> +<li><code>android:versionCode</code> - アプリケーション コードのバージョンを他のバージョンと相対的に示す整数値。 + +<p>この値は整数なので、その他のアプリケーションはプログラムでバージョンの値を評価して関係を確認できます（たとえば、このバージョンがアップグレードかダウングレードなのか、など）。任意の整数値を設定できますが、アプリケーションの後続のリリースでは、現在より大きな値を使用するようにしてください。システムではこのバージョン管理の基準を強制しませんが、後継リリースの値を増加させることは標準的です。 </p> + +<p>通常、アプリケーションの最初のバージョンの versionCode を 1 に設定してリリースし、その後は各リリースについて、リリースがメジャー リリースであってもマイナー リリースであっても、値を単調増加させます。これは、<code>android:versionCode</code> の値は、ユーザーに表示されるアプリケーション リリース バージョンと類似している必要性はないことを意味します。以下の <code>android:versionName</code> をご覧ください。アプリケーションと公開サービスでは、このバージョンの値はユーザーには表示されません。</p> +</li> +<li><code>android:versionName</code> - アプリケーション コードのリリース バージョンを表す文字列値で、ユーザーに表示される値です。 +<p>値は文字列なので、アプリケーション バージョンを「<major>.<minor>.<point>」といった文字列や、その他のタイプの絶対的または相対的バージョン ID として記述できます。 </p> + +<p><code>android:versionCode</code> の場合と同様に、システムではこの値をアプリケーションでユーザーに表示する以外の目的で内部的に利用することはありません。公開サービスでは、ユーザーに表示するために <code>android:versionName</code> 値を取り出す可能性もあります。</p> +</li> +</ul> + +<p>これらのバージョン属性の両方をマニフェスト ファイルの <code><manifest></code> 要素で定義します。 </p> + +<p>ここに、<code><manifest></code> 要素の <code>android:versionCode</code> と <code>android:versionName</code> 属性を示すマニフェストの例を示します。 </p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" + package="com.example.package.name" + android:versionCode="2" + android:versionName="1.1"> + <application android:icon="@drawable/icon" android:label="@string/app_name"> + ... + </application> +</manifest> +</pre> + +<p>この例では、<code>android:versionCode</code> 値は現在の .apk がこのアプリケーション コードの 2 番目のリリースを含んでいることを表し、これは <code>android:codeName</code> 文字列が示すようにマイナー後継リリースであることを示します。 </p> + +<p>Android フレームワークには、アプリケーションがシステムに別のアプリケーションのバージョン情報を問い合わせる API が用意されています。バージョン情報を取得するため、アプリケーションは {@link android.content.pm.PackageManager#getPackageInfo(java.lang.String, int)} +method of {@link android.content.pm.PackageManager PackageManager}. </p> を使用します。 + +<h2 id="minsdkversion">最小システム API バージョンの指定</h2> + +<p>アプリケーションが最低でも Android プラットフォームの特定のバージョンを必要とする場合、このバージョンを API レベルの ID としてアプリケーションのマニフェスト ファイルに指定できます。このようにすると、互換性のあるバージョンの Android システムを実行しているデバイスにのみアプリケーションをインストールできるようになります。 </p> + +<p>最小システム バージョンをマニフェストに指定するには、次の属性を使用します: </p> + +<ul> +<li><code>android:minSdkVersion</code> - Android プラットフォームのコード バージョンに対応する整数値。 +<p>アプリケーションのインストールを準備する際に、システムはこの属性の値を確認して、システム バージョンと比較します。<code>android:minSdkVersion</code> 値がシステム バージョンよりも大きい場合、システムはアプリケーションのインストールを中止します。 </p> + +<p>この属性をマニフェストに指定しない場合、システムではアプリケーションがすべてのプラットフォーム バージョンと互換性があると仮定します。</p></li> +</ul> + +<p>アプリケーションに最小プラットフォーム バージョンを指定するには、<code><uses-sdk></code> 要素を <code><manifest></code> の子として追加し、<code>android:minSdkVersion</code> を属性として定義します。 </p> + +<p>詳細は、<a href="{@docRoot}about/versions/android-1.1.html">Android System Image 1.1 Version Notes</a> もご覧ください。</p> diff --git a/docs/html-intl/ja/guide/topics/fundamentals.jd b/docs/html-intl/ja/guide/topics/fundamentals.jd new file mode 100644 index 0000000..cf9f7dd --- /dev/null +++ b/docs/html-intl/ja/guide/topics/fundamentals.jd @@ -0,0 +1,922 @@ +page.title=開発の基礎 +@jd:body + +<div id="qv-wrapper"> +<div id="qv"> +<h2>主なクラス</h2> +<ol> +<li>{@link android.app.Activity}</li> +<li>{@link android.app.Service}</li> +<li>{@link android.content.BroadcastReceiver}</li> +<li>{@link android.content.ContentProvider}</li> +<li>{@link android.content.Intent}</li> +</ol> + +<h2>このドキュメントの内容</h2> +<ol> +<li><a href="#appcomp">アプリケーションのコンポーネント</a> + <ol> + <li><a href="#actcomp">コンポーネントのアクティブ化: インテント</a></li> + <li><a href="#endcomp">コンポーネントの終了</a></li> + <li><a href="#manfile">マニフェスト ファイル</a></li> + <li><a href="#ifilters">インテント フィルタ</a></li> + </ol></li> +<li><a href="#acttask">アクティビティとタスク</a> + <ol> + <li><a href="#afftask">親和性と新しいタスク</a></li> + <li><a href="#lmodes">起動モード</a></li> + <li><a href="#clearstack">スタックのクリア</a></li> + <li><a href="#starttask">タスクの開始</a></li> + </ol></li> +<li><a href="#procthread">プロセスとスレッド</a> + <ol> + <li><a href="#procs">プロセス</a></li> + <li><a href="#threads">スレッド</a></li> + <li><a href="#rpc">リモート プロシージャ コール</a></li> + <li><a href="#tsafe">スレッドセーフなメソッド</a></li> + </ol></li> +<li><a href="#lcycles">コンポーネントのライフサイクル</a> + <ol> + <li><a href="#actlife">アクティビティのライフサイクル</a></li> + <li><a href="#servlife">サービスのライフサイクル</a></li> + <li><a href="#broadlife">ブロードキャスト レシーバのライフサイクル</a></li> + <li><a href="#proclife">プロセスとライフサイクル</a></li> + </ol></li> +</ol> +</div> +</div> + +<p> +Android アプリケーションはすべて Java プログラミング言語で記述します。コンパイル済みの Java コード（およびそのアプリケーションに必要なすべてのデータやリソース ファイル）は、<a href="{@docRoot}tools/aapt.html"><code>aapt</code> ツール</a>を使用して Android パッケージにバンドルします。Android パッケージは、拡張子が {@code .apk} のアーカイブ ファイルです。<i></i>ユーザーは、このファイルをデバイスにダウンロードして利用します。つまり、Android パッケージは、アプリケーションをモバイル デバイスに配布およびインストールするための媒体として機能します。1 つの {@code .apk} ファイルに含まれているすべてのコードが、1 つのアプリケーションと見なされます。<i></i> +</p> + +<p> +各 Android アプリケーションは、以下に示すさまざまな方法で他のアプリケーションから隔離されています: +</p> + +<ul> +<li>すべてのアプリケーションは、デフォルトではそのアプリケーション個別の Linux プロセスで実行されます。Android は、アプリケーション コードの実行が必要になったときにプロセスを開始し、その必要がなくなって他のアプリケーションからシステム リソースを要求されたときにプロセスを終了します。</li> + +<li>プロセスごとに専用の Java 仮想マシン（VM）が割り当てられるため、アプリケーション コードは他のアプリケーションから隔離された状態で実行されます。</li> + +<li>デフォルトでは、アプリケーションごとに固有の Linux ユーザー ID が割り当てられます。権限が設定されているため、アプリケーションのファイルはそのユーザーからしか認識できず、そのアプリケーション自体からのみ利用できます。ただし、ファイルを他のアプリケーションにエクスポートすることは可能です。</li> +</ul> + +<p> +2 つのアプリケーションで同じユーザー ID を共有することもできます。その場合は、それぞれのアプリケーションのファイルを相互に認識できます。システム リソースを節約するため、同じ ID のアプリケーションで同じ VM を共有し、同じ Linux プロセスで実行することも可能です。 +</p> + + +<h2 id="appcomp">アプリケーションのコンポーネント</h2> + +<p> +Android の大きな特長の 1 つは、許可されていれば、あるアプリケーションから別のアプリケーションの要素を利用できる点です。たとえば、開発中のアプリケーションで画像の一覧をスクロール表示したい場合、他のアプリケーションで開発済みの適切なスクローラがあり、その利用が許可されていれば、独自に開発しなくてもそのスクローラを利用できます。アプリケーションに他のアプリケーションのコードを組み込んだり、リンクを設定したりする必要はありません。必要になった時点で、他のアプリケーションの一部分を開始するだけです。 +</p> + +<p> +この仕組みが機能するには、アプリケーション プロセスの一部分を必要に応じて開始でき、その部分の Java オブジェクトをインスタンス化できなくてはなりません。そのため、Android アプリケーションには、他のシステムで動作するアプリケーションでよく使用されるような、アプリケーション全体にアクセスするための単一のエントリ ポイント（たとえば {@code main()} 関数）はありません。代わりに、システムが必要に応じてインスタンス化して実行できるコンポーネントで構成されます。<i></i>コンポーネントには以下の 4 つのタイプがあります: +</p> + +<dl> + +<dt><b>アクティビティ</b></dt> +<dd>アクティビティは、ユーザーが 1 つの操作を集中的に行うための視覚的なユーザー インターフェースを表します。<i></i>たとえば、ユーザーが選択できるメニュー アイテムの一覧を表示するアクティビティや、写真をキャプション付きで表示するアクティビティなどが考えられます。SMS アプリケーションなら、あるアクティビティでメッセージを送信する連絡先の一覧を表示し、別のアクティビティで選択した連絡先へのメッセージを入力し、その他のアクティビティで古いメッセージを参照したり設定を変更したりできます。これらのアクティビティを組み合わせて全体としてのユーザー インターフェースを形成しますが、それぞれのアクティビティは相互に独立しています。各アクティビティは、{@link android.app.Activity} 基本クラスのサブクラスとして実装されます。 + +<p> +アプリケーションは、1 つのアクティビティで構成することも、上記のSMS アプリケーションのように複数のアクティビティで構成することもできます。どのようなアクティビティがいくつ必要になるかは、アプリケーションやその設計に応じて異なります。通常は、アクティビティのうちのいずれかを最初のアクティビティとして指定し、ユーザーがアプリケーションを起動したときに表示します。あるアクティビティから別のアクティビティに移動するには、現在のアクティビティから次のアクティビティを開始します。 +</p> + +<p> +各アクティビティには、それを表示するためのデフォルトのウィンドウが割り当てられます。通常はウィンドウを画面全体に表示しますが、画面より小さいウィンドウを他のウィンドウの前面に表示することもできます。アクティビティに、新たなウィンドウを追加することも可能です。たとえば、アクティビティの途中でユーザーの応答を要求するポップアップ ダイアログを表示したり、ユーザーが画面上の特定のアイテムを選択したときに別ウィンドウで重要な情報を表示したりできます。 +</p> + +<p> +ウィンドウの視覚的なコンテンツは、ビュー（{@link android.view.View} 基本クラスの派生オブジェクト）の階層として提供されます。各ビューは、ウィンドウ内の特定の矩形領域を制御します。親ビューは、その子となるビューで構成され、それらの子ビューのレイアウトを決定します。リーフ ビュー（階層の最下位に位置するビュー）は、そのビューが制御する矩形領域に表示され、その領域でのユーザーのアクションに対して応答します。つまり、ビューはアクティビティとユーザーが対話する場所です。たとえば、ビューに小さな画像を表示し、ユーザーがその画像をタップしたら何らかのアクションを開始することもできます。Android には、ボタン、テキスト フィールド、スクロール バー、メニュー アイテム、チェックボックスなど、さまざまなビューがあらかじめ用意されています。 +</p> + +<p> +ビューの階層は、<code>{@link android.app.Activity#setContentView Activity.setContentView()}</code> メソッドを使用してアクティビティのウィンドウ内に配置します。コンテンツ ビューは、階層のルートとなる View オブジェクトです<i></i>（ビューおよびその階層について詳しくは<a href="{@docRoot}guide/topics/ui/index.html">User Interface</a> のドキュメントをご覧ください）。 +</p> + +<p><dt><b>サービス</b></dt> +<dd>サービスは、視覚的なユーザー インターフェースを持たず、バックグラウンドにおいて明確な終了期限がなくで実行されます。<i></i>たとえば、ユーザーが他の操作をしている間 BGM を再生するサービス、ネットワーク経由でデータをフェッチするサービス、何かを計算してその結果をアクティビティに提供するサービスなどが考えられます。各サービスは、{@link android.app.Service} 基本クラスの拡張です。 + +<p> +典型的な例としては、プレイリストの曲を再生するメディア プレーヤーが挙げられます。プレーヤー アプリケーションは、ユーザーが曲を選んで再生するための 1 つ以上のアクティビティで構成することが予想されますが、ユーザーはプレーヤーを離れて別の操作に移った後も曲を聞いていたいと考えられることから、曲の再生自体をアクティビティで処理するわけにはいきません。音楽の再生を続けるには、メディア プレーヤー アクティビティから、バックグラウンドで実行するサービスを開始します。音楽再生サービスは、それを開始したアクティビティが画面上に見えなくなった後もそのまま実行されます。 +</p> + +<p> +また、実行中のサービスに接続（バインド）することもできます（実行されていない場合はそのサービスを開始することも可能です）。接続中は、サービスが公開しているインターフェースを使ってサービスと対話できます。音楽再生サービスであれは、このインターフェースを使って一時停止、巻き戻し、停止、再生の再開などの操作を実行できるようにします。 +</p> + +<p> +アクティビティや他のコンポーネントと同様に、サービスもアプリケーション プロセスのメイン スレッドで実行します。したがって、サービスによって他のコンポーネントやユーザー インターフェースの実行を妨げられることはなく、時間がかかるタスク（たとえば曲の再生）については、通常は別のスレッドを生成して処理します。詳しくは、<a href="#procthread">プロセスとスレッド</a>をご覧ください。 +</p></dd> + +<dt><b>ブロードキャスト レシーバ</b></dt> +<dd>ブロードキャスト レシーバは、ブロードキャストの連絡を受信してそれに対処するだけのコンポーネントです。<i></i>ブロードキャストの多くが元々はシステム コードで、たとえばタイム ゾーンが変更されたこと、電池の残量が少なくなったこと、写真が撮影されたこと、ユーザーが言語設定を変更したことなどを連絡するために使用します。アプリケーションでも、たとえば何らかのデータがデバイスにダウンロードされて利用できるようになったことを、他のアプリケーションにブロードキャストで知らせることができます。 + +<p> +アプリケーションでは、重要と思われるすべての連絡に応答できるよう、ブロードキャスト レシーバをいくつでも設定できます。すべてのレシーバは、{@link android.content.BroadcastReceiver} 基本クラスの拡張です。 +</p> + +<p> +ブロードキャスト レシーバがユーザー インターフェースを表示することはありません。ただし、受信した情報への応答としてアクティビティを開始したり、{@link android.app.NotificationManager} を使用してユーザーにアラートを送信したりすることはあります。通知の際には、バックライトを点滅させる、バイブレーションを起動する、音を鳴らすなど、さまざまな方法でユーザーの注意を喚起できます。通常は、ステータス バーに永続アイコンを表示し、ユーザーがこれを開いてメッセージを取得できるようにします。 +</p></dd> + +<dt><b>コンテンツ プロバイダ</b></dt> +<dd>コンテンツ プロバイダは、アプリケーションのデータを他のアプリケーションでも利用できるようにします。<i></i>データは、ファイル システムや SQLite データベースなど、一般に利用できる方法で格納されていれば使用できます。コンテンツ プロバイダは、{@link android.content.ContentProvider} 基本クラスの拡張です。プロバイダが制御する型のデータを、他のアプリケーションから取得および格納するための標準メソッド セットを実装しています。ただし、これらのメソッドをアプリケーションから直接呼び出すことはできません。代わりに、{@link android.content.ContentResolver} オブジェクトのメソッドを呼び出します。ContentResolver は、すべてのプロバイダと通信でき、プロバイダと連携して関係のあるすべてのプロセス間通信を管理します。 + +<p> +コンテンツ プロバイダの使用方法について詳しくは、<a href="{@docRoot}guide/topics/providers/content-providers.html">Content Providers</a>のドキュメントをご覧ください。 +</p></dd> + +</dl> + +<p> +Android では、特定のコンポーネントで処理すべきリクエストがあると、そのコンポーネントのアプリケーション プロセスが実行中かどうかを確認（必要に応じてプロセスを開始）し、そのコンポーネントの適切なインスタンスが利用可能かどうかを確認（必要に応じてインスタンスを作成）します。 +</p> + + +<h3 id="actcomp">コンポーネントのアクティブ化: インテント</h3> + +<p> +コンテンツ プロバイダは、ContentResolver からのリクエストの対象になるとアクティブ化されます。それ以外の 3 つのコンポーネント（アクティビティ、サービス、ブロードキャスト レシーバ）は、インテントと呼ばれる非同期メッセージによってアクティブ化されます。<i></i>インテントは、メッセージのコンテンツを保持する {@link android.content.Intent} オブジェクトです。アクティビティやサービスの場合の Intent オブジェクトの主な役割は、リクエストされているアクションを指名し、その対象となるデータの URI を指定することです。たとえば、ユーザーに画像を表示するためのリクエストや、ユーザーにテキストを編集させるリクエストをアクティビティに伝達できます。ブロードキャスト レシーバの場合は、Intent オブジェクトがこれから通知を行うアクションを指名します。たとえば、カメラのボタンが押されたことを、関係のあるブロードキャスト レシーバに通知できます。 +</p> + +<p> +以下に示すように、コンポーネントのタイプごとに別々のアクティブ化メソッドが用意されています: +</p> + +<ul> + +<li>アクティビティを起動する（または何か新しい処理を実行させる）には、Intent オブジェクトを <code>{@link android.content.Context#startActivity +Context.startActivity()}</code> または <code>{@link +android.app.Activity#startActivityForResult +Activity.startActivityForResult()}</code> に渡します。応答アクティビティで <code>{@link android.app.Activity#getIntent getIntent()}</code> メソッドを呼び出すと、最初にそのアクティビティが起動されたときのインテントの内容を確認できます。Android によってアクティビティの <code>{@link +android.app.Activity#onNewIntent onNewIntent()}</code> メソッドが呼び出され、アクティビティが後続のインテントに渡されます。 + +<p> +多くの場合、アクティビティから次のアクティビティを開始します。開始するアクティビティから結果が返される場合は、{@code startActivity()} ではなく {@code startActivityForResult()} を呼び出します。たとえば、ユーザーに写真を選択させるアクティビティを開始する場合は、ユーザーによって選択された写真が返されるかもしれません。結果は、呼び出し側のアクティビティの <code>{@link android.app.Activity#onActivityResult +onActivityResult()}</code> メソッドに渡した Intent オブジェクトで返されます。 +</p> +</li> + +<li><p>サービスを開始する（または実行中のサービスに新しい指示を与える）には、<code>{@link +android.content.Context#startService Context.startService()}</code> に Intent オブジェクトを渡します。Android により、サービスの <code>{@link android.app.Service#onStart +onStart()}</code> メソッドが呼び出されて Intent オブジェクトが渡されます。</p> + +<p> +同様に、インテントを <code>{@link +android.content.Context#bindService Context.bindService()}</code> に渡すと、呼び出し側のコンポーネントと対象となるサービスの間の継続中の接続を確立できます。サービスは、<code>{@link android.app.Service#onBind onBind()}</code> 呼び出しで Intent オブジェクトを受け取ります（サービスがまだ開始されていない場合は、必要に応じて {@code bindService()} で開始できます）。たとえば、上で例に挙げた音楽再生サービスとの接続を確立するアクティビティを使用して、ユーザーが再生を操作するための手段（ユーザー インターフェース）を提供できます。アクティビティで {@code bindService()} を呼び出して接続を確立してから、サービスに定義されているメソッドを呼び出して再生を操作します。 +</p> + +<p> +サービスのバインドについては、後ほど<a href="#rpc">リモート プロシージャ コール</a>のセクションで詳しく説明します。 +</p> +</li> + +<li><p>アプリケーションでブロードキャストを開始するには、<code>{@link +android.content.Context#sendBroadcast(Intent) Context.sendBroadcast()}</code>、<code>{@link android.content.Context#sendOrderedBroadcast(Intent, String) +Context.sendOrderedBroadcast()}</code>、<code>{@link +android.content.Context#sendStickyBroadcast Context.sendStickyBroadcast()}</code> などのメソッドのいずれかのバリエーションに Intent オブジェクトを渡します。Android によって <code>{@link +android.content.BroadcastReceiver#onReceive onReceive()}</code> メソッドが呼び出され、関係のあるすべてのブロードキャスト レシーバにインテントが配信されます。</p></li> + +</ul> + +<p> +インテント メッセージについて詳しくは、<a href="{@docRoot}guide/components/intents-filters.html">Intents and Intent Filters</a> をご覧ください。 +</p> + + +<h3 id="endcomp">コンポーネントの終了</h3> + +<p> +コンテンツ プロバイダは、ContentResolver からのリクエストに応答している間のみアクティブになります。ブロードキャスト レシーバは、ブロードキャスト メッセージに応答している間のみアクティブになります。つまり、これらのコンポーネントを明示的に終了させる必要はありません。 +</p> + +<p> +一方、アクティビティはユーザー インターフェースを提供します。長い時間をかけてユーザーと会話するためのものであり、待機状態の間も、会話が続いてきる限りはアクティブなままになっている可能性があります。同様に、サービスも長い間実行されたままになる可能性があります。Android には、アクティビティとサービスを以下のような規則的な方法で終了させるためのメソッドが用意されています: +</p> + +<ul> +<li>アクティビティを終了させるには、その <code>{@link android.app.Activity#finish finish()}</code> メソッドを呼び出します。あるアクティビティから {@code startActivityForResult()} で開始した別のアクティビティは、<code>{@link android.app.Activity#finishActivity finishActivity()}</code> を呼び出して終了させることができます。</li> + +<li>サービスは、その <code>{@link android.app.Service#stopSelf stopSelf()}</code> メソッドを呼び出すか、<code>{@link android.content.Context#stopService Context.stopService()}</code> を呼び出すことで停止できます。</li> +</ul> + +<p> +コンポーネントが、既に利用されていない場合や、Android がよりアクティブな他のコンポーネントにメモリを割り当てる必要がある場合は、システムがコンポーネントを終了させることもあります。このような状況およびその影響については、<a href="#lcycles">コンポーネントのライフサイクル</a>で詳しく説明します。 +</p> + + +<h3 id="manfile">マニフェスト ファイル</h3> + +<p> +アプリケーション コンポーネントを開始するには、Android がそのコンポーネントの存在を認識している必要があります。アプリケーションのコンポーネントは、マニフェスト ファイルで宣言します。このファイルは、アプリケーションのコード、ファイル、リソースなどとともに Android パッケージ（{@code .apk} ファイル）にバンドルされます。 +</p> + +<p> +マニフェストは構造化された XML ファイルで、どのアプリケーションでも常に AndroidManifest.xml という名前になります。アプリケーション コンポーネントの宣言以外にも、アプリケーションをリンクさせる必要のあるライブラリ（デフォルトの Android ライブラリを除く）の指定や、アプリケーションに付与されるべき権限の指定などにも使用します。 +</p> + +<p> +しかし、マニフェストの最も重要な役割は、アプリケーションのコンポーネントに関する情報を Android に提供することです。たとえば、アクティビティを次のように宣言できます: +</p> + +<pre><?xml version="1.0" encoding="utf-8"?> +<manifest . . . > + <application . . . > + <activity android:name="com.example.project.FreneticActivity" + android:icon="@drawable/small_pic.png" + android:label="@string/freneticLabel" + . . . > + </activity> + . . . + </application> +</manifest></pre> + +<p> +<code><a href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a></code> 要素の {@code name} 属性は、そのアクティビティを実装する {@link android.app.Activity} サブクラスを指名します。{@code icon} および {@code label} 属性には、ユーザーに対して表示するアイコンやラベルが保持されているリソース ファイルを指定します。 +</p> + +<p> +その他のコンポーネントも、サービスは <code><a href="{@docRoot}guide/topics/manifest/service-element.html"><service></a></code> 要素、ブロードキャスト レシーバは <code><a href="{@docRoot}guide/topics/manifest/receiver-element.html"><receiver></a></code> 要素、コンテンツ プロバイダは <code><a href="{@docRoot}guide/topics/manifest/provider-element.html"><provider></a></code> 要素を使用して同じような方法で宣言します。マニフェストに宣言されていないアクティビティ、サービス、およびコンテンツ プロバイダは、システムから認識できないため実行されることはありません。ただし、ブロードキャスト レシーバの場合は、マニフェストで宣言する方法と、コード内で {@link android.content.BroadcastReceiver} オブジェクトとして動的に作成し、<code>{@link android.content.Context#registerReceiver Context.registerReceiver()}</code> を呼び出してシステムに登録する方法があります。 +</p> + +<p> +マニフェスト ファイルの作成方法について詳しくは、<a href="{@docRoot}guide/topics/manifest/manifest-intro.html">The AndroidManifest.xml File</a>をご覧ください。 +</p> + + +<h3 id="ifilters">インテント フィルタ</h3> + +<p> +Intent オブジェクトでは、対象とするコンポーネントを明示的に指名できます。明示的に指名されている場合、Android はマニフェスト ファイル内の宣言に基づいてコンポーネントを特定してアクティブにします。一方、明示的に指名されていない場合は、そのインテントに応答する上で最適なコンポーネントが選択されます。方法としては、Intent オブジェクトを、その対象となりうるコンポーネントのインテント フィルタと照合します。<i></i>コンポーネントのインテント フィルタは、そのコンポーネントで処理できるインテントの種類を示します。これもコンポーネントに関する重要な情報の 1 つなので、マニフェスト ファイルで宣言します。次に、上に示した例を拡張して 2 つのインテント フィルタを追加したアクティビティを示します: +</p> + +<pre><?xml version="1.0" encoding="utf-8"?> +<manifest . . . > + <application . . . > + <activity android:name="com.example.project.FreneticActivity" + android:icon="@drawable/small_pic.png" + android:label="@string/freneticLabel" + . . . > + <intent-filter . . . > + <action android:name="android.intent.action.MAIN" /> + <category android:name="android.intent.category.LAUNCHER" /> + </intent-filter> + <intent-filter . . . > + <action android:name="com.example.project.BOUNCE" /> + <data android:mimeType="image/jpeg" /> + <category android:name="android.intent.category.DEFAULT" /> + </intent-filter> + </activity> + . . . + </application> +</manifest></pre> + +<p> +この例の 1 つ目のフィルタは、アクション「{@code android.intent.action.MAIN}」とカテゴリ「{@code android.intent.category.LAUNCHER}」を組み合わせた一般的なフィルタです。このフィルタは、アプリケーション ランチャ（ユーザーがデバイス上で起動できるアプリケーションを一覧表示した画面）に、このアクティビティを表示する必要があることを示しています。つまり、このアクティビティはアプリケーションへのエントリ ポイントとして機能し、ユーザーがランチャでそのアプリケーションを選択したときに最初に表示されるということです。 +</p> + +<p> +2 つ目のフィルタでは、アクティビティが特定のタイプのデータに対して実行できるアクションを宣言しています。 +</p> + +<p> +コンポーネントにはインテント フィルタをいくつでも指定でき、それぞれのフィルタで別々の機能を宣言できます。フィルタが 1 つも指定されていないコンポーネントは、そのコンポーネントが対象として明示的に指名されているインテントでのみアクティブにできます。 +</p> + +<p> +コード内で作成して登録したブロードキャスト レシーバの場合、インテント フィルタは {@link android.content.IntentFilter} オブジェクトとして直接インスタンス化されます。それ以外の全てのフィルタは、マニフェストで設定します。 +</p> + +<p> +インテント フィルタについて詳しくは、<a href="{@docRoot}guide/components/intents-filters.html">Intents and Intent Filters</a> をご覧ください。 +</p> + + +<h2 id="acttask">アクティビティとタスク</h2> + +<p> +既に説明したように、あるアクティビティから別のアクティビティを開始することができます。これには、別のアプリケーションで定義されているアクティビティも含まれます。たとえば、ユーザーに特定の場所の地図を表示するとします。そのためのアクティビティは既に存在しているので、現在のアクティビティで必要な情報を Intent オブジェクトに格納して {@code startActivity()} に渡すだけで、マップ ビューアに地図を表示できます。ユーザーが [戻る] キーを押すと、画面に元のアクティビティが再表示されます。 +</p> + +<p> +この場合、マップ ビューアは別のアプリケーションで定義されており、そのアプリケーションのプロセスで実行されていますが、ユーザーにとってはマップ ビューアが元のアプリケーションの一部であるかのように感じられます。Android では、両方のアクティビティを同じタスクに組み込むことで、このようなユーザー エクスペリエンスを実現できます。<i></i>簡単に言えば、ユーザーが 1 つの「アプリケーション」と感じるものがタスクです。関連するアクティビティをスタックにまとめたものがタスクです。スタック内のルート アクティビティは、タスクを開始するアクティビティです。通常であれば、ユーザーがアプリケーション ランチャで選択するアクティビティがこれに相当します。スタックの最上位にあるアクティビティは、ユーザーのアクションの焦点となっている実行中のアクティビティです。あるアクティビティから別のアクティビティを開始すると、そのアクティビティが新たにスタックにプッシュされて実行中のアクティビティになります。1 つ前のアクティビティはスタック内に残されています。ユーザーが [[]戻る] キーを押すと、現在のアクティビティがスタックからポップされ、1 つ前のアクティビティが実行中のアクティビティとして再開されます。 +</p> + +<p> +スタックはオブジェクトを保持します。したがって、同じ Activity サブクラスのインスタンス（たとえばマップ インスタンス）を複数開くと、それぞれのインスタンスが別々のエントリになります。スタック内のアクティビティは、プッシュまたはポップされるのみで再配置されることはありません。 +</p> + +<p> +タスクはアクティビティのスタックであり、マニフェスト ファイル内のクラスや要素ではありません。したがって、アクティビティと無関係にタスクの値を設定することはできません。タスクの値は、ルート アクティビティでまとめて設定します。たとえば、次のセクションでは「タスクの親和性」について説明しますが、値はタスクのルート アクティビティの親和性のセットから読み込まれます。 +</p> + +<p> +タスク内のアクティビティは、1 つのユニットとして一緒に移動します。タスク全体（アクティビティ スタック全体）をフォアグラウンドに移動したり、バックグラウンドに移動したりできます。たとえば、現在のタスクは 4 つのアクティビティからなるスタックで、現在のアクティビティの下にアクティビティが 3 つあるとします。ここで、ユーザーが [ホーム] キーを押してアプリケーション ランチャに移動し、新しいアプリケーション（実際には新しいタスク）を選択したとします。<i></i>すると、現在のタスクはバックグラウンドに移動し、新しいタスクのルート アクティビティが表示されます。しばらくして、ユーザーがホーム画面に戻り 1 つ前のアプリケーション（タスク）を選択すると、そのタスクがスタック内の 4 つのアクティビティとともにフォアグラウンドに移動します。ここでユーザーが [戻る] キーを押しても、中断したばかりのアプリケーション（1 つ前のタスクのルート アクティビティ）は表示されません。代わりに、スタックの最上位のアクティビティがポップされ、同じタスクの 1 つ前のアクティビティが表示されます。 +</p> + +<p> +アクティビティとタスクの動作としては、ここで説明した動作がデフォルトです。ただし、この動作のほとんどの要素は変更可能です。タスクとアクティビティの関連付けやタスク内でのアクティビティの動作は、アクティビティを開始した Intent オブジェクトのフラグ セットと、マニフェストに指定されているアクティビティの <code><a href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a></code> 要素の属性セットとの相互作用によって決まります。リクエスト側と応答側の両方が動作に影響を及ぼします。 +</p> + +<p> +この点において、主に使用する Intent フラグは以下のとおりです: + +<p style="margin-left: 2em">{@code FLAG_ACTIVITY_NEW_TASK} <br/>{@code FLAG_ACTIVITY_CLEAR_TOP} <br/>{@code FLAG_ACTIVITY_RESET_TASK_IF_NEEDED} <br/>{@code FLAG_ACTIVITY_SINGLE_TOP}</p> + +<p> +また、主に使用する {@code <activity>} 属性は以下のとおりです: + +<p style="margin-left: 2em">{@code taskAffinity} <br/>{@code launchMode} <br/>{@code allowTaskReparenting} <br/>{@code clearTaskOnLaunch} <br/>{@code alwaysRetainTaskState} <br/>{@code finishOnTaskLaunch}</p> + +<p> +以降のセクションでは、これらのフラグや属性の役割、相互作用の仕組み、使用する際の留意事項などについて説明します。 +</p> + + +<h3 id="afftask">親和性と新しいタスク</h3> + +<p> +デフォルトでは、アプリケーション内のすべてのアクティビティは相互に親和性があり、すべてのアクティビティができる限り同じタスクに属そうとします。<i></i>ただし、{@code <activity>} 要素の {@code taskAffinity} 属性を使用して、アクティビティごとに個別の親和性を設定することもできます。つまり、別々のアプリケーションで定義されているアクティビティで親和性を共有したり、同じアプリケーションで定義されているアクティビティに別々の親和性を割り当てたりできるということです。親和性が作用する状況は 2 つあります。1 つはアクティビティを起動する Intent オブジェクトに {@code FLAG_ACTIVITY_NEW_TASK} フラグが含まれている場合、もう 1 つはアクティビティの {@code allowTaskReparenting} 属性が "{@code true}" に設定されている場合です。 +</p> + +<dl> +<dt><code>{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}</code> フラグ</dt> +<dd>既に説明したとおり、新しいアクティビティは、デフォルトでは {@code startActivity()} を呼び出したアクティビティのタスクの一部として起動します。つまり、呼び出し側のアクティビティと同じスタックにプッシュされるということです。しかし、{@code startActivity()} に渡された Intent オブジェクトに {@code FLAG_ACTIVITY_NEW_TASK} フラグが含まれている場合、システムはその新しいアクティビティを別のタスクに収容しようとします。フラグの名前からも判断できますが、ほとんどの場合は新しいタスクが開始されます。ただし常にそうなるとは限りません。既存のタスクに新しいアクティビティと同じ親和性が割り当てられている場合、そのアクティビティはそのタスクの一部として起動します。そうでない場合には、新しいタスクが開始されます。</dd> + +<dt><code><a +href="{@docRoot}guide/topics/manifest/activity-element.html#reparent">allowTaskReparenting</a></code> 属性</dt> +<dd>{@code allowTaskReparenting} 属性が "{@code true}" に設定されているアクティビティは、そのアクティビティと親和性のあるタスクがフォアグラウンドに移ったときに、アクティビティを開始したタスクから親和性のあるタスクに移動できます。たとえば、旅行アプリケーションの一部として、選択された都市の天気予報を表示するアクティビティが定義されているとします。このアクティビティには、同じアプリケーション内の他のアクティビティと同じ親和性（デフォルトの親和性）が割り当てられていますが、その親の割り当てを変更することも可能です。あるアクティビティが天気予報アクティビティを開始すると、その時点では開始側のアクティビティと同じタスクに属した状態になります。しかし、次に旅行アプリケーションがフォアグラウンドに移ると、天気予報アクティビティの割り当てが変更され、旅行アプリケーションのタスクの一部として表示されます。</dd> +</dl> + +<p> +ユーザーから見て複数の「アプリケーション」が 1 つの {@code .apk} ファイルに含まれている場合は、それぞれのアプリケーションに関連付けられているアクティビティに別々の親和性を割り当てることをおすすめします。 +</p> + + +<h3 id="lmodes">起動モード</h3> + +<p> +<code><a href="{@docRoot}guide/topics/manifest/activity-element.html#lmode">launchMode</a></code> 属性の {@code <activity>} 要素には、以下の 4 種類の起動モードを割り当てることができます: +</p> + +<p style="margin-left: 2em">"{@code standard}"（デフォルト モード）<br>"{@code singleTop}"<br>"{@code singleTask}"<br>"{@code singleInstance}"</p> + +<p> +これらのモードは、それぞれが以下の 4 つの点で異なります: +</p> + +<ul> + +<li><b>インテントに応答するアクティビティをどのタスクに保持するか</b>。"{@code standard}" および "{@code singleTop}" モードの場合は、そのインテントを開始した（つまり <code>{@link android.content.Context#startActivity startActivity()}</code> を呼び出した）タスクに保持されます。ただし、Intent オブジェクトに <code>{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK}</code> フラグが含まれている場合は、前のセクション<a href="#afftask">親和性と新しいタスク</a>で説明したとおり、別のタスクが選択されます。 + +<p> +一方、"{@code singleTask}" および "{@code singleInstance}" モードの場合は、アクティビティが常にタスクのルート アクティビティになります。タスクは定義されており、他のタスクの一部として起動されることはありません。 +</p> + +<li><p><b>アクティビティのインスタンスを複数生成できるか</b>。"{@code standard}" または "{@code singleTop}" アクティビティは複数回インスタンス化できます。それらのインスタンスを複数のタスクに割り当てることも、特定のタスクに同じアクティビティの複数のインスタンスを割り当てることも可能です。 +</p> + +<p> +一方、"{@code singleTask}" および "{@code singleInstance}" アクティビティのインスタンスは 1 つに制限されます。これらのアクティビティはタスクのルートに当たります。したがって、これらのタスクの複数のインスタンスがデバイス上に同時に存在することはないということになります。 +</p> + +<li><p><b>インスタンスのタスクに他のアクティビティを含めることができるか</b>。"{@code singleInstance}" アクティビティは、そのタスク内の唯一のアクティビティとして単独で動作します。ここから別のアクティビティを開始した場合、そのアクティビティは起動モードに関係なく、あたかもインテントに {@code FLAG_ACTIVITY_NEW_TASK} フラグが含まれているかのように別のタスクで起動します。"{@code singleInstance}" モードと "{@code singleTask}" モードは、これ以外の点ではまったく同じです。</p> + +<p> +他の 3 つのモードでは、タスクに複数のアクティビティを割り当てることができます。"{@code singleTask}" アクティビティは、常にタスクのルート アクティビティになりますが、同じタスクに割り当てることになる別のアクティビティを開始することができます。"{@code standard}" および "{@code singleTop}" アクティビティのインスタンスは、スタック内のどの位置にでも配置できます。 +</p></li> + +<li><b>クラスの新しいインスタンスを起動して新しいインテントを処理するかどうか</b>。デフォルトの "{@code standard}" モードの場合は、新しいインテントに応答するときには必ず新しいインスタンスが作成されます。それぞれのインスタンスで処理するインテントは 1 つのみです。"{@code singleTop}" モードの場合は、クラスの既存のインスタンスが対象タスクのアクティビティ スタックの最上位にあれば、それを再利用して新しいインテントを処理します。スタックの最上位にない場合は再利用されません。代わりに、新しいインスタンスが作成されてスタックにプッシュされ、新しいインテントの処理に使用されます。 + +<p> +たとえば、タスクのアクティビティ スタックに、ルート アクティビティ A とアクティビティ B、C、D が含まれているとします。スタック内のアクティビティの順序は A-B-C-D で D が最上位です。ここに、アクティビティのタイプが D のインテントが届きます。D の起動モードがデフォルトの "{@code standard}" である場合は、そのクラスの新しいインスタンスが起動し、スタックは A-B-C-D-D となります。しかし、D の起動モードが "{@code singleTop}" であれば、スタックの最上位は D なので、新しいインテントは既存のインスタンスによって処理されるはずです。したがって、スタックは A-B-C-D のままとなります。 +</p> + +<p> +一方、届いたインテントのアクティビティ タイプが B だった場合は、B のモードが "{@code standard}" であっても "{@code singleTop}"であっても B の新しいインスタンスが起動します。これは B がスタックの最上位ではないためで、結果としてスタックは A-B-C-D-B となります。 +</p> + +<p> +"{@code singleTask}" または "{@code singleInstance}" アクティビティの場合は、既に説明したとおり同時に複数のインスタンスが存在することはないため、インスタンスは常に新しいインテントを処理することになります。"{@code singleInstance}" アクティビティはスタック内の唯一のアクティビティであるため、常にスタックの最上位、つまりインテントを処理する位置にあります。一方、"{@code singleTask}" アクティビティは、スタック内の上位に他のアクティビティがある場合とない場合があります。上位にアクティビティがある場合、インテントを処理する位置にはないため、そのインテントはドロップされます（インテントがドロップされたとしても、そのインテントが届いたことによって、タスクがフォアグラウンドに移ったままの状態になります）。 +</p> +</li> + +</ul> + +<p> +既存のアクティビティで新しいインテントを処理することになった場合は、<code>{@link android.app.Activity#onNewIntent onNewIntent()}</code> の呼び出しによって Intent オブジェクトがアクティビティに渡されます（最初にアクティビティを開始したインテント オブジェクトは <code>{@link android.app.Activity#getIntent getIntent()}</code> を呼び出して取得できます）。 +</p> + +<p> +なお、新しいインテントを処理するためにアクティビティの新しいインスタンスが作成された場合、ユーザーは [[]戻る] キーを押して 1 つ前の状態（1 つ前のアクティビティ）に戻ることができます。しかし、アクティビティの既存のインスタンスで新しいインテントを処理する場合は、[[]戻る] キーを押しても、新しいインテントが届く前にそのインスタンスで処理していた作業に戻ることはできません。 +</p> + +<p> +起動モードについて詳しくは、<code><a href="{@docRoot}guide/topics/manifest/activity-element.html"><activity></a></code> 要素の説明をご覧ください。 +</p> + + +<h3 id="clearstack">スタックのクリア</h3> + +<p> +ユーザーがタスクを長時間放置すると、タスクのルート アクティビティを除くすべてのアクティビティがクリアされます。ユーザーがタスクに戻ると、タスクは以前のように表示されますが、残っているのは最初のアクティビティだけです。つまり、一定の時間が経過していればユーザーは以前の作業を放棄していて、新しい作業をするためにそのタスクに戻ってきたと考えるわけです。 +</p> + +<p> +これがデフォルトです。この動作を変更したい場合は、以下のアクティビティ属性を使用します: +</p> + +<dl> +<dt><code><a +href="{@docRoot}guide/topics/manifest/activity-element.html#always">alwaysRetainTaskState</a></code> 属性</dt> +<dd>タスクのルート アクティビティでこの属性を "{@code true}" に設定すると、上で説明したデフォルトの動作は発生しません。長時間経過しても、タスク内のすべてのアクティビティはそのまま残されます。</dd> + +<dt><code><a +href="{@docRoot}guide/topics/manifest/activity-element.html#clear">clearTaskOnLaunch</a></code> 属性</dt> +<dd>タスクのルート アクティビティでこの属性を "{@code true}" に設定した場合、ユーザーがいったんタスクを離れると、戻ったときにはルートを含むすべてのアクティビティがクリアされています。つまり、{@code alwaysRetainTaskState} の正反対の動作になります。ユーザーが一瞬でもタスクを離れると、最初の状態からやり直すことになります。</dd> + +<dt><code><a +href="{@docRoot}guide/topics/manifest/activity-element.html#finish">finishOnTaskLaunch</a></code> 属性</dt> +<dd>この属性は {@code clearTaskOnLaunch} に似ていますが、タスク全体ではなく単一のアクティビティに作用します。また、ルート アクティビティを含むどのアクティビティもクリアの対象となりえます。この属性が "{@code true}" に設定されたアクティビティは、現在のセッションの間のみタスクの一部を形成します。ユーザーがいったんそのタスクから離れてから、再度タスクに戻ると、このアクティビティはクリアされています</dd> +</dl> + +<p> +アクティビティをスタックから削除する方法は他にもあります。Intent オブジェクトに <code>{@link +android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP FLAG_ACTIVITY_CLEAR_TOP}</code> フラグが含まれており、そのインテントを処理すべきタイプのアクティビティのインスタンスが対象タスクのスタック内に存在する場合は、そのインスタンスがスタックの最上位になってインテントに応答できるよう、それより上位のアクティビティはすべてクリアされます。指定されたアクティビティの起動モードが "{@code standard}" である場合は、そのアクティビティもスタックから削除され、新しいインスタンスが起動してインテントを処理します。起動モード "{@code standard}" では、新しいインテントを処理する際、常に新しいインスタンスが作成されるためです。 +</p> + +<p> +{@code FLAG_ACTIVITY_CLEAR_TOP} は、ほとんどの場合 {@code FLAG_ACTIVITY_NEW_TASK} と組み合わせて使用します。これらのフラグを組み合わせると、別のタスクに既に存在しているアクティビティを探し、それをインテントに応答できる位置に配置できます。 +</p> + + +<h3 id="starttask">タスクの開始</h3> + +<p> +アクティビティをタスクのエントリ ポイントとして設定するには、アクションとして "{@code android.intent.action.MAIN}"、カテゴリとして "{@code android.intent.category.LAUNCHER}" を指定したインテント フィルタをアクティビティに追加します（このタイプのフィルタの例については、<a href="#ifilters">インテント フィルタ</a>をご覧ください）。このタイプのフィルタを追加すると、アクティビティのアイコンとラベルがアプリケーション ランチャに表示されます。これにより、ユーザーがタスクを起動するための手段を提供できるだけでなく、起動後はいつでもそのタスクに戻れるようにすることができます。 +</p> + +<p> +この 2 番目の機能、つまりユーザーがいったんタスクを離れても後で戻ることができるようにする点が重要です。この理由から、アクティビティに {@code MAIN} と {@code LAUNCHER} フィルタが指定されている場合は、必ずタスクが開始される起動モード（"{@code singleTask}" または "{@code singleInstance}"）を使用する必要があります。たとえば、このフィルタを指定しなかった場合を考えてみましょう。インテントが "{@code singleTask}" アクティビティを起動し、新しいタスクが開始され、ユーザーがしばらくの間このタスクで作業を行います。その後、ユーザーが [ホーム] キーを押したとします。ホーム画面が表示され、先ほどのタスクはバックグラウンドに移動します。しかし、このタスクはアプリケーション ランチャには表示されていないため、ユーザーがタスクに戻るための手段がありません。 +</p> + +<p> +{@code FLAG_ACTIVITY_NEW_TASK} フラグにも、これと同じような難しさがあります。このフラグを指定したアクティビティでは、新しいタスクを開始した後にユーザーが [ホーム] キーを押してそのタスクを離れた場合に備え、タスクに戻るための手段を用意しておく必要があります。一部のエンティティ（たとえば通知マネージャ）は、アクティビティを常に外部タスクとして開始します。エンティティの一部として開始することはないため、{@code startActivity()} に渡すインテントには必ず {@code FLAG_ACTIVITY_NEW_TASK} を指定します。外部エンティティから呼び出すことのできるアクティビティでこのフラグが使用されている可能性がある場合は、開始されたタスクにユーザーが戻るための手段を別途提供するようにしてください。 +</p> + +<p> +ユーザーがアクティビティに戻ることができるようにしない場合は、{@code <activity>} 要素の {@code finishOnTaskLaunch} を "{@code true}" に設定します。詳しくは、<a href="#clearstack">スタックのクリア</a>をご覧ください。 +</p> + + +<h2 id="procthread">プロセスとスレッド</h2> + +<p> +Android では、最初のアプリケーション コンポーネントを実行する必要が生じると、そのための Linux プロセスを単一の実行スレッドで開始します。デフォルトでは、アプリケーションのすべてのコンポーネントがそのプロセスとスレッドで実行されます。 +</p> + +<p> +ただし、コンポーネントが他のプロセスで実行されるようにしたり、特定のプロセスに使用する追加スレッドを生成したりすることも可能です。 +</p> + + +<h3 id="procs">プロセス</h3> + +<p> +コンポーネントを実行するプロセスは、マニフェスト ファイルで管理します。コンポーネントの各要素（{@code <activity>}、{@code <service>}、{@code <receiver>}、および {@code <provider>}）には {@code process} 属性があり、そのコンポーネントをどのプロセスで実行すべきかを指定できるようになっています。これらの属性の設定によって、それぞれのコンポーネントを専用のプロセスで実行したり、一部のコンポーネントだけでプロセスを共有したりできます。また、別々のアプリケーションのコンポーネントが、同じプロセスで実行されるように設定することもできます。この場合は、それらのアプリケーションが同じ Linux ユーザー ID を共有し、同じ認証機関によって署名されている必要があります。{@code <application>} 要素にも {@code process} 属性があり、すべてのコンポーネントに適用されるデフォルト値を設定できます。 +</p> + +<p> +すべてのコンポーネントは指定されたプロセスのメイン スレッドでインスタンス化され、コンポーネントに対するシステム コールはそのスレッドからディスパッチされます。1 つのインスタンスに対して、複数のスレッドが作成されることはありません。したがって、システム コールに応答するメソッド（たとえば、後ほど<a href="#lcycles">コンポーネント ライフサイクル</a>で説明するライフサイクル通知や、ユーザーのアクションを報告する <code>{@link android.view.View#onKeyDown View.onKeyDown()}</code> のようなメソッド）は、常にそのプロセスのメイン スレッドで実行されます。つまり、コンポーネントがシステムから呼び出されたときに、プロセス内の他のコンポーネントの実行を妨げないよう、実行に時間がかかる処理や他の妨げになることの多い処理（ネットワーク処理、ループ計算など）をできる限り避ける必要があるということです。時間がかかる処理には別のスレッドを生成できます。詳しくは、次の<a href="#threads">スレッド</a> セクションをご覧ください。 +</p> + +<p> +状況によっては、Android がプロセスを終了させるべきと判断する場合があります。たとえば、メモリが不足してきた場合や、他のプロセスでユーザーにすばやく応答する必要がある場合です。プロセスが終了すると、そのプロセス内で実行されているアプリケーション コンポーネントは破棄されます。それらのコンポーネントで処理する作業がもう一度発生すると、そのためのプロセスが再び開始されます。 +</p> + +<p> +Android では、どのプロセスを終了させるかを判断するため、ユーザーにとっての相対的な重要度を重み付けして管理します。たとえば、アクティビティがまだ画面に表示されているプロセスを終了させるよりも、アクティビティが画面に表示されていないプロセスを終了させる方が合理的です。したがって、プロセスを終了させるかどうかは、そのプロセスで実行されているコンポーネントの状態に応じて判断されるということです。コンポーネントの状態については、後ほど<a href="#lcycles">コンポーネントのライフサイクル</a>で詳しく説明します。 +</p> + + +<h3 id="threads">スレッド</h3> + +<p> +アプリケーションを単一のプロセスに限定したとしても、バックグラウンドでの処理にスレッドが必要になることはよくあります。ユーザー インターフェースはユーザーのアクションに対して常にすばやく応答できなければならないため、アクティビティをホストするスレッドで、ネットワーク ダウンロードのような時間のかかる処理を一緒にホストしないようにする必要があります。すぐに完了しない可能性のあるすべての処理は、別のスレッドに割り当てるようにしてください。 +</p> + +<p> +スレッドは、標準の Java {@link java.lang.Thread} オブジェクトを使用してコード内で作成します。Android には、スレッドを管理するための便利なクラスが数多く用意されています。たとえば、スレッド内でメッセージ ループを実行するための {@link android.os.Looper}、メッセージを処理するための {@link android.os.Handler}、メッセージ ループでスレッドを設定するための {@link android.os.HandlerThread} などがあります。 +</p> + + +<h3 id="rpc">リモート プロシージャ コール</h3> + +<p> +Androidは軽量な仕組みのリモート・プロシージャ・コール (RPC) を採用しています。RPC とは、メソッドをローカルで呼び出しますが、実行はリモート（別のプロセス）で行い、その結果を呼び出し側に返します。そのためには、メソッド呼び出しとそれに付随するデータをオペレーティングシステムが解釈できるレベルまで分解してから、それらをローカルのプロセスとアドレス空間からリモートのプロセスとアドレス空間に転送し、リモートで呼び出しを再構築する必要があります。戻り値は、反対方向に転送しなければなりません。Android にはこの処理を行うためのコードがすべて用意されているため、RPC インターフェースを定義して実装するだけで RPC を利用できます。 +</p> + +<p> +RPC インターフェースに含めることができるのはメソッドのみです。すべてのメソッドは、戻り値がない場合でも同期的に実行されます（つまり、リモート メソッドが完了するまでローカル メソッドがブロックされます）。 +</p> + +<p> +このメカニズムを簡単に説明すると次のようになります。まず、シンプルなインターフェース定義言語（IDL）を使用して、実装したい RPC インターフェースを宣言します。<code><a href="{@docRoot}guide/components/aidl.html">aidl</a></code> ツールにより、RPC インターフェースの宣言から Java インターフェース定義が生成されます。この定義は、ローカルとリモートの両方のプロセスで使用する必要があります。定義には、次の図に示すように 2 つの内部クラスが含まれています: +</p> + +<p style="margin-left: 2em"> +<img src="{@docRoot}images/binder_rpc.png" alt="RPC のメカニズム" /> +</p> + +<p> +これらの内部クラスには、IDL で宣言したインターフェースのリモート プロシージャ コールを管理するために必要なコードがすべて含まれています。どちらの内部クラスも {@link android.os.IBinder} インターフェースを実装します。一方の内部クラスは、ローカルのシステムで内部的に使用しますが、記述するコードでは無視しても構いません。もう一方の内部クラスはスタブと呼ばれ、{@link android.os.Binder} クラスを拡張します。スタブには、IPC（プロセス間通信）呼び出しを発生させるための内部コードに加え、IDL で宣言した RPC インターフェース内のメソッドの宣言が含まれます。これらのメソッドを実装するには、図に示すようにスタブをサブクラス化します。２つの内部クラスのうちの一方は、システムがローカルかつ内部的に使用するので、開発者が記述するコードでは無視してかまいません。... リモート側では、図のようにスタブをサブクラス化して、これらのメソッドを実装する必要があります。 +</p> + +<p> + 通常、リモート プロセスはサービスで管理します。サービスなら、プロセスや他のプロセスへの接続に関する情報をシステムに伝えることができるからです。サービスには、{@code aidl} ツールで生成されたインターフェース ファイルと、RPC メソッドを実装するスタブ サブクラスの両方を持たせることになります。サービスのクライアントには、{@code aidl} ツールで生成されたインターフェース ファイルのみを持たせます。 +</p> + +<p> +以下に、サービスとそのクライアントの間の接続がどのように設定されるかを示します: +</p> + +<ul> +<li>サービスのクライアント（ローカル側）には <code>{@link android.content.ServiceConnection#onServiceConnected +onServiceConnected()}</code> および<code>{@link android.content.ServiceConnection#onServiceDisconnected +onServiceDisconnected()}</code> メソッドが実装されているため、リモート サービスとの接続が確立されたときや切断されたときには通知を受けることができます。通知があり次第、<code>{@link android.content.Context#bindService bindService()}</code> を呼び出して接続を設定します。 +</li> + +<li> +サービスの <code>{@link android.app.Service#onBind onBind()}</code> メソッドは、受け取ったインテント（{@code bindService()} に渡されたインテント）に応じて、接続を承認または拒否するために実装します。接続が承認されると、接続を承認するのであれば、スタブ サブクラスのインスタンスを返します。 +</li> + +<li>サービスが接続を承認すると、Android がクライアントの {@code onServiceConnected()} メソッドを呼び出し、IBinder オブジェクト（サービスが管理するスタブ サブクラスのプロキシ）を渡します。クライアントは、このプロキシを介してリモートサービスを呼び出すことができます。 +</li> +</ul> + +<p> +ここでは、説明を簡単にするため、RPC メカニズムの細かい点は省略しています。詳しくは、<a href="{@docRoot}guide/components/aidl.html">Designing a Remote Interface Using AIDL</a>、および {@link android.os.IBinder IBinder} クラスの説明をご覧ください。 +</p> + + +<h3 id="tsafe">スレッドセーフなメソッド</h3> + +<p> +状況によっては実装したメソッドが複数のスレッドから呼び出されることもあるため、スレッドセーフな記述を心掛ける必要があります。 +</p> + +<p> +前のセクションで説明した RPC のようにメソッドをリモートで呼び出すことができる場合は、このような状況が特に発生しやすくなります。IBinder オブジェクトに実装されているメソッドを IBinder と同じプロセスから呼び出すと、そのメソッドは呼び出し側のスレッドで実行されます。一方、別のプロセスからメソッドを呼び出した場合は、プロセスのメイン スレッドではなく、IBinder と同じプロセス内に保持されているスレッドのプールから選択されたスレッドで実行されます。たとえば、サービスの {@code onBind()} メソッドはそのサービスのプロセスのメイン スレッドから呼び出されるのに対し、{@code onBind()} から返されたオブジェクトに実装されているメソッド（たとえば RPC メソッドを実装するスタブ サブクラス）はプール内のスレッドから呼び出されます。サービスには複数のクライアントを割り当てることができるため、複数のプール スレッドを同じ IBinder に同時に割り当てることも可能です。したがって、IBinder メソッドはスレッドセーフになるように実装する必要があります。 +</p> + +<p> +同様に、コンテンツ プロバイダも別のプロセスからのデータ リクエストを受け取ることができます。ContentResolver および ContentProvider クラスはプロセス間通信の管理の詳細を隠蔽しますが、それらのリクエストに応答する ContentProvider メソッド（<code>{@link android.content.ContentProvider#query query()}</code>、<code>{@link android.content.ContentProvider#insert insert()}</code>、<code>{@link android.content.ContentProvider#delete delete()}</code>、<code>{@link android.content.ContentProvider#update update()}</code>、および <code>{@link android.content.ContentProvider#getType getType()}</code> メソッド）は、プロセスのメイン スレッドではなく、コンテンツ プロバイダのプロセス内のスレッドのプールから呼び出されます。これらのメソッドを同時に呼び出すことのできるメソッドの数に制限はありません。したがって、これらのメソッドもスレッドセーフになるように実装する必要があります。 +</p> + + +<h2 id="lcycles">コンポーネントのライフサイクル</h2> + +<p> +アプリケーション コンポーネントにはライフサイクルがあります。ライフサイクルは、インテントへ応答することでのインスタンス化で始まり、そのインスタンスの破棄で終わります。この間、コンポーネントがアクティブなときとアクティブでないときがあり、アクティビティであればユーザーから見えるときと見えないときがあります。このセクションでは、アクティビティ、サービス、およびブロードキャスト レシーバのライフサイクルについて説明します。具体的には、それぞれがライフタイムの間に取ることのできる状態、状態の遷移を通知する方法、およびそれらの状態が、コンポーネントを実行しているプロセスが終了させられたり、インスタンスが破棄されたりする可能性への影響などについて説明します。 +</p> + + +<h3 id="actlife">アクティビティのライフサイクル</h3> + +<p>アクティビティは、基本的に以下の 3 つの状態を取ります:</p> + +<ul> +<li> 状態がアクティブまたは実行中のアクティビティは、画面のフォアグラウンドに表示されている（つまり現在のタスクのアクティビティ スタックの最上位にある）アクティビティです。<em></em><em></em>これが、ユーザーのアクションの焦点となっているアクティビティです。</li> + +<li><p>状態が一時停止のアクティビティは、ユーザーのアクションの焦点から外れていますが、まだユーザーから見ることのできるアクティビティです。<em></em>つまり、それよりも前面に他のアクティビティが表示されていますが、そのアクティビティが透明か全画面表示でないかのどちらかで、一時停止しているアクティビティの一部が見えている状態です。一時停止しているアクティビティは、完全に動作しています（すべての状態やメンバー情報は保持されており、ウィンドウ マネージャにアタッチされたままになっています）。ただし、メモリが極端に不足した場合は、システムによって強制終了させられる可能性があります。</p></li> + +<li><p>状態が停止のアクティビティは、別のアクティビティに隠されて完全に見えなくなったアクティビティです。<em></em>すべての状態とメンバー情報はまだ保持しています。しかし、もうユーザーに対して表示されていないため、他でメモリが必要な場合は強制終了させられる可能性が高いアクティビティです。</p></li> +</ul> + +<p> +システムが一時停止または停止しているアクティビティをメモリから削除する場合は、アクティビティの {@link android.app.Activity#finish finish()} メソッドを呼び出して終了を要求するか、単純のそのプロセスを強制終了します。そのアクティビティをもう一度ユーザーに表示する際は、完全に再起動して以前の状態に復元する必要があります。 +</p> + +<p> +アクティビティがある状態から別の状態に遷移すると、以下の protected メソッドに対する呼び出しによって変更が通知されます: +</p> + +<p style="margin-left: 2em">{@code void onCreate(Bundle <i>savedInstanceState</i>)} <br/>{@code void onStart()} <br/>{@code void onRestart()} <br/>{@code void onResume()} <br/>{@code void onPause()} <br/>{@code void onStop()} <br/>{@code void onDestroy()}</p> + +<p> +これらのメソッドはすべて、状態が変化したときに適切な処理を行うためにオーバーライドできるフックです。オブジェクトが初めてインスタンス化されたときに初期設定を行うため、すべてのアクティビティには <code>{@link android.app.Activity#onCreate onCreate()}</code> を実装する必要があります。多くのアクティビティには、データの変更をコミットするための <code>{@link android.app.Activity#onPause onPause()}</code> も実装します。これを実装しない場合は、何らかの方法でユーザーとの対話を停止できるようにしておく必要があります。 +</p> + +<div class="sidebox-wrapper"> +<div class="sidebox"> +<h2>スーパークラスの呼び出し</h2> +<p> +どのアクティビティ ライフサイクル メソッドの実装でも、必ず最初にスーパークラス バージョンを呼び出す必要があります。次に例を示します: +</p> + +<pre>protected void onPause() { + super.onPause(); + . . . +}</pre> +</div> +</div> + + +<p> +これら 7 つのメソッドを使用すると、アクティビティのライフサイクル全体を定義できます。これらを実装することで、ネストされた 3 つのループからなるアクティビティのライフサイクルを監視できます: +</p> + +<ul> +<li>アクティビティの<b>ライフタイム全体</b>は、<code>{@link android.app.Activity#onCreate onCreate()}</code> が初めて呼び出されたときに始まり、最後に <code>{@link android.app.Activity#onDestroy}</code> が呼び出されたときに終了します。アクティビティは、{@code onCreate()} で「全体的」な状態のすべての初期設定を行い、{@code onDestroy()} 残っていたリソースをすべて解放します。たとえば、ネットワークからのデータのダウンロードをバックグラウンドで実行するスレッドは、{@code onCreate()} で作成され、{@code onDestroy()} で停止します。</li> + +<li><p>アクティビティの<b>可視ライフタイム</b>は、<code>{@link android.app.Activity#onStart onStart()}</code> の呼び出しで始まり、対応する <code>{@link android.app.Activity#onStop onStop()}</code> の呼び出しで終了します。このライフタイムの間は、ユーザーが画面上でそのアクティビティを見ることができます。ただし、アクティビティがフォアグラウンドにない場合や、ユーザーと対話していない場合もあります。これらの 2 つのメソッドの間は、ユーザーに対してアクティビティを表示するために必要なリソースを確保できます。たとえば、{@code onStart()} で {@link android.content.BroadcastReceiver} を登録して UI に影響する変化を監視し、表示しているアクティビティがユーザーから見えなくなったら {@code onStop()} で登録を解除できます。{@code onStart()} および {@code onStop()} メソッドは、アクティビティがユーザーから見え隠れするたびに繰り返し呼び出すことができます。</p></li> + +<li><p>アクティビティの<b>フォアグラウンド ライフタイム</b>は、<code>{@link android.app.Activity#onResume onResume()}</code> の呼び出しで始まり、対応する <code>{@link android.app.Activity#onPause onPause()}</code> の呼び出しで終了します。フォアグラウンド ランタイムの間は、このアクティビティが他のどのアクティビティよりも前面に表示され、ユーザーと対話しています。アクティビティは、一時停止状態と再開状態の間を頻繁に遷移します。たとえば、デバイスがスリープ状態になるときや新しいアクティビティを開始するときには {@code onPause()} が呼び出され、アクティビティの結果や新しいインテントが届いたときには {@code onResume()} が呼び出されます。したがって、これらのメソッドを記述する際は、できるだけ軽量化しておく必要があります。</p></li> +</ul> + +<p> +次の図に、これらのループとアクティビティの遷移経路を示します。色の付いた楕円は、アクティビティが取ることのできる主な状態です。長方形は、アクティビティが状態間を遷移するときに処理を実行するために実装できるコールバック メソッドを表します。 +<p> + +<p style="margin-left: 2em"><img src="{@docRoot}images/activity_lifecycle.png" +alt="Android のアクティビティ ライフサイクルの状態遷移図" /></p> + +<p> +次の表では、各メソッドについて詳しく説明し、ライフサイクル全体における位置付けを示します: +</p> + +<table border="2" width="85%" frame="hsides" rules="rows"> +<colgroup align="left" span="3"></colgroup> +<colgroup align="left"></colgroup> +<colgroup align="center"></colgroup> +<colgroup align="center"></colgroup> + +<thead> +<tr><th colspan="3">メソッド</th> <th>説明</th> <th>強制終了</th> <th>次</th></tr> +</thead> + +<tbody> +<tr> + <td colspan="3" align="left"><code>{@link android.app.Activity#onCreate onCreate()}</code></td> + <td>アクティビティが初めて作成されるときに呼び出されます。通常の静的な設定（ビューの作成、リストへのデータのバインドなど）は、すべてのこのメソッドで行う必要があります。このアクティビティの 以前の状態が保存されていた場合、このメソッドにはその状態を保持している Bundle オブジェクトが引数として（詳しくは、後述の<a href="#actstate">アクティビティの状態の保存</a>をご覧ください）。 + <p>この後には、必ず {@code onStart()} が呼び出されます。</p></td> + <td align="center">不可</td> + <td align="center">{@code onStart()}</td> +</tr> + +<tr> + <td rowspan="5" style="border-left: none; border-right: none;"> </td> + <td colspan="2" align="left"><code>{@link android.app.Activity#onRestart +onRestart()}</code></td> + <td>アクティビティが停止した後、それをもう一度開始する直前に呼び出されます。 + <p>この後には、必ず {@code onStart()} が呼び出されます。</p></td> + <td align="center">不可</td> + <td align="center">{@code onStart()}</td> +</tr> + +<tr> + <td colspan="2" align="left"><code>{@link android.app.Activity#onStart onStart()}</code></td> + <td>アクティビティがユーザーから見えるようになる直前に呼び出されます。 + <p>その後、アクティビティがフォアグラウンドに表示された場合は {@code onResume()} が、他のアクティビティの後ろに隠れた場合は {@code onStop()} が呼び出されます。</p></td> + <td align="center">不可</td> + <td align="center">{@code onResume()} <br/>または<br/>{@code onStop()}</td> +</tr> + +<tr> + <td rowspan="2" style="border-left: none;"> </td> + <td align="left"><code>{@link android.app.Activity#onResume onResume()}</code></td> + <td>アクティビティがユーザーとの対話を開始する直前に呼び出されます。この時点で、アクティビティはアクティビティ スタックの最上位にあり、ユーザーからの入力はこのアクティビティに対して行われます。 + <p>この後には、必ず {@code onPause()} が呼び出されます。</p></td> + <td align="center">不可</td> + <td align="center">{@code onPause()}</td> +</tr> + +<tr> + <td align="left"><code>{@link android.app.Activity#onPause onPause()}</code></td> + <td>システムが別のアクティビティを開始しようとしているときに呼び出されます。このメソッドは、保存されていない変更を永続データにコミットする場合や、アニメーションのように CPU を大量に消費する処理を停止する場合に使用するのが一般的です。このメソッドが終了するまでは次のアクティビティが開始されたないため、できる限り短時間で実行できるようにしておく必要があります。 + <p>その後、アクティビティがフォアグラウンドに戻った場合は {@code onResume()} が、ユーザーから見えなくなった場合は {@code onStop()} が呼び出されます。</td> + <td align="center"><strong style="color:#800000">可能</strong></td> + <td align="center">{@code onResume()} <br/>または<br/>{@code onStop()}</td> +</tr> + +<tr> + <td colspan="2" align="left"><code>{@link android.app.Activity#onStop onStop()}</code></td> + <td>アクティビティがユーザーから見えなくなったときに呼び出されます。見えなくなる状況としては、アクティビティが破棄された場合や、再開された別のアクティビティ（既存か新規かを問わず）によって隠された場合が考えられます。 + <p>その後、アクティビティがユーザーとの対話に戻った場合は {@code onRestart()} が、アクティビティが完全に終了する場合は {@code onDestroy()} が呼び出されます。</p></td> + <td align="center"><strong style="color:#800000">可能</strong></td> + <td align="center">{@code onRestart()} <br/>または<br/>{@code onDestroy()}</td> +</tr> + +<tr> + <td colspan="3" align="left"><code>{@link android.app.Activity#onDestroy +onDestroy()}</code></td> + <td>アクティビティが破棄される前に呼び出されます。これが、アクティビティが受け取る最後の呼び出しとなります。このメソッドが呼び出される状況としては、アクティビティが完了する場合（<code>{@link android.app.Activity#finish + finish()}</code> が呼び出されたとき）や、システムが領域を確保するために一時的にそのアクティビティのインスタンスを破棄する場合が考えられます。これらの 2 つの状況は、<code>{@link + android.app.Activity#isFinishing isFinishing()}</code> メソッドを使用して識別できます。</td> + <td align="center"><strong style="color:#800000">可能</strong></td> + <td align="center"><em>なし</em></td> +</tr> +</tbody> +</table> + +<p> +表の<b>強制終了</b>列に注目してください。この列は、メソッドが終了した後であれば、システムがアクティビティのコードの別の行を実行することなくいつでもアクティビティを実行しているプロセスを強制終了できるかどうかを示しています。<em></em>{@code onPause()}、{@code onStop()}、および {@code onDestroy()} メソッドの 3 つは「可能」となっています。1 番目に挙げた {@code onPause()} だけは、プロセスが強制終了する前に必ず呼び出されます。{@code onStop()} と {@code onDestroy()} は、必ず呼び出されるとは限りません。したがって、永続データ（たとえばユーザーによる編集）をストレージに書き込む際は {@code onPause()} を使用する必要があります。 +</p> + +<p> +<b>強制終了</b>列が「不可」になっているメソッドは、それらが呼び出された瞬間から、アクティビティを実行しているプロセスを保護して強制終了されないようにします。したがって、アクティビティが強制終了可能な状態にあるのは、たとえば {@code onPause()} が返されてから {@code onResume()} が呼び出されるまでの間ということです。その後は、もう一度 {@code onPause()} が返されるまで、強制終了できる状態には戻りません。 +</p> + +<p> +後述の<a href="#proclife">プロセスとライフサイクル</a>のセクションで詳しく説明しますが、ここでの定義で技術的には「強制終了可能」でないアクティビティでも、システムによって強制終了させられる可能性はありますが、他に利用できるリソースがないなど、極端に急を要する場合に限られます。 +</p> + + +<h4 id="actstate">アクティビティの状態の保存</h4> + +<p> +メモリ不足を補うためにユーザーではなくシステムがアクティビティを終了させた場合には，ユーザがそのアクティビティに戻ったときに、以前の状態のままであることを期待するでしょう。 +</p> + +<p> +アクティビティが強制終了させられる前の状態を保存しておきたい場合は、アクティビティに <code>{@link android.app.Activity#onSaveInstanceState +onSaveInstanceState()}</code> メソッドを実装します。このメソッドは、アクティビティが破棄されやすい状態になる前（つまり {@code onPause()} が呼び出される前）に呼び出されます。その際、アクティビティの動的な状態を名前/値ペアとして記録できる {@link android.os.Bundle} オブジェクトが渡されます。アクティビティがもう一度開始されると、Bundle は {@code onCreate()} だけでなく、{@code onStart()} の後に呼び出される <code>{@link +android.app.Activity#onRestoreInstanceState onRestoreInstanceState()}</code> メソッドにも渡され、保存されている状態をそのどちらかまたは両方で復元できます。 +</p> + +<p> +{@code onSaveInstanceState()} および {@code onRestoreInstanceState()} メソッドは、これまでに説明した {@code onPause()} などとは異なり、ライフサイクル メソッドではありません。これらのメソッドは、常に呼び出されるわけではありません。たとえば、{@code onSaveInstanceState()} は、システムによってアクティビティが破棄しやすい状態にされる前には呼び出されますが、ユーザーのアクション（たとえば [[]戻る] キー）によってインスタンスが実際に破棄されるときには呼び出されません。そのような場合は、ユーザーがそのアクティビティに戻ることを想定する必要はないため、状態を保存する理由がないのです。 +</p> + +<p> +{@code onSaveInstanceState()} は常に呼び出されるとは限らないため、アクティビティの一時的な状態を記録する目的のみに使用し、永続データの格納には使用しないようにしてください。この目的には {@code onPause()} を使用します。 +</p> + + +<h4 id="coordact">アクティビティの協調</h4> + +<p> +あるアクティビティが別のアクティビティを開始すると、両方のアクティビティのライフサイクル状態が遷移します。一方が一時停止または停止し、もう一方が開始されます。場合によっては、これらの協調させる必要があります。 +</p> + +<p> +ライフサイクルのコールバックの順序は明確に定義されており、特に 2 つのアクティビティが同じプロセス内に存在する場合は次のようになります: +</p> + +<ol> +<li>現在のアクティビティの {@code onPause()} メソッドが呼び出されます。</li> + +<li>続いて、開始されるアクティビティの {@code onCreate()}、{@code onStart()}、および {@code onResume()} メソッドが順番に呼び出されます。</li> + +<li>その後、開始されたアクティビティが画面上で見えなくなると、その {@code onStop()} メソッドが呼び出されます。</li> +</ol> + + +<h3 id="servlife">サービスのライフサイクル</h3> + +<p> +サービスは、以下の 2 つの方法で使用できます: +</p> + +<ul> +<li>いったん開始したら、停止させられる（または自ら停止する）まで実行し続けることができます。このモードでは、<code>{@link android.content.Context#startService Context.startService()}</code> が呼び出されて開始し、<code>{@link android.content.Context#stopService Context.stopService()}</code> 呼び出されて停止します。サービス自体が <code>{@link android.app.Service#stopSelf() Service.stopSelf()}</code> または <code>{@link android.app.Service#stopSelfResult Service.stopSelfResult()}</code> を呼び出して停止することもできます。サービスの開始時に {@code startService()} が何度呼び出されたとしても、{@code stopService()} を一度呼び出せばサービスは停止します。</li> + +<li><p>サービスで定義されているインターフェースをエクスポートし、これを介してプログラム的に操作できます。クライアントから Service オブジェクトへの接続を確立し、その接続を使用してサービスにアクセスします。接続は、<code>{@link android.content.Context#bindService Context.bindService()}</code> を呼び出して確立し、<code>{@link android.content.Context#unbindService Context.unbindService()}</code> でサービスを開始します。複数のクライアントが同じサービスにバインドすることも可能です。サービスがまだ開始されていなかった場合は，必要に応じて {@code bindService()} で開始できます。 +</p></li> +</ul> + +<p> +これら 2 つのモードは、完全に分離されているわけではありません。{@code startService()} で開始されたサービスにバインドすることも可能です。たとえば、再生する曲を指定した Intent オブジェクトで {@code startService()} を呼び出して音楽再生サービスを開始したとします。その後、たとえばユーザーがプレーヤーを操作したい場合や再生中の曲に関する情報を入手したい場合には、アクティビティから {@code bindService()} を呼び出してサービスとの接続を確立できます。このような場合、最後のバインドが閉じられるまでは、{@code stopService()} を呼び出してもサービスは停止しません。 +</p> + +<p> +アクティビティと同様、サービスにもライフサイクル メソッドがあり、これらを実装することでサービスの状態の変化を監視できます。ただし、protected ではなく public で、以下の 3 つしかありません: +</p> + +<p style="margin-left: 2em">{@code void onCreate()} <br/>{@code void onStart(Intent <i>intent</i>)} <br/>{@code void onDestroy()}</p> + +<p> +これらのメソッドを実装することで、ネストされた 2 つのループからなるサービスのライフサイクルを監視できます: +</p> + +<ul> +<li>サービスの<b>ライフタイム全体</b>は、<code>{@link android.app.Service#onCreate onCreate()}</code> が呼び出されたときに始まり、<code>{@link android.app.Service#onDestroy}</code> 終了したときに終わります。アクティビティと同じく、サービスも {@code onCreate()} で初期設定を行い、{@code onDestroy()} で残っていたリソースをすべて解放します。たとえば、音楽再生サービスであれば、{@code onCreate()} で音楽を再生するスレッドを作成し、{@code onDestroy()} でそのスレッドを停止できます。</li> + +<li><p>サービスの<b>アクティブ ライフタイム</b>は、<code>{@link android.app.Service#onStart onStart()}</code> を呼び出したときに始まります。このメソッドには、{@code startService()} に渡された Intent オブジェクトが渡されます。音楽再生サービスは、この Intent オブジェクトをみて曲を見つけ、その再生を開始します。</p> + +<p> +サービスの停止に相当するコールバック、つまり {@code onStop()} メソッドはありません。 +</p></li> +</ul> + +<p> +{@code onCreate()} および {@code onDestroy()} メソッドは、サービスを <code>{@link android.content.Context#startService Context.startService()}</code> または <code>{@link android.content.Context#bindService Context.bindService()}</code> のどちらで開始したかに関係なく、すべてのサービスで呼び出されます。一方、{@code onStart()} は、サービスを {@code startService()} で開始した場合のみ呼び出されます。 +</p> + +<p> +サービスが他からのバインドを許可している場合は、以下のコールバック メソッドを追加で実装できます: +</p> + +<p style="margin-left: 2em">{@code IBinder onBind(Intent <i>intent</i>)} <br/>{@code boolean onUnbind(Intent <i>intent</i>)} <br/>{@code void onRebind(Intent <i>intent</i>)}</p> + +<p> +<code>{@link android.app.Service#onBind onBind()}</code> コールバックには {@code bindService()} に渡された Intent オブジェクトが渡され、<code>{@link android.app.Service#onUnbind onUnbind()}</code> には {@code unbindService()} 渡された Intent オブジェクトが渡されます。サービスがバインドを許可している場合は、クライアントがサービスと対話する通信チャネルを {@code onBind()} で返します。{@code onUnbind()} メソッドは、サービスに新しいクライアントが接続した場合に <code>{@link android.app.Service#onRebind onRebind()}</code> の呼び出しを要求できます。 +</p> + +<p> +次の図に、サービスのコールバック メソッドを示します。なお、{@code startService()} で作成されたサービスと、{@code bindService()} で作成されたサービスを分けて記述していますが、作成された方法に関係なく，すべてのサービスはクライアントからのバインドを許可できます。したがって、どのサービスも {@code onBind()} および{@code onUnbind()} メソッドの呼び出しを受け取る可能性はあります。 +</p> + +<p style="margin-left: 2em"><img src="{@docRoot}images/service_lifecycle.png" +alt="サービス コールバックの状態遷移図" /></p> + + +<h3 id="broadlife">ブロードキャスト レシーバのライフサイクル</h3> + +<p> +ブロードキャスト レシーバのコールバック メソッドは次の 1 つのみです: +</p> + +<p style="margin-left: 2em">{@code void onReceive(Context <i>curContext</i>, Intent <i>broadcastMsg</i>)}</p> + +<p> +レシーバにブロードキャスト メッセージが届くと、<code>{@link android.content.BroadcastReceiver#onReceive onReceive()}</code> メソッドが呼び出され、メッセージを保持する Intent オブジェクトが渡されます。ブロードキャスト レシーバは、このメソッドの実行中のみアクティブと見なされます。{@code onReceive()} 終了すると、ブロードキャスト レシーバはアクティブでなくなります。 +</p> + +<p> +ブロードキャスト レシーバがアクティブになっているプロセスは、強制終了しないよう保護されます。一方、アクティブでないコンポーネントのみからなるプロセスは、それが消費しているメモリが他のプロセスで必要になった場合は、いつでも強制終了される可能性があります。 +</p> + +<p> +この点は、ブロードキャスト メッセージへの応答に時間がかかるため、ユーザー インターフェースの他のコンポーネントを実行しているメイン スレッドとは別のスレッドで何らかの処理を行う必要がある場合に問題になります。{@code onReceive()} が新しいスレッドを生成して終了した場合、プロセス内に他にアクティブなアプリケーション コンポーネントがなければ、そのスレッドを含めたプロセス全体がアクティブでないと判断されて強制終了させられるおそれがあります。この問題を回避するには、{@code onReceive()} でサービスを開始し、そのサービスにジョブを実行させます。これにより、プロセス内にまだアクティブなコンポーネントがあると見なされます。 +</p> + +<p> +次のセクションでは、プロセスが強制終了される可能性が高くなる状況についてさらに詳しく説明します。 +</p> + + +<h3 id="proclife">プロセスとライフサイクル</h3> + +<p>Android は、プロセスをできるだけ長い間維持しようとします。しかし、最終的にメモリが不足したときには、古いプロセスを削除しなければならなくなります。Android では、どのプロセスを維持し、どのプロセスを強制終了させるかを判断するため、プロセス内で実行されているコンポーネントと各コンポーネントの状態に基づいて、各プロセスを「重要度の階層」の位置づけます。まず最も重要度の低いプロセスが削除され、次は 2 番目に重要度の低いプロセス、その次に 3 番目、というように判断されます。階層は 5 つのレベルで構成されます。以下では、重要度の高いものから順に説明します: +</p> + +<ol> + +<li><b>フォアグラウンド プロセス</b>は、ユーザーがその時点で行っている作業に必要なプロセスです。以下のいずれかの条件を満たしているプロセスは、フォアグラウンド プロセスと見なされます: + +<ul> +<li>ユーザーと対話中のアクティビティを実行している（Activity オブジェクトの <code>{@link android.app.Activity#onResume +onResume()}</code> メソッドが呼び出されている）。</li> + +<li><p>ユーザーと対話中のアクティビティにバインドされているサービスを実行している。</p></li> + +<li><p>いずれかのライフサイクル コールバック（<code>{@link android.app.Service#onCreate +onCreate()}</code>、<code>{@link android.app.Service#onStart onStart()}</code>、または <code>{@link android.app.Service#onDestroy onDestroy()}</code>）を実行している {@link android.app.Service} オブジェクトを保持している。</p></li> + +<li><p><code>{@link android.content.BroadcastReceiver#onReceive +onReceive()}</code> メソッドを実行している {@link android.content.BroadcastReceiver} オブジェクトを保持している。</p></li> +</ul> + +<p> +同時に存在するフォアグラウンド プロセスは少数に限られています。フォアグラウンド プロセスは、メモリが極端に不足し、すべてのフォアグラウンド プロセスの実行を継続できない場合の最終手段として強制終了させられます。通常、その時点でデバイスはメモリ ページングの状態に達しており、ユーザー インターフェースを応答可能な状態に維持するためには、フォアグラウンド プロセスの一部を強制終了させなければならない状況に陥っています。 +</p></li> + +<li><p><b>可視プロセス</b>は、フォアグラウンド コンポーネントではないものの、ユーザーが見ている画面に影響を及ぼすことのできるプロセスです。以下のいずれかの条件を満たしているプロセスは、可視プロセスと見なされます:</p> + +<ul> +<li>フォアグラウンドではないがユーザーから見ることができるアクティビティを実行している（その <code>{@link android.app.Activity#onPause onPause()}</code> メソッドが呼び出されている）。これは、たとえばフォアグラウンド アクティビティがダイアログで、その背後に直前のアクティビティが見えるような状況です。</li> + +<li><p>ユーザーから見ることのできるアクティビティにバインドされているサービスを実行している。</p></li> +</ul> + +<p> +可視プロセスは、非常に重要なプロセスと見なされ、すべてのフォアグラウンド プロセスの実行を維持するために必要でない限り、強制終了させられることはありません。 +</p></li> + +<li><p><b>サービス プロセス</b>は、<code>{@link android.content.Context#startService startService()}</code> メソッドで開始されたサービスを実行しているプロセスのうち、より重要度の高い 2 つのレベルのどちらにも該当しないプロセスです。サービス プロセスは、ユーザーに見えるものとの直接的な関係はありませんが、たとえばバックグラウンドでの MP3 の再生、ネットワークからのデータのダウンロードなど、ユーザーが気にかけている処理であることが一般的です。したがって、すべてのフォアグラウンド プロセスと可視プロセスに加え、これらのサービス プロセスの実行を維持するだけのメモリが確保できる限り、強制終了させられることはありません。 +</p></li> + +<li><p><b>バックグラウンド プロセス</b>は、その時点でユーザーから見えないアクティビティを保持している（Activity オブジェクトの <code>{@link android.app.Activity#onStop onStop()}</code> メソッドが呼び出されている）プロセスです。これらのプロセスは、ユーザー エクスペリエンスに直接的には影響しておらず、フォアグラウンド、可視、サービス プロセスからメモリが要求された場合はいつでも強制終了する可能性があります。通常は数多くのバックグラウンド プロセスが実行されているため、それらを LRU（least recently used）リストに登録し、ユーザーが一番最近見たアクティビティのプロセスが最後に強制終了するような仕組みになっています。アクティビティにライフサイクル メソッドが正しく実装されており、現在の状態が正しく保存されていれば、プロセスを強制終了してもユーザー エクスペリエンスに悪影響が及ぶことはありません。 +</p></li> + +<li><p><b>空のプロセス</b>は、アクティブなアプリケーション コンポーネントを保持していないプロセスです。このようなプロセスを維持しておく唯一の理由は、これをキャッシュとして使用し、次回コンポーネントを実行するときの起動時間を短くするためです。多くの場合、システムはこれらのプロセスを強制終了させて、プロセス キャッシュとその基礎となるカーネル キャッシュの間でシステム リソース全体のバランスを取ります。</p></li> + +</ol> + +<p> +各プロセスは、その時点でアクティブなコンポーネントの重要度に基づいて、そのプロセスが取りうる最も高いレベルにランク付けされます。たとえば、あるプロセスがサービスと可視アクティビティをホストしている場合、そのプロセスはサービス プロセスではなく可視プロセスとしてランク付けされます。 +</p> + +<p> +また、あるプロセスに他のプロセスが依存しているために、そのプロセスのランクが引き上げられる可能性もあります。他のプロセスから依存されているプロセスが、依存しているプロセスよりも低いレベルにランク付けされることはありません。たとえば、プロセス A 内のコンテンツ プロバイダにプロセス B 内のクライアントが依存している場合や、プロセス A 内のサービスがプロセス B 内のコンポーネントにバインドされている場合、プロセス A は常にプロセス B よりは重要度が高いと見なされます。 +</p> + +<p> +サービスを実行しているプロセスは、バックグラウンド アクティビティを実行しているプロセスよりも高くランク付けされます。したがって、時間のかかる処理を実行する場合、特にその処理がアクティビティよりも長く続くような場合は、単にスレッドを生成するのではなく、その処理用のサービスを開始することをおすすめします。たとえば、バックグラウンドで音楽を再生する場合や、カメラで撮影した写真を Web サイトにアップロードする場合などはこれに当たります。サービスを使用することで、アクティビティがどのような状況にあっても、処理の重要度として「サービス プロセス」レベル以上を維持できます。<a href="#broadlife">ブロードキャスト レシーバのライフサイクル</a>のセクションでも説明しましたが、ブロードキャスト レシーバにおいてもこれと同じ理由で、処理に時間がかかる場合はスレッドではなくサービスを使用することをおすすめします。 +</p> diff --git a/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd new file mode 100644 index 0000000..c4aafe4 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/battery-monitoring.jd @@ -0,0 +1,120 @@ +page.title=電池残量と充電状態の監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true +next.title=ホルダーの装着状態とタイプの特定と監視 +next.link=docking-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#DetermineChargeState">現在の充電状態を特定する</a></li> + <li><a href="#MonitorChargeState">充電状態の変化を監視する</a></li> + <li><a href="#CurrentLevel">現在の電池残量を特定する</a></li> + <li><a href="#MonitorLevel">電池残量の大きな変化を監視する</a></li> +</ol> + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>バックグラウンド更新が電池消費量に及ぼす影響を抑えるために更新の頻度を変更するには、初めに現在の電池残量と充電状態を調べることをおすすめします。</p> + +<p>アプリの更新が電池消費量に及ぼす影響の度合いは、端末の電池残量と充電状態によって異なります。AC 電源から端末を充電しているときは、更新の実行による影響はごくわずかなので、ほとんどの場合は、端末が AC 電源に接続されている限り、更新頻度を最大にして差し支えありません。逆に、端末が電池で駆動しているときは、更新頻度を下げると電池消費量を抑えることができます。</p> + +<p>同様に、電池残量を調べると、残量がごくわずかであるときに更新頻度を下げたり、場合によっては停止させたりすることができます。</p> + + +<h2 id="DetermineChargeState">現在の充電状態を特定する</h2> + +<p>初めに、現在の充電状態を特定します。{@link android.os.BatteryManager} によって電池と充電状態に関するすべての詳細情報が sticky {@link android.content.Intent} としてブロードキャストされますが、この中に充電状態が格納されています。</p> + +<p>これは sticky インテントであるため、{@link android.content.BroadcastReceiver} を登録する必要はありません。{@code registerReceiver} を呼び出し、{@code null} をレシーバとして渡すだけで（次のコード例を参照）、現在の電池状態のインテントが返されます。ここで実際の {@link android.content.BroadcastReceiver} オブジェクトを渡すこともできますが、このレッスンでは後で更新についての処理を行うので、これは必要ありません。</p> + +<pre>IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED); +Intent batteryStatus = context.registerReceiver(null, ifilter);</pre> + +<p>現在の充電状態に加えて、充電中の場合は USB 経由か AC 充電器経由かを調べることもできます。<p> + +<pre>// Are we charging / charged? +int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1); +boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || + status == BatteryManager.BATTERY_STATUS_FULL; + +// How are we charging? +int chargePlug = battery.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1); +boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB; +boolean acCharge = chargePlug == BATTERY_PLUGGED_AC;</pre> + +<p>一般的には、端末が AC 充電器に接続されているときはバックグラウンド更新の頻度を最大にし、USB 経由で充電中のときは頻度を下げ、電池で駆動中のときはさらに頻度を下げます。</p> + + +<h2 id="MonitorChargeState">充電状態の変化を監視する</h2> + +<p>充電状態は、端末が充電器に接続されたときにすぐに変化するので、充電状態の変化を監視し、その変化に応じて更新の頻度を変更することが重要です。</p> + +<p>{@link android.os.BatteryManager} は、端末が電源に接続されたときや接続が解除されたときに、アクションをブロードキャストします。このようなイベントは、アプリが実行中でないときでも受信することが重要です。特にそのイベントが、アプリのバックグラウンド更新を開始するためにアプリを起動させる頻度に影響するものである場合です。したがって、{@link android.content.BroadcastReceiver} をアプリのマニフェスト内で登録し、両方のイベントを受信するために {@link android.content.Intent#ACTION_POWER_CONNECTED} と {@link android.content.Intent#ACTION_POWER_DISCONNECTED} をインテント フィルタ内で定義します。</p> + +<pre><receiver android:name=".PowerConnectionReceiver"> + <intent-filter> + <action android:name="android.intent.action.ACTION_POWER_CONNECTED"/> + <action android:name="android.intent.action.ACTION_POWER_DISCONNECTED"/> + </intent-filter> +</receiver></pre> + +<p>関連付けられている {@link android.content.BroadcastReceiver} 実装の中で、前のステップで説明したように、現在の充電状態と充電方法を抽出します。</p> + +<pre>public class PowerConnectionReceiver extends BroadcastReceiver { + @Override + public void onReceive(Context context, Intent intent) { + int status = intent.getIntExtra(BatteryManager.EXTRA_STATUS, -1); + boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING || + status == BatteryManager.BATTERY_STATUS_FULL; + + int chargePlug = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1); + boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB; + boolean acCharge = chargePlug == BATTERY_PLUGGED_AC; + } +}</pre> + + +<h2 id="CurrentLevel">現在の電池残量を特定する</h2> + +<p>状況によっては、現在の電池残量がわかると便利なことがあります。たとえば、電池残量が所定のレベルを下回った場合にアプリのバックグラウンド更新の頻度を下げることができます。</p> + +<p>現在の電池残量を調べるには、次に示すように、電池状態のインテントから現在の電池残量と最大量を抽出します。</p> + +<pre>int level = battery.getIntExtra(BatteryManager.EXTRA_LEVEL, -1); +int scale = battery.getIntExtra(BatteryManager.EXTRA_SCALE, -1); + +float batteryPct = level / (float)scale;</pre> + + +<h2 id="MonitorLevel">電池残量の大きな変化を監視する</h2> + +<p>電池状態を継続的に監視することは簡単ではありませんが、その必要もありません。</p> + +<p>一般的に、電池残量を継続的に監視するほうが、電池への影響はアプリの通常の動作によるものよりも大きくなるため、電池残量の大きな変化のみを監視することをおすすめします。特に、端末が電池残量低下状態に入ったときや、その状態が解消されたときです。</p> + +<p>次に示すマニフェストの断片は、ブロードキャスト レシーバの中にあるインテント フィルタ要素からの抜粋です。このレシーバは、端末が電池残量低下状態に入ったときや、その状態が解消されたときに呼び出されます。そのために、{@link android.content.Intent#ACTION_BATTERY_LOW} と {@link android.content.Intent#ACTION_BATTERY_OKAY} を受信します。</p> + +<pre><receiver android:name=".BatteryLevelReceiver"> +<intent-filter> + <action android:name="android.intent.action.ACTION_BATTERY_LOW"/> + <action android:name="android.intent.action.ACTION_BATTERY_OKAY"/> + </intent-filter> +</receiver></pre> + +<p>一般的に、電池残量がごくわずかになったときはアプリのバックグラウンド更新をすべて停止することをおすすめします。データがいくら新しくても、端末自体の電源が切れてしまったのではデータを活用できません。</p> + +<p>多くの場合、端末の充電という動作が開始するのは、端末がホルダーにセットされるのと同時です。次のレッスンでは、現在のホルダーの状態を特定し、端末のホルダー装着状態の変化を監視する方法を紹介します。</p> + diff --git a/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd new file mode 100644 index 0000000..82b0c6b --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/connectivity-monitoring.jd @@ -0,0 +1,70 @@ +page.title=接続状態の特定と監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true + +previous.title=ホルダーの装着状態とタイプの特定と監視 +previous.link=docking-monitoring.html +next.title=オンデマンドでのブロードキャスト レシーバ操作 +next.link=manifest-receivers.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#DetermineConnection">インターネット接続の有無を特定する</a></li> + <li><a href="#DetermineType">インターネット接続のタイプを特定する</a></li> + <li><a href="#MonitorChanges">接続状態の変化を監視する</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>反復アラームとバックグラウンド サービスの用途のうち代表的なものとしては、インターネット リソースからアプリのデータを定期的に更新するためのスケジュール設定や、データのキャッシュへの格納、長時間に及ぶダウンロードの実行などがあります。しかし、インターネットに接続されていないときや、速度が低すぎるためにダウンロードを完了できない場合にまで、更新をスケジューリングするために端末をスリープ状態から復帰させる必要があるでしょうか。</p> + +<p>{@link android.net.ConnectivityManager} を使用すると、端末が実際にインターネットに接続されているかどうかと、接続されている場合の接続タイプを調べることができます。</p> + + +<h2 id="DetermineConnection">インターネット接続の有無を特定する</h2> + +<p>端末がインターネットに接続されていない場合は、インターネット リソースに基づく更新をスケジューリングする必要性はありません。次のスニペットは、{@link android.net.ConnectivityManager} を使用してアクティブなネットワークを問い合わせて、インターネットに接続しているかどうかを特定する方法を示すものです。</p> + +<pre>ConnectivityManager cm = + (ConnectivityManager)context.getSystemService(Context.CONNECTIVITY_SERVICE); + +NetworkInfo activeNetwork = cm.getActiveNetworkInfo(); +boolean isConnected = activeNetwork.isConnectedOrConnecting();</pre> + + +<h2 id="DetermineType">インターネット接続のタイプを特定する</h2> + +<p>現在使用可能なインターネット接続のタイプも調べることができます。</p> + +<p>端末の接続のタイプとしては、モバイル データ、WiMAX、Wi-Fi、イーサネットがあります。次に示すように、アクティブなネットワークのタイプを問い合わせると、使用可能な帯域幅に合わせて更新頻度を変更することができます。</p> + +<pre>boolean isWiFi = activeNetwork.getType() == ConnectivityManager.TYPE_WIFI;</pre> + +<p>モバイル データ接続のコストは Wi-Fi 接続を大きく上回る傾向があるため、端末がモバイル接続しているときはアプリの更新頻度を下げるのが一般的です。同様に、大量のデータをダウンロードするときは、Wi-Fi 接続されるまで停止するとよいでしょう。</p> + +<p>更新を停止した場合は、接続状態の変化を受信することが重要です。インターネット接続が確立されたら更新を再開できるようにするためです。</p> + + +<h2 id="MonitorChanges">接続状態の変化を監視する</h2> + +<p>接続状態の詳細が変化すると、{@link android.net.ConnectivityManager} によって {@link android.net.ConnectivityManager#CONNECTIVITY_ACTION}（{@code "android.net.conn.CONNECTIVITY_CHANGE"}）アクションがブロードキャストされます。アプリのマニフェスト内でブロードキャスト レシーバを登録し、このような変化を検出することで、それに応じてアプリのバックグラウンド更新を再開（または停止）することができます。</p> + +<pre><action android:name="android.net.conn.CONNECTIVITY_CHANGE"/></pre> + +<p>端末の接続状態の変化は、きわめて頻繁になることもあります。このブロードキャストは、モバイル データ接続と Wi-Fi 接続とが切り替わるたびに発行されるからです。したがって、このブロードキャストの監視は、更新やダウンロードを停止した後に再開すべきかどうかを判断するために限って行うことをおすすめします。一般的には、更新を開始する前にインターネット接続の有無を調べれば十分です。インターネットに接続していない場合は、再び接続されるまでの間、更新を停止します。</p> + +<p>このようにするには、マニフェスト内で宣言したブロードキャスト レシーバのオンとオフを切り替える必要があります。これについて、次のレッスンで説明します。</p> diff --git a/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd b/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd new file mode 100644 index 0000000..9c0e054 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/docking-monitoring.jd @@ -0,0 +1,74 @@ +page.title=ホルダーの装着状態とタイプの特定と監視 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true +previous.title= 電池残量と充電状態の監視 +previous.link=battery-monitoring.html +next.title= 接続状態の特定と監視 +next.link=connectivity-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#CurrentDockState">オーディオ フォーカスをリクエストする</a></li> + <li><a href="#DockType">現在のホルダーのタイプを特定する</a></li> + <li><a href="#MonitorDockState">ホルダーの装着状態またはタイプの変化を監視する</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>Android 搭載端末を装着できるホルダーの種類には、さまざまなものがあります。たとえば、車載用や家庭用のホルダーがあり、デジタルかアナログかという区別もあります。ホルダー装着状態は一般的に、充電状態と密接にリンクしています。多くのホルダーは、装着されている端末に電力を供給しているからです。</p> + +<p>端末のホルダー装着状態が更新の頻度にどのように影響するかは、アプリによって異なります。たとえば、スポーツ センター アプリなら、卓上ホルダー装着時には更新頻度を上げ、カー ホルダー装着時には更新を完全に停止するとよいでしょう。逆に、カー ホルダー装着時に更新頻度を最大にするケースとしては、バックグラウンド サービスによって道路交通状況を更新する場合が考えられます。</p> + +<p>ホルダー装着状態も sticky {@link android.content.Intent} としてブロードキャストされるので、端末がホルダーに装着されているかどうかと、装着されている場合のホルダーのタイプを問い合わせることができます。</p> + + +<h2 id="CurrentDockState">現在のホルダー装着状態を特定する</h2> + +<p>ホルダー装着状態の詳細は、{@link android.content.Intent#ACTION_DOCK_EVENT} アクションの sticky ブロードキャストにエクストラとして含まれています。これは sticky であるため、{@link android.content.BroadcastReceiver} を登録する必要はありません。次のコード例に示すように、{@link android.content.Context#registerReceiver registerReceiver()} を呼び出し、{@code null} をブロードキャスト レシーバとして渡します。</p> + +<pre>IntentFilter ifilter = new IntentFilter(Intent.ACTION_DOCK_EVENT); +Intent dockStatus = context.registerReceiver(null, ifilter);</pre> + +<p>現在のホルダー装着状態は、次のように {@code EXTRA_DOCK_STATE} エクストラから抽出します。<p> + +<pre>int dockState = battery.getIntExtra(EXTRA_DOCK_STATE, -1); +boolean isDocked = dockState != Intent.EXTRA_DOCK_STATE_UNDOCKED;</pre> + + +<h2 id="DockType">現在のホルダーのタイプを特定する</h2> + +<p>端末がホルダーに装着されている場合のホルダーのタイプは、次の 4 つのいずれかです。 +<ul><li>カー</li> +<li>卓上</li> +<li>ローエンド（アナログ）卓上</li> +<li>ハイエンド（デジタル）卓上</li></ul></p> + +<p>最後の 2 つは、Android API レベル 11 で追加されたものです。したがって、ホルダーのタイプだけがわかればよく、デジタルとアナログの区別は問わないという場合は、次のように 3 つすべてについて調べるとよいでしょう。</p> + +<pre>boolean isCar = dockState == EXTRA_DOCK_STATE_CAR; +boolean isDesk = dockState == EXTRA_DOCK_STATE_DESK || + dockState == EXTRA_DOCK_STATE_LE_DESK || + dockState == EXTRA_DOCK_STATE_HE_DESK;</pre> + + +<h2 id="MonitorDockState">ホルダーの装着状態またはタイプの変化を監視する</h2> + +<p>端末がホルダーに装着されたり、装着が解除されたりするたびに、{@link android.content.Intent#ACTION_DOCK_EVENT} アクションがブロードキャストされます。端末のホルダー装着状態の変化を監視するには、次のコード例に示すように、アプリのマニフェスト内でブロードキャスト レシーバを登録します。</p> + +<pre><action android:name="android.intent.action.ACTION_DOCK_EVENT"/></pre> + +<p>レシーバ実装の中でホルダーのタイプと状態を抽出する方法は、前のステップで使用したものと同じです。</p> diff --git a/docs/html-intl/ja/training/monitoring-device-state/index.jd b/docs/html-intl/ja/training/monitoring-device-state/index.jd new file mode 100644 index 0000000..07897b1 --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/index.jd @@ -0,0 +1,49 @@ +page.title=電池消費量の最適化 + +trainingnavtop=true +startpage=true +next.title=電池残量と充電状態の監視 +next.link=battery-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>依存関係と前提条件</h2> +<ul> + <li>Android 2.0（API レベル 5）以上</li> + <li>「<a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a>」を読み終えていること</li> +</ul> + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/services.html">サービス</a> +</ul> + +</div> +</div> + +<p>アプリを開発するときは、ホスト端末の電池消費量への影響を抑えるよう心がける必要があります。このクラスを修了すると、開発するアプリの中でホスト端末の状態を監視し、それに基づいて機能や動作を変更することができるようになります。</p> + +<p>接続が失われたときはバックグラウンド サービスの更新を停止する、電池残量が低下したときは更新の頻度を下げるといった対策を講じることにより、ユーザー エクスペリエンスを損なうことなく、アプリが電池消費量に及ぼす影響を最小限に抑えることができます。</p> + +<h2>レッスン</h2> + +<!-- Create a list of the lessons in this class along with a short description of each lesson. +These should be short and to the point. It should be clear from reading the summary whether someone +will want to jump to a lesson or not.--> + +<dl> + <dt><b><a href="battery-monitoring.html">電池残量と充電状態の監視</a></b></dt> + <dd>アプリの更新頻度を変更するために現在の電池残量や充電状態の変化を特定および監視する方法を学習します。</dd> + + <dt><b><a href="docking-monitoring.html">ホルダーの装着状態とタイプの特定と監視</a></b></dt> + <dd>最適な更新頻度は、ホスト端末がどのように使用されているかによって異なります。ホルダーの装着状態とタイプに応じてアプリの動作を変更するために、これらを特定および監視する方法を学習します。</dd> + + <dt><b><a href="connectivity-monitoring.html">接続状態の特定と監視</a></b></dt> + <dd>インターネットに接続していないときは、オンライン ソースからアプリを更新することはできません。接続状態を調べ、それに応じてバックグラウンド更新の頻度を変更する方法を学習します。また、大量の帯域幅を消費する処理を開始する前に接続が Wi-Fi かモバイル データかを調べる方法も学習します。</dd> + + <dt><b><a href="manifest-receivers.html">オンデマンドでのブロードキャスト レシーバ操作</a></b></dt> + <dd>マニフェスト内で宣言したブロードキャスト レシーバのオンとオフを実行時に切り替えます。端末の状態に応じて、不要なレシーバを無効にすることができます。効率を上げるために、状態変化レシーバのオンとオフを切り替える方法や、端末が特定の状態になるまでアクションを延期する方法を学習します。</dd> +</dl>
\ No newline at end of file diff --git a/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd b/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd new file mode 100644 index 0000000..7635d9f --- /dev/null +++ b/docs/html-intl/ja/training/monitoring-device-state/manifest-receivers.jd @@ -0,0 +1,50 @@ +page.title=オンデマンドでのブロードキャスト レシーバ操作 +parent.title=電池消費量の最適化 +parent.link=index.html + +trainingnavtop=true + +previous.title=接続状態の特定と監視 +previous.link=connectivity-monitoring.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンの内容</h2> +<ol> + <li><a href="#ToggleReceivers">効率を上げるために状態変化レシーバのオンとオフを切り替える</a></li> +</ol> + + +<h2>関連項目</h2> +<ul> + <li><a href="{@docRoot}guide/components/intents-filters.html">インテントとインテント フィルタ</a> +</ul> + +</div> +</div> + +<p>端末の状態変化を監視する最も単純な方法は、監視対象とする状態ごとに {@link android.content.BroadcastReceiver} を作成し、それぞれをアプリのマニフェスト内で登録するというものです。これらの各レシーバ内で、端末の現在の状態に基づいて反復アラームのスケジュールを再設定します。</p> + +<p>この方法のデメリットは、これらのレシーバのいずれかがトリガされるたびに端末がスリープから復帰することですが、このことは必要以上に頻繁に発生する可能性があります。</p> + +<p>これよりも良い方法は、実行時にブロードキャスト レシーバをオンまたはオフにするというものです。このようにすれば、マニフェスト内で宣言したレシーバを受動的アラームとして使用できます。つまり、このアラームは、必要なときにだけシステム イベントによって呼び出されます。</p> + + +<h2 id="ToggleReceivers">効率を上げるために状態変化レシーバのオンとオフを切り替える </h2> + +<p>{@link android.content.pm.PackageManager} を使用すると、マニフェスト内で定義されているコンポーネントの有効化状態を切り替えることができます。このコンポーネントにはブロードキャスト レシーバも該当するので、次に示すようにオンとオフを切り替えることができます。</p> + +<pre>ComponentName receiver = new ComponentName(context, myReceiver.class); + +PackageManager pm = context.getPackageManager(); + +pm.setComponentEnabledSetting(receiver, + PackageManager.COMPONENT_ENABLED_STATE_ENABLED, + PackageManager.DONT_KILL_APP)</pre> + +<p>この手法を使用すれば、接続が失われたことが判明した場合に、接続状態変化レシーバ以外のレシーバをすべて無効にすることができます。逆に、接続が確立された後は、接続状態変化の受信を停止します。オンラインかどうかを調べるのは、更新を実行する直前や、反復更新アラームのスケジュール再設定の直前だけで十分です。</p> + +<p>同じ手法を使用して、大量の帯域幅を必要とするダウンロードを延期することもできます。それには、接続状態の変化をリッスンするブロードキャスト レシーバを有効にしておき、端末が Wi-Fi に接続されたらダウンロードを開始します。</p> diff --git a/docs/html-intl/ja/training/multiscreen/adaptui.jd b/docs/html-intl/ja/training/multiscreen/adaptui.jd new file mode 100644 index 0000000..8b1e6ac --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/adaptui.jd @@ -0,0 +1,212 @@ +page.title=順応性のある UI フローの実装 +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +previous.title=さまざまな画面密度のサポート +previous.link=screendensities.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> + +<ol> + <li><a href="#TaskDetermineCurLayout">現在のレイアウトを判別する</a></li> + <li><a href="#TaskReactToLayout">現在のレイアウトに合わせて応答する</a></li> + <li><a href="#TaskReuseFrag">他のアクティビティのフラグメントを再利用する</a></li> + <li><a href="#TaskHandleConfigChanges">画面設定の変更を処理する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/tablets-and-handsets.html">タブレットと携帯端末のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + + +</div> +</div> + +<p>アプリが現在表示しているレイアウトによって、UI フローが異なる可能性があります。たとえば、アプリがデュアルペイン モードであれば、左ペインのアイテムをクリックすると、単に右ペインにコンテンツが表示されるだけですが、シングルペイン モードであれば、コンテンツは（別のアクティビティ内の）コンテンツ専用のペインに表示される必要があります。</p> + + +<h2 id="TaskDetermineCurLayout">現在のレイアウトを判別する</h2> + +<p>レイアウトによって実装が多少異なるので、まず、ユーザーが現在どのようなレイアウトを表示しているかを判別する必要があります。たとえば、ユーザーが表示しているレイアウトが「シングルペイン」モードなのか、「デュアルペイン」モードなのかを確認する必要があります。それは、以下のようなコードで、ある特定のビューが存在し、かつ可視になっているかを照会することで可能です:</p> + +<pre class="prettyprint"> +public class NewsReaderActivity extends FragmentActivity { + boolean mIsDualPane; + + @Override + public void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + setContentView(R.layout.main_layout); + + View articleView = findViewById(R.id.article); + mIsDualPane = articleView != null && + articleView.getVisibility() == View.VISIBLE; + } +} +</pre> + +<p>このコードにおいて「article」ペインが使用可能かどうかを照会している点に注目してください。特定のレイアウトの照会をハードコーディングするよりもはるかに柔軟性があります。</p> + +<p>その他にも、さまざまなコンポーネントでも対応できる方法として、コンポーネントを操作する前に使用可能かどうかを確認する方法もあります。たとえば、News Reader サンプル アプリでは、メニューを開くボタンがありますが、このボタンは Android 3.0 よりも古いバージョンで動作しているときにしか表示されません（この機能は、API レベル 11 以上の <PH>{@link android.app.ActionBar}</PH> で提供されるため）。そこで、以下のようなコードを追加して、このボタンのイベント リスナーを追加します:</p> + +<pre class="prettyprint"> +Button catButton = (Button) findViewById(R.id.categorybutton); +OnClickListener listener = /* create your listener here */; +if (catButton != null) { + catButton.setOnClickListener(listener); +} +</pre> + + +<h2 id="TaskReactToLayout">現在のレイアウトに合わせて応答する</h2> + +<p>現在のレイアウトによって、一部のアクションの結果が異なる可能性があります。たとえば、News Reader サンプルでは、見出しリストで見出しをクリックしたとき、デュアルペイン モードの UI の場合は右ペインに記事が表示されますが、シングルペインの UI の場合は別のアクティビティが起動します:</p> + +<pre> +@Override +public void onHeadlineSelected(int index) { + mArtIndex = index; + if (mIsDualPane) { + /* display article on the right pane */ + mArticleFragment.displayArticle(mCurrentCat.getArticle(index)); + } else { + /* start a separate activity */ + Intent intent = new Intent(this, ArticleActivity.class); + intent.putExtra("catIndex", mCatIndex); + intent.putExtra("artIndex", index); + startActivity(intent); + } +} +</pre> + +<p>同様に、アプリがデュアルペイン モードの場合は、ナビ用タブでアクション バーを設定し、一方、シングルペイン モードの場合は、スピナー ウィジェットでナビを設定することになります。したがって、コードでは以下のようにどちらのケースが適切かを調べることも必要です:</p> + +<pre> +final String CATEGORIES[] = { "トップ ニュース 政治", "政治", "経済", "Technology" }; + +public void onCreate(Bundle savedInstanceState) { + .... + if (mIsDualPane) { + /* use tabs for navigation */ + actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_TABS); + int i; + for (i = 0; i < CATEGORIES.length; i++) { + actionBar.addTab(actionBar.newTab().setText( + CATEGORIES[i]).setTabListener(handler)); + } + actionBar.setSelectedNavigationItem(selTab); + } + else { + /* use list navigation (spinner) */ + actionBar.setNavigationMode(android.app.ActionBar.NAVIGATION_MODE_LIST); + SpinnerAdapter adap = new ArrayAdapter<String>(this, + R.layout.headline_item, CATEGORIES); + actionBar.setListNavigationCallbacks(adap, handler); + } +} +</pre> + + +<h2 id="TaskReuseFrag">他のアクティビティのフラグメントを再利用する</h2> + +<p>複数の画面に対応するように設計する場合、あるパターンが繰り返されますが、そうしたパターンは、ある画面設定ではペインとして、別の画面設定では別のアクティビティとして実装されるインターフェースの一部に存在します。たとえば、News Reader サンプルでは、ラージ画面の場合はニュース記事のテキストが右ペインに表示されますが、それよりも小さい画面の場合は別のアクティビティになります。</p> + +<p>このような場合、通常、複数のアクティビティで同じ <PH>{@link android.app.Fragment}</PH> サブクラスを再利用することでコードの重複を回避できます。たとえば、<code>ArticleFragment</code> は以下のようにデュアルペイン レイアウトで使用されます:</p> + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} + +<p>また、より小さな画面向けのアクティビティ レイアウト内では（レイアウトを使用せずに）再利用されます（<code>ArticleActivity</code>）:</p> + +<pre> +ArticleFragment frag = new ArticleFragment(); +getSupportFragmentManager().beginTransaction().add(android.R.id.content, frag).commit(); +</pre> + +<p>当然、これは XML レイアウトでフラグメントを宣言するのと同じ効果がありますが、この場合は、XML レイアウトは必要ありません。このアクティビティのコンポーネントは記事フラグメントしかないからです。</p> + +<p>フラグメントを設計する際に注意すべき非常に重要なポイントの 1 つとして、特定のアクティビティに対して強い結合を作成しないことがあります。通常、これは、フラグメントが自分のホスト アクティビティとやり取りするのに必要なあらゆる手段を抽象化したインターフェースを定義し、さらに、そのインターフェースをホスト アクティビティに実装することで可能になります:</p> + +<p>たとえば、News Reader アプリの <code>HeadlinesFragment</code> は、まさにそのようになっています:</p> + +<pre> +public class HeadlinesFragment extends ListFragment { + ... + OnHeadlineSelectedListener mHeadlineSelectedListener = null; + + /* Must be implemented by host activity */ + public interface OnHeadlineSelectedListener { + public void onHeadlineSelected(int index); + } + ... + + public void setOnHeadlineSelectedListener(OnHeadlineSelectedListener listener) { + mHeadlineSelectedListener = listener; + } +} +</pre> + +<p>これにより、ユーザーが見出しを選択すると、フラグメントは以下のように（特定のハードコーディングされたアクティビティに通知するのではなく）ホスト アクティビティが指定したリスナーに通知します:</p> + +<pre> +public class HeadlinesFragment extends ListFragment { + ... + @Override + public void onItemClick(AdapterView<?> parent, + View view, int position, long id) { + if (null != mHeadlineSelectedListener) { + mHeadlineSelectedListener.onHeadlineSelected(position); + } + } + ... +} +</pre> + +<p>このテクニックについては、<a +href="{@docRoot}guide/practices/tablets-and-handsets.html">タブレットと携帯端末のサポート</a>で詳しく説明されています。</p> + + +<h2 id="TaskHandleConfigChanges">画面設定の変更を処理する</h2> + +<p>インターフェースの各パーツを実装するのに個別のアクティビティを使用している場合、インターフェースの一貫性を維持するために、（向きの変更などの）特定の設定変更に対応できるように注意する必要があります。</p> + +<p>たとえば、Android 3.0 以上が動作する一般的な 7 インチ タブレットでは、News Reader サンプルがニュース記事を表示する場合、縦表示では個別のアクティビティを使用しますが、横表示では 2 ペイン レイアウトを使用します。</p> + +<p>つまり、縦表示のときに記事閲覧用アクティビティが画面上にある場合、画面の向きが横方向に変わったことを検出したら、コンテンツを 2 ペイン レイアウトで表示するために、そのアクティビティを終了してメインのアクティビティに戻り、適切に応答しなければなりません:</p> + +<pre> +public class ArticleActivity extends FragmentActivity { + int mCatIndex, mArtIndex; + + @Override + protected void onCreate(Bundle savedInstanceState) { + super.onCreate(savedInstanceState); + mCatIndex = getIntent().getExtras().getInt("catIndex", 0); + mArtIndex = getIntent().getExtras().getInt("artIndex", 0); + + // If should be in two-pane mode, finish to return to main activity + if (getResources().getBoolean(R.bool.has_two_panes)) { + finish(); + return; + } + ... +} +</pre> + + diff --git a/docs/html-intl/ja/training/multiscreen/index.jd b/docs/html-intl/ja/training/multiscreen/index.jd new file mode 100644 index 0000000..ff84f8a --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/index.jd @@ -0,0 +1,64 @@ +page.title=複数画面のデザイン + +trainingnavtop=true +startpage=true +next.title=さまざまな画面サイズのサポート +next.link=screensizes.html + +@jd:body + +<div id="tb-wrapper"> +<div id="tb"> + +<h2>必要な知識と前提条件</h2> + +<ul> + <li>Android 1.6 以上（サンプル アプリを使用するには 2.1 以上）</li> + <li><a +href="http://developer.android.com/guide/components/activities.html">アクティビティ</a>と<a href="http://developer.android.com/guide/components/fragments.html">フラグメント</a>の基礎知識</li> + <li>Android <a +href="http://developer.android.com/guide/topics/ui/index.html">ユーザー インターフェース</a>の開発経験</li> + <li><a +href="{@docRoot}tools/extras/support-library.html">サポート ライブラリ</a>の利用（一部の機能で必要）</li> +</ul> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + +</div> +</div> + +<p>Android は、小さな携帯電話から大きなテレビまで、画面サイズも種類もさまざまなデバイスに搭載できます。そのため、できる限り多くのユーザーが使用できるように、すべての画面サイズに対応できるようアプリを設計することが重要になります。</p> + +<p>しかし、さまざまな種類のデバイスに対応できるだけでは十分ではありません。画面サイズによって、ユーザーが操作できることが決まってくるため、本当にユーザーを満足させてよい印象を持ってもらうためには、アプリが単に複数の画面をサポートするだけでは不十分です: 画面設定ごとにユーザー エクスペリエンスを最適化する必要があります。<em></em><em></em></p> + +<p>このクラスは、いくつかの画面設定に合わせて最適化されたユーザー インターフェースを実装する方法を提供します。</p> + +<p>各レッスンで紹介されているコードは、複数の画面に合わせて最適化する際、ベスト プラクティスとなるサンプル アプリから抜粋したものです。このサンプルを（右側から）ダウンロードして、再利用可能なコードのソースとしてご自分のアプリに使用することができます。</p> + +<p class="note"><strong>注:</strong> このクラスと関連サンプルでは、<a +href="{@docRoot}tools/extras/support-library.html">サポート ライブラリ</a>を使用します。理由は、Android 3.0 未満のバージョンで <PH>{@link android.app.Fragment}</PH> API を使用するためです。このクラスのすべての API を使用するには、ライブラリをダウンロードして、アプリに追加する必要があります。</p> + + +<h2>レッスン</h2> + +<dl> + <dt><b><a href="screensizes.html">さまざまな画面サイズのサポート</a></b></dt> + <dd>このレッスンでは、さまざまな画面サイズに適したレイアウトを（柔軟なビュー サイズ、 <PH>{@link android.widget.RelativeLayout}</PH>、画面サイズと画面の向きの修飾子、エイリアス フィルタ、ナインパッチ ビットマップを使用して）設計する方法について学習します。</dd> + + <dt><b><a href="screendensities.html">さまざまな画面密度のサポート</a></b></dt> + <dd>このレッスンでは、（密度非依存ピクセルを使用し、各密度に適したビットマップを提供して）ピクセル密度が異なる画面をサポートする方法について学習します。</dd> + + <dt><b><a href="adaptui.html">順応性のある UI フローの実装</a></b></dt> + <dd>このレッスンでは、いくつかの画面サイズ/密度の組み合わせに適した方法（実行時にアクティブなレイアウトを検出する方法、現在のレイアウトに合わせて応答する方法、画面設定の変更を処理する方法）で UI を実装する方法について学習します。</dd> +</dl> diff --git a/docs/html-intl/ja/training/multiscreen/screendensities.jd b/docs/html-intl/ja/training/multiscreen/screendensities.jd new file mode 100644 index 0000000..3482d5c --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/screendensities.jd @@ -0,0 +1,100 @@ +page.title=さまざまな画面密度のサポート +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +previous.title=さまざまな画面サイズのサポート +previous.link=screensizes.html +next.title=順応性のある UI フローの実装 +next.link=adaptui.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> +<ol> + <li><a href="#TaskUseDP">密度非依存ピクセルを使用する</a></li> + <li><a href="#TaskProvideAltBmp">代替ビットマップを生成する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> + <li><a href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">アイコン設計のガイドライン</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + + +</div> +</div> + +<p>このレッスンでは、異なるリソースを生成し、かつ解像度非依存単位を使用して、異なる画面密度をサポートする方法について学習します。</p> + +<h2 id="TaskUseDP">密度非依存ピクセルを使用する</h2> + +<p>レイアウトを設計する際に回避すべきよくある落とし穴の 1 つとして、絶対ピクセルを使用して距離やサイズを定義することがあります。ピクセルを使用してレイアウトのサイズを定義すると、画面によってピクセル密度が異なるため、問題が起こります。したがって、同じピクセル数では、デバイスが異なる場合に物理サイズが異なる可能性があります。そのため、サイズを指定する場合は、常に <code>dp</code> 単位や <code>sp</code> 単位を使用します。<code>dp</code> とは、1 ピクセルの物理サイズが 160 dpi に相当する密度非依存ピクセルです。<code>sp</code> も基本単位は同じですが、ユーザーの優先テキスト サイズによってサイズが決まるので（スケール非依存ピクセル）、テキスト サイズを定義する際にはこの単位を使用する必要があります（ただし、レイアウト サイズには絶対に使用しないこと）。</p> + +<p>たとえば、2 つのビューの間にスペースを挿入する場合は、<code>px</code> ではなくて <code>dp</code> を使用します:</p> + +<pre> +<Button android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:text="@string/clickme" + android:layout_marginTop="20dp" /> +</pre> + +<p>テキスト サイズを指定する場合は、常に <code>sp</code> を使用します:</p> + +<pre> +<TextView android:layout_width="match_parent" + android:layout_height="wrap_content" + android:textSize="20sp" /> +</pre> + + +<h2 id="TaskProvideAltBmp">代替ビットマップを生成する</h2> + +<p>Android は、画面密度がさまざまなデバイスで動作するため、それぞれの汎用密度バケット（低密度、中密度、高密度、超高密度）に合わせてビットマップ リソースを生成する必要があります。そうすることで、すべての画面密度で画質とパフォーマンスが向上します。</p> + +<p>これらの画像を生成するには、ベクター形式の未加工リソースから、次のサイズ スケールを使用して密度別に画像を生成する必要があります:</p> + +<p><ul> + <li><code>xhdpi</code>: 2.0 + <li><code>hdpi</code>: 1.5 + <li><code>mdpi</code>: 1.0（基準） + <li><code>ldpi</code>: 0.75 +</ul></p> + +<p>つまり、200×200 画像（<code>xhdpi</code> デバイス用）を生成する場合、同じリソースを 150×150 画像（<code>hdpi</code> デバイス用）、100×100 画像（<code>mdpi</code> デバイス用）、75×75（<code>ldpi</code> デバイス用）でも生成する必要があります。</p> + +<p>さらに、生成した画像を <code>res/</code> 下の適切なサブディレクトリに配置することで、アプリが動作するデバイスの画面密度に基づいて、自動的に適切な画像が表示されます:</p> + +<pre class="classic no-pretty-print"> +MyProject/ + res/ + drawable-xhdpi/ + awesomeimage.png + drawable-hdpi/ + awesomeimage.png + drawable-mdpi/ + awesomeimage.png + drawable-ldpi/ + awesomeimage.png +</pre> + +<p>また、<code>@drawable/awesomeimage</code> を参照する場合は常に画面の dpi に基づいて、適切なビットマップが選択されます。</p> + +<p>アプリ用のアイコン アセットを作成するためのヒントとガイドラインについては、<a +href="{@docRoot}guide/practices/ui_guidelines/icon_design.html">アイコン設計のガイドライン</a>をご覧ください。</p> + diff --git a/docs/html-intl/ja/training/multiscreen/screensizes.jd b/docs/html-intl/ja/training/multiscreen/screensizes.jd new file mode 100644 index 0000000..3655a33 --- /dev/null +++ b/docs/html-intl/ja/training/multiscreen/screensizes.jd @@ -0,0 +1,279 @@ +page.title=さまざまな画面サイズのサポート +parent.title=複数画面のデザイン +parent.link=index.html + +trainingnavtop=true +next.title=さまざまな画面密度のサポート +next.link=screendensities.html + +@jd:body + + +<!-- This is the training bar --> +<div id="tb-wrapper"> +<div id="tb"> + +<h2>このレッスンでの学習内容</h2> +<ol> + <li><a href="#TaskUseWrapMatchPar">「wrap_content」と「match_parent」を使用する</a></li> + <li><a href="#TaskUseRelativeLayout">RelativeLayout を使用する</a></li> + <li><a href="#TaskUseSizeQuali">サイズ修飾子を使用する</a></li> + <li><a href="#TaskUseSWQuali">最小幅修飾子を使用する</a></li> + <li><a href="#TaskUseAliasFilters">レイアウト エイリアスを使用する</a></li> + <li><a href="#TaskUseOriQuali">画面の向きの修飾子を使用する</a></li> + <li><a href="#TaskUse9Patch">ナインパッチ ビットマップを使用する</a></li> +</ol> + +<h2>関連ドキュメント</h2> + +<ul> + <li><a href="{@docRoot}guide/practices/screens_support.html">複数画面のサポート</a></li> +</ul> + +<h2>試してみる</h2> + +<div class="download-box"> +<a href="http://developer.android.com/shareables/training/NewsReader.zip" class="button">サンプル アプリのダウンロード</a> +<p class="filename">NewsReader.zip</p> +</div> + +</div> +</div> + +<p>このレッスンでは、異なる画面サイズを以下のような方法でサポートする方法について学習します:</p> +<ul> + <li>画面に収まるようにレイアウト サイズを適切に変更する</li> + <li>画面設定に基づいて適切な UI レイアウトを表示する</li> + <li>適切な画面に適切なレイアウトを適用する</li> + <li>適切にサイズ調整したビットマップを表示する</li> +</ul> + + +<h2 id="TaskUseWrapMatchPar">「wrap_content」と「match_parent」を使用する</h2> + +<p>レイアウトをさまざまな画面サイズに柔軟に対応させるには、一部のビュー コンポーネントの幅と高さに <code>"wrap_content"</code> と <code>"match_parent"</code> を使用する必要があります。<code>"wrap_content"</code> を使用すると、ビューの幅や高さがそのビュー内にコンテンツが収まるのに必要な最小サイズに設定されます。一方、<code>"match_parent"</code>（API レベル 8 より前の名称は <code>"fill_parent"</code>）を使用すると、コンポーネントがその親ビューのサイズに一致するまで拡大されます。</p> + +<p>ハードコーディングされたサイズの代わりに <code>"wrap_content"</code> と <code>"match_parent"</code> を使用することで、ビューはそれぞれ、そのビューに必要なスペースだけを使用したり、空きスペースを埋めるまで拡大したりします。次に例を示します:</p> + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane_with_bar.xml all} + +<p>このサンプルでは、特定のサイズではない <code>"wrap_content"</code> と <code>"match_parent"</code> をコンポーネント サイズにどのように使用しているかに注目してください。こうすることで、異なる画面のサイズと向きにレイアウトを正しく対応させることができます。</p> + +<p>たとえば、このレイアウトを縦表示と横表示で表示したときの見え方を以下に示します。コンポーネントのサイズが幅と高さに自動的に適合している点に注目してください:</p> + +<img src="{@docRoot}images/training/layout-hvga.png" /> +<p class="img-caption"><strong>図 1.</strong> News Reader サンプル アプリの縦表示（左）と横表示（右）</p> + + +<h2 id="TaskUseRelativeLayout">RelativeLayout を使用する</h2> + +<p>ネストされた <PH>{@link android.widget.LinearLayout} インスタンスや、</PH> <code>"wrap_content"</code> と <code>"match_parent"</code> のサイズの組み合わせを使用すると、かなり複雑なレイアウトを作成できます。しかし、 <PH>{@link android.widget.LinearLayout}</PH> では、子ビューの空間的な位置関係を正確に制御することはできません。 <PH>{@link android.widget.LinearLayout} のビューは、</PH> 単に一列に並ぶだけです。子ビューに対して直線以外のさまざまな配置を実現する必要がある場合は、 <PH>{@link android.widget.RelativeLayout}</PH>を使用することでうまくいくことがよくあります。たとえば、1 つの子ビューを画面の左側に配置し、もう 1 つの子ビューを右側に配置できます。</p> + +<p>次に例を示します:</p> + +<pre> +<?xml version="1.0" encoding="utf-8"?> +<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" + android:layout_width="match_parent" + android:layout_height="match_parent"> + <TextView + android:id="@+id/label" + android:layout_width="match_parent" + android:layout_height="wrap_content" + android:text="Type here:"/> + <EditText + android:id="@+id/entry" + android:layout_width="match_parent" + android:layout_height="wrap_content" + android:layout_below="@id/label"/> + <Button + android:id="@+id/ok" + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:layout_below="@id/entry" + android:layout_alignParentRight="true" + android:layout_marginLeft="10dp" + android:text="OK" /> + <Button + android:layout_width="wrap_content" + android:layout_height="wrap_content" + android:layout_toLeftOf="@id/ok" + android:layout_alignTop="@id/ok" + android:text="Cancel" /> +</RelativeLayout> +</pre> + +<p>図 2 は、このレイアウトの QVGA 画面での見え方を示しています。</p> + +<img src="{@docRoot}images/training/relativelayout1.png" /> +<p class="img-caption"><strong>図 2.</strong> QVGA 画面（スモール画面）のスクリーンショット</p> + +<p>図 3 は、このレイアウトのラージ画面での見え方を示しています。</p> + +<img src="{@docRoot}images/training/relativelayout2.png" /> +<p class="img-caption"><strong>図 3.</strong> WSVGA 画面（ラージ画面）のスクリーンショット</p> + +<p>コンポーネントのサイズが変更されても、 <PH>{@link android.widget.RelativeLayout.LayoutParams}</PH>で指定されたとおりに空間的な位置関係が維持されていることがわかります。</p> + + +<h2 id="TaskUseSizeQuali">サイズ修飾子を使用する</h2> + +<p>柔軟なレイアウトや相対的なレイアウトから得られる恩恵は、前のセクションで説明したことくらいです。これらのレイアウトはコンポーネントの内部や周囲のスペースを引き延ばすことでさまざまな画面に対応しますが、それぞれの画面サイズに合った最高のユーザー エクスペリエンスを実現していない可能性があります。したがって、アプリでは、柔軟なレイアウトの実装だけではなく、さまざまな画面設定に合わせた複数の代替レイアウトも必要になります。これは、<a href="http://developer.android.com/guide/practices/screens_support.html#qualifiers">設定修飾子</a>を使用することで実現可能です。設定修飾子により、ランタイムが現在のデバイスの設定に基づいて適切なリソース（画面サイズ別のレイアウト デザインなど）を自動的に選択できます。</p> + +<p>たとえば、多くのアプリでは、ラージ画面用に「2 ペイン」パターンを実装しています（一方のペインに項目リスト、もう一方のペインにそのコンテンツを表示することが可能です）。タブレットやテレビは両方のペインを同時に表示できるほど十分に大きい画面ですが、携帯端末の画面では 2 つのペインを別々に表示する必要があります。そのようなレイアウトを実装するには、次のようなファイルが必要になります:</p> + +<ul> + <li><code>res/layout/main.xml</code>、シングルペイン（デフォルト）レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} +</li> + <li><code>res/layout-large/main.xml</code>、2 ペイン レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} +</li> +</ul> + +<p>2 番目のレイアウトのディレクトリ名の <code>large</code> 修飾子に注目してください。このレイアウトは、ラージ（7 インチ以上のタブレットなど）と分類された画面のデバイスで選択されます。それよりも小さいデバイスでは、その他のレイアウト（修飾子なし）が選択されます。</p> + + +<h2 id="TaskUseSWQuali">最小幅修飾子を使用する</h2> + +<p>Android 3.2 未満のデバイスでデベロッパーが抱えていた問題の 1 つに、Dell Streak、初代 Galaxy Tab、7 インチ タブレット全般を含む、「ラージ」画面サイズの分類があります。しかし、多くのアプリでは、すべて「ラージ」画面と見なされたとしても、このカテゴリ内のデバイスのサイズに合わせて異なるレイアウト（5 インチと 7 インチのデバイス用など）を表示したい場合があります。そこで、Android 3.2 では「最小幅」修飾子などが導入されました。</p> + +<p>最小幅修飾子を使用すると、dp で指定した特定の最小幅の画面を対象とすることができます。たとえば、一般的な 7 インチ タブレットは最小幅が 600 dp なので、これらの画面の UI で 2 つのペイン（ただし、それよりも小さい画面ではシングル リスト）を表示したい場合は、前のセクションで説明した 2 つのレイアウトをシングルペイン レイアウト用と 2 ペイン レイアウト用としてそのまま利用できます。ただし、<code>large</code> サイズ修飾子の代わりに、<code>sw600dp</code> を使用して、最小幅が 600 dp の画面では 2 ペイン レイアウトになるよう指定します:</p> + +<ul> + <li><code>res/layout/main.xml</code>、シングルペイン（デフォルト）レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} +</li> + <li><code>res/layout-sw600dp/main.xml</code>、2 ペイン レイアウト: + +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} +</li> +</ul> + +<p>つまり、最小幅が 600dp 以上のデバイスでは <code>layout-sw600dp/main.xml</code>（2 ペイン）レイアウトが選択され、それよりも小さい画面では <code>layout/main.xml</code>（シングルペイン）レイアウトが選択されるということです。</p> + +<p>ただし、Android 3.2 未満のデバイスではこの修飾子は機能しません。これは <code>sw600dp</code> をサイズ修飾子として認識できないためです。したがって、引き続き <code>large</code> 修飾子も使用する必要があります。そこで、<code>res/layout-sw600dp/main.xml</code> と同じ内容の <code>res/layout-large/main.xml</code> という名前のファイルも必要になります。次のセクションでは、このようにレイアウト ファイルの重複を避けるためのテクニックについて学習します。</p> + + +<h2 id="TaskUseAliasFilters">レイアウト エイリアスを使用する</h2> + +<p>最小幅修飾子は、Android 3.2 以上でしか利用できません。したがって、旧バージョンとの互換性を維持するために、あいまいなサイズ分類（small、normal、large、xlarge）も併用することが必要です。たとえば、携帯端末ではシングルペイン UI、7 インチ タブレットやテレビなどの大きなデバイスではマルチペイン UI を表示するよう UI を設計する場合、以下のようなファイルが必要になります:</p> + +<p><ul> +<li><code>res/layout/main.xml:</code> シングルペイン レイアウト</li> +<li><code>res/layout-large:</code> マルチペイン レイアウト</li> +<li><code>res/layout-sw600dp:</code> マルチペイン レイアウト</li> +</ul></p> + +<p>最後の 2 つのファイルは同じものです。一方は Android 3.2 デバイス用で、もう一方は旧バージョンの Android を搭載したタブレットとテレビ用です。</p> + +<p>このようにタブレット/テレビ用として同じファイルを使用することで起こる重複（さらに、その結果メンテナンスが困難になる状況）を避けるために、エイリアス ファイルを使用できます。たとえば、次のようなレイアウトを定義できます:</p> + +<ul> +<li><code>res/layout/main.xml</code>、シングルペイン レイアウト</li> +<li><code>res/layout/main_twopanes.xml</code>、2 ペイン レイアウト</li> +</ul> + +<p>さらに、次の 2 つのファイルを追加します:</p> + +<p><ul> +<li><code>res/values-large/layout.xml</code>: +<pre> +<resources> + <item name="main" type="layout">@layout/main_twopanes</item> +</resources> +</pre> +</li> + +<li><code>res/values-sw600dp/layout.xml</code>: +<pre> +<resources> + <item name="main" type="layout">@layout/main_twopanes</item> +</resources> +</pre> + +</li> +</ul></p> + +<p>最後の 2 つのファイルの内容は同じですが、実際のレイアウトは定義していません。これらのファイルは、単に <PH>{@code main}</PH> を <PH>{@code main_twopanes}</PH>へのエイリアスになるように設定しただけです。これらのファイルには <code>large</code> と <code>sw600dp</code> セレクタが含まれているので、Android のバージョンに関係なく（ +<PH>Android 3.2 未満のタブレット/テレビは {@code large} に一致し、</PH>Android 3.2 以上のタブレット/テレビは <code>sw600dp</code> に一致します）タブレット/テレビに適用されます。</p> + + +<h2 id="TaskUseOriQuali">画面の向きの修飾子を使用する</h2> + +<p>横表示と縦表示が両方とも正しく表示されるレイアウトもありますが、ほとんどのレイアウトは調整が必要になります。以下に、News Reader サンプル アプリの各画面のサイズと向きでレイアウトがどのように表示されるかを示します:</p> + +<p><ul> +<li><b>スモール画面、縦表示:</b> シングル ペイン、ロゴ付き</li> +<li><b>スモール画面、横表示:</b> シングル ペイン、ロゴ付き</li> +<li><b>7 インチ タブレット、縦表示:</b> シングル ペイン、アクション バー付き</li> +<li><b>7 インチ タブレット、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +<li><b>10 インチ タブレット、縦表示:</b> デュアル ペイン、ナロー、アクション バー付き</li> +<li><b>10 インチ タブレット、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +<li><b>テレビ、横表示:</b> デュアル ペイン、ワイド、アクション バー付き</li> +</ul></p> + +<p>これらの各レイアウトは、<code>res/layout/</code> ディレクトリ内の XML ファイルに定義されています。各レイアウトをさまざまな画面設定に割り当てるには、アプリでレイアウト エイリアスを使用して、各設定に対応付けます:</p> + +<p><code>res/layout/onepane.xml:</code></p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane.xml all} + +<p><code>res/layout/onepane_with_bar.xml:</code></p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/onepane_with_bar.xml all} + +<p><code>res/layout/twopanes.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes.xml all} + +<p><code>res/layout/twopanes_narrow.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/layout/twopanes_narrow.xml all} + +<p>これで、考えられるすべてのレイアウトが定義されました。あとは、設定修飾子を使用して、適切なレイアウトを各設定にマッピングするだけです。そのためには、以下のようなレイアウト エイリアス テクニックを使用することができます:</p> + +<p><code>res/values/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values/layouts.xml all} + +<p><code>res/values-sw600dp-land/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-land/layouts.xml +all} + +<p><code>res/values-sw600dp-port/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-sw600dp-port/layouts.xml +all} + +<p><code>res/values-large-land/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-land/layouts.xml all} + +<p><code>res/values-large-port/layouts.xml</code>:</p> +{@sample development/samples/training/multiscreen/newsreader/res/values-large-port/layouts.xml all} + + + +<h2 id="TaskUse9Patch">ナインパッチ ビットマップを使用する</h2> + +<p>異なる画面サイズをサポートするには、画像リソースも異なるサイズに対応できないといけません。たとえば、ボタンの背景は、適用されるボタンの形状が異なってもサイズが合わなければいけません。</p> + +<p>サイズ変更可能なコンポーネントでシンプルな画像を使用すると、ランタイムによって画像が一様に拡大縮小されるので、いくぶん期待はずれの結果になることがすぐにわかります。これは、ナインパッチ ビットマップを使用することで解決します。ナインパッチ ビットマップとは、拡大可能な領域と拡大不可能な領域が指定された特殊なフォーマットの PNG ファイルです。</p> + +<p>そのため、サイズが変化するコンポーネントで使用するビットマップをデザインする場合は、常にナインパッチを使用してください。ビットマップをナインパッチに変換するには、まず、通常の画像を用意します（図 4: わかりやすく 4 倍に拡大しています）。</p> + +<img src="{@docRoot}images/training/button.png" /> +<p class="img-caption"><strong>図 4.</strong> <code>button.png</code></p> + +<p>次に、 <ode +href="{@docRoot}tools/help/draw9patch.html">SDK の <code>draw9patch</code></a> ユーティリティ（<code>tools/</code> ディレクトリにあります）からナインパッチを実行して、左境界線と上境界線上にピクセル（ドット）を描くことで拡大する領域にマークを付けます。また、右境界線と下境界線上にピクセルを描くことで、コンテンツを入れる領域をマークできます（図 5）。</p> + +<img src="{@docRoot}images/training/button_with_marks.png" /> +<p class="img-caption"><strong>図 5.</strong> <code>button.9.png</code></p> + +<p>境界線上に黒いピクセルがあることに注目してください。左境界線と上境界線上のものは画像を拡大できる領域で、右境界線と下境界線上のものはコンテンツを配置する領域を示しています。</p> + +<p>さらに、<code>.9.png</code> という拡張子にも注目してください。この拡張子は必ず使用してください。そうすることで、通常の PNG 画像ではなく、ナインパッチ画像であることがフレームワークによって検出されます。</p> + +<p>この背景を（<code>android:background="@drawable/button"</code> を設定して）コンポーネントに適用すると、ボタンのサイズに合わせて適切に画像が拡大します（図 6 のさまざまなサイズを参照）。</p> + +<img src="{@docRoot}images/training/buttons_stretched.png" /> +<p class="img-caption"><strong>図 6</strong><code>button.9.png</code> ナインパッチを使用したさまざまなサイズのボタン</p> + |