Merge branch 'mnc-mr-docs' into mnc-ub-dev

Large merge to reconnect automerger for docs branch to mainline.

 Conflicts:
	docs/html-intl/intl/es/index.jd
	docs/html-intl/intl/es/preview/download.jd
	docs/html-intl/intl/es/preview/index.jd
	docs/html-intl/intl/ja/index.jd
	docs/html-intl/intl/ja/preview/download.jd
	docs/html-intl/intl/ja/preview/index.jd
	docs/html-intl/intl/ko/index.jd
	docs/html-intl/intl/ko/preview/download.jd
	docs/html-intl/intl/ko/preview/index.jd
	docs/html-intl/intl/pt-br/index.jd
	docs/html-intl/intl/pt-br/preview/download.jd
	docs/html-intl/intl/pt-br/preview/index.jd
	docs/html-intl/intl/ru/index.jd
	docs/html-intl/intl/ru/preview/download.jd
	docs/html-intl/intl/ru/preview/index.jd
	docs/html-intl/intl/zh-cn/index.jd
	docs/html-intl/intl/zh-cn/preview/download.jd
	docs/html-intl/intl/zh-cn/preview/index.jd
	docs/html-intl/intl/zh-tw/index.jd
	docs/html-intl/intl/zh-tw/preview/download.jd
	docs/html-intl/intl/zh-tw/preview/index.jd
	docs/html/guide/topics/manifest/compatible-screens-element.jd
	docs/html/guide/topics/manifest/uses-feature-element.jd
	docs/html/preview/download.jd
	docs/html/preview/features/runtime-permissions.jd
	docs/html/sdk/index.jd
	docs/html/tools/revisions/studio.jd
	docs/html/tools/sdk/eclipse-adt.jd
	docs/html/tools/support-library/features.jd
	telephony/java/android/telephony/TelephonyManager.java

Bug: 28000173
Change-Id: Iacab0481175f1b32e0ac3bab98cde9e994100e94

3 files changed, 182 insertions, 112 deletions

diff --git a/docs/html-intl/intl/ja/design/patterns/compatibility.jd b/docs/html-intl/intl/ja/design/patterns/compatibility.jd
new file mode 100644
index 000000000000..c035a15a3630
--- /dev/null
+++ b/docs/html-intl/intl/ja/design/patterns/compatibility.jd
@@ -0,0 +1,70 @@
+page.title=下方互換性
+page.tags="support"
+page.metaDescription=Android 4.x がバージョンの古いハードウェアや OS 向けにデザインされた UI にどのように対応するかについての注意事項。
+@jd:body
+
+<a class="notice-developers" href="{@docRoot}training/basics/supporting-devices/index.html">
+  <div>
+    <h3>デベロッパー ドキュメント</h3>
+    <p>異なる端末のサポート</p>
+  </div>
+</a>
+
+<p>Android 3.0 での大きな変更点には、以下のような点があります。</p>
+<ul>
+<li>仮想コントロール（Back、Home、Recents）のナビゲーション処理の導入によるナビゲーション ハードウェア キー（Back、Menu、Search、Home）の廃止
+</li>
+<li>アクションバーでメニュー項目を使用する際の表現パターンの強化</li>
+</ul>
+<p>Android 4.0 では、こういったタブレット向けの変更点が携帯端末プラットフォームにも導入されました。</p>
+
+<h2 id="older-hardware">古いハードウェアやアプリへの Android 4.0 の対応</h2>
+
+<div class="cols">
+  <div class="col-6">
+
+<h4>仮想ナビゲーション コントロールのある携帯端末</h4>
+<p>Android 3.0 以降をターゲットにした Android アプリは、アクションをアクションバーに表示します。アクションバーに収まらないアクションや、トップレベルに表示するほど重要ではないアクションは、アクション オーバーフローに表示されます。
+
+</p>
+<p>ユーザーは、アクションバーをタップすることで、アクション オーバーフローにアクセスできます。</p>
+
+  </div>
+  <div class="col-7">
+
+    <img src="{@docRoot}design/media/compatibility_virtual_nav.png">
+
+  </div>
+</div>
+
+<div class="cols">
+  <div class="col-6">
+
+<h4>物理ナビゲーション キーのある携帯端末</h4>
+<p>従来型のナビゲーション ハードウェア キーのある Android 携帯端末では、画面下部に仮想ナビゲーション バーは表示されません。
+代わりに、メニュー ハードウェア キーからアクション オーバーフローを利用できます。そのため、ポップアップするアクションは先ほどの例と同じように利用できますが、画面の下部に表示される点が異なります。
+</p>
+
+  </div>
+  <div class="col-7">
+
+    <img src="{@docRoot}design/media/compatibility_physical_buttons.png">
+
+  </div>
+</div>
+
+<div class="cols">
+  <div class="col-6">
+
+<h4>仮想ナビゲーション コントロールのある携帯端末でのレガシー アプリ</h4>
+<p>Android 2.3 以前をターゲットにビルドされたアプリを仮想ナビゲーション コントロールのある携帯端末で実行すると、仮想ナビゲーション バーの右側にアクション オーバーフロー コントロールが表示されます。
+コントロールをタップすると、アプリのアクションを従来型の Android メニュー形式で表示できます。
+</p>
+
+  </div>
+  <div class="col-7">
+
+    <img src="{@docRoot}design/media/compatibility_legacy_apps.png">
+
+  </div>
+</div>
diff --git a/docs/html-intl/intl/ja/design/patterns/confirming-acknowledging.jd b/docs/html-intl/intl/ja/design/patterns/confirming-acknowledging.jd
index 35ba821a5cf6..c2dfb8492a8e 100644
--- a/docs/html-intl/intl/ja/design/patterns/confirming-acknowledging.jd
+++ b/docs/html-intl/intl/ja/design/patterns/confirming-acknowledging.jd
@@ -2,69 +2,69 @@ page.title=確認と通知
 page.tags=dialog,toast,notification
 @jd:body
 
-<p>状況に応じて、ユーザーがアプリでアクションを呼び出したときに、テキストを使ってそのアクションを<em>確認</em>したり<em>通知</em>したりするのは良い方法です。</p>
+<p>アプリでアクションを呼び出すときに、テキストでそのアクションを<em>確認</em>または<em>通知</em>するとよい場合があります。</p>
 
-<div class="layout-content-row">
-  <div class="layout-content-col span-6">
+<div class="cols">
+  <div class="col-6">
     <img src="{@docRoot}design/media/confirm_ack_confirming.png">
-    <p><strong>確認</strong>とは、呼び出したアクションを続けるかどうかをユーザーに確認してもらうことです。場合によって、確認は考慮する必要があるアクションに関連する警告や重要情報とともに表示されることがあります。</p>
+    <p><strong>確認</strong>とは、呼び出したアクションを本当に続行してもよいかどうかをユーザーにたずねることです。検討を要するアクションがあれば、それに関する警告や重要情報とともに表示されることもあります。</p>
   </div>
-  <div class="layout-content-col span-6">
+  <div class="col-6">
     <img src="{@docRoot}design/media/confirm_ack_acknowledge.png">
-    <p><strong>通知</strong>とは、呼び出したアクションが完了したことをユーザーにお知らせするテキストを表示することです。これによって、システムが実行している暗黙的な処理の不明瞭さをなくすことができます。場合によって、通知はアクションを元に戻すオプションとともに表示されることがあります。</p>
+    <p><strong>通知</strong>とは、呼び出したアクションが完了したことをユーザーに知らせるテキストを表示することです。システムにより実行中であり、ユーザーには表示されない操作を確認できます。アクションを元に戻すオプションとともに表示されることもあります。</p>
   </div>
 </div>
 
-<p>このような方法でユーザーに情報を伝えると、実行された処理やこれから実行される処理についての不明瞭さを軽減できます。確認や通知によって、後悔するような間違いをするのを防ぐこともできます。</p>
+<p>このような機能を使用すれば、実行済みの処理やこれから実行される処理を明確に把握できます。確認や通知を表示することで、後悔するような間違いを防ぐこともできます。</p>
 
-<h2>ユーザーのアクションを確認または通知する場合</h2>
-<p>すべてのアクションに確認または通知が必要なわけではありません。デザインを決定する際の指針として次のチャートを使用してください。</p>
+<h2>ユーザーのアクションを確認または通知するタイミング</h2>
+<p>すべてのアクションに確認または通知が必要なわけではありません。確認や通知が必要かどうかを判断するには、次のチャートを使用してください。</p>
 <img src="{@docRoot}design/media/confirm_ack_flowchart.png">
 
 <h2>確認</h2>
-<div class="layout-content-row">
-  <div class="layout-content-col span-6">
+<div class="cols">
+  <div class="col-6">
     <h4>例: Google Play ブックス</h4>
     <img src="{@docRoot}design/media/confirm_ack_ex_books.png">
-    <p>この例では、ユーザーが Google Play ライブラリから書籍を削除することを要求しています。その書籍が今後端末で使えなくなることを知ってもらうことが重要であるため、このアクションを確認する<a href="{@docRoot}design/building-blocks/dialogs.html#alerts">アラート</a>が表示されます。</p>
-    <p>確認のダイアログを作成するときは、要求されたアクションがすぐわかるようなタイトルにします。</p>
+    <p>この例では、ユーザーは Google Play ライブラリから書籍を削除するよう要求しています。この書籍が今後いずれの端末でも使用できなくなるということを知らせる必要があるため、このアクションを確認する<a href="{@docRoot}design/building-blocks/dialogs.html#alerts">アラート</a>が表示されます。</p>
+    <p>確認ダイアログは、要求されたアクションをタイトルに記述するなどして、わかりやすく作成します。</p>
   </div>
-  <div class="layout-content-col span-7">
-    <h4>例: Android Beam</h4>
+  <div class="col-7">
+    <h4>例: Android ビーム</h4>
     <img src="{@docRoot}design/media/confirm_ack_ex_beam.png">
-    <p>確認は、必ずしも 2 つのボタンの付いたアラートで示す必要はありません。Android Beam を開始した後に、ユーザーには共有するコンテンツ（この例では写真）にタップするように求めるメッセージが表示されます。共有を続行しない場合は、電話を離すだけです。</p>
+    <p>確認は、必ずしも 2 つのボタンが付いたアラートで行う必要はありません。Android ビームを開始した後、共有するコンテンツ（この例では写真）をタップするようメッセージが表示されます。共有を続行しない場合は、携帯端末を離すだけです。</p>
   </div>
 </div>
 
 <h2>通知</h2>
-<div class="layout-content-row">
-  <div class="layout-content-col span-6">
-    <h4>例: 放置した Gmail 下書きの保存</h4>
+<div class="cols">
+  <div class="col-6">
+    <h4>例: 途中まで書いた Gmail の下書きの保存</h4>
     <img src="{@docRoot}design/media/confirm_ack_ex_draftsave.png">
-    <p>この例では、ユーザーが Gmail 作成画面から前の画面に戻ったり、上位画面に移動したりするときに、予測しないことが起こる可能性があるため、現在の下書きが自動的に保存されます。トースト形式の通知によってその状態が明らかになります。この通知は数秒後にフェードします。</p>
+    <p>この例では、ユーザーが Gmail 作成画面から前の画面に戻ったり、画面の上部に移動したりすると、予測しないことが起こることもあるため、現在の下書きが自動的に保存されています。この動作はトースト形式で通知され、数秒後に消えます。</p>
     <p>この場合、保存操作はユーザーではなくアプリによって行われるため、元に戻す操作は適切ではありません。また、下書きのリストに移動するだけでメッセージの作成をすぐに再開できます。</p>
 
   </div>
-  <div class="layout-content-col span-6">
+  <div class="col-6">
     <h4>例: Gmail スレッドの削除</h4>
     <img src="{@docRoot}design/media/confirm_ack_draft_deleted.png">
-    <p>ユーザーが Gmail のリストからスレッドを削除した後に、元に戻すオプションとともに通知が表示されます。ユーザーがリストのスクロールなど関連しないアクションを実行するまで通知は表示されたままになります。</p>
+    <p>ユーザーが Gmail のリストから会話を削除した後に、元に戻すオプションとともに認定が表示されます。リストのスクロールなど無関係なアクションをユーザーが実行するまで、通知の表示は消えません。</p>
   </div>
 </div>
 
 <h2>確認または通知を行わない場合</h2>
-<div class="layout-content-row">
-  <div class="layout-content-col span-6">
+<div class="cols">
+  <div class="col-6">
     <h4>例: +1 操作</h4>
     <img style="padding: 33px 0 30px;" src="{@docRoot}design/media/confirm_ack_ex_plus1.png">
-    <p><strong>確認は不要</strong>。ユーザーが誤って +1 ボタンをタップしても、大きな問題にはなりません。ボタンをもう一度タップすればアクションを元に戻すことができます。</p>
-    <p><strong>通知は不要</strong>。+1 ボタンがバウンスし、赤に変わります。これは非常にわかりやすいシグナルです。</p>
+    <p><strong>確認は不要です</strong>。ユーザーが誤って [+1] ボタンをタップしても、あまり問題ではありません。ボタンをもう一度タップすれば、アクションを元に戻すことができるからです。</p>
+    <p><strong>通知は不要です</strong>。[+1] ボタンがバウンドして赤に変わります。これは非常にわかりやすいシグナルです。</p>
   </div>
-  <div class="layout-content-col span-7">
-    <h4>例: ホームスクリーンからアプリを削除</h4>
+  <div class="col-7">
+    <h4>例: ホームスクリーンからアプリを削除する場合</h4>
     <img src="{@docRoot}design/media/confirm_ack_ex_removeapp.png">
-    <p><strong>確認は不要</strong>。これは意図的なアクションです。ユーザーはアイテムを比較的大きな分離されたターゲットにドラッグ アンド ドロップする必要があります。そのため、不測の問題が発生することはほとんどありません。ユーザーがこの決定を元に戻したい場合は、ほんの数秒で元に戻すことができます。</p>
-    <p><strong>通知は不要</strong>。ユーザーは自分でアプリをドラッグして削除するため、アプリがホームスクリーンから消えることがわかっています。</p>
+    <p><strong>確認は不要です</strong>。このアクションは賢明に設計されており、ユーザーはアイテムを比較的離れたところにある大きいターゲットにドラッグ アンド ドロップする必要があります。そのため、アクシデントが発生することはほとんどありません。しかもこの操作を取り消したい場合は、ほんの数秒で元に戻すことができるようになっています。</p>
+    <p><strong>通知は不要です</strong>。ユーザーが自分でアプリをドラッグして削除しているので、アプリがホームスクリーンから消えるのがわかっているからです。</p>
 
   </div>
 </div>
diff --git a/docs/html-intl/intl/ja/design/patterns/navigation.jd b/docs/html-intl/intl/ja/design/patterns/navigation.jd
index dbb6b04e14e3..079ad2511f53 100644
--- a/docs/html-intl/intl/ja/design/patterns/navigation.jd
+++ b/docs/html-intl/intl/ja/design/patterns/navigation.jd
@@ -1,213 +1,213 @@
-page.title=Back と Up を使用したナビゲーション
+page.title=Back ボタンと Up ボタンを使用したナビゲーション
 page.tags="navigation","activity","task","up navigation","back navigation"
 page.image=/design/media/navigation_between_siblings_gmail.png
 @jd:body
 
 <a class="notice-developers" href="{@docRoot}training/implementing-navigation/index.html">
   <div>
-    <h3>デベロッパー文書</h3>
-    <p>効果的なナビゲーションを実装する</p>
+    <h3>デベロッパー ドキュメント</h3>
+    <p>効果的なナビゲーションの実装</p>
   </div>
 </a>
 
-<p itemprop="description">一貫したナビゲーションは全体的なユーザーの操作性を向上するために欠かせない重要な要素です。一貫性がなく予測できない動作ほどユーザーにとって不快なものはありません。
-Android 3.0 では、全体的なナビゲーション動作が大きく変更されました。
-注意深く Back と Up のガイドラインに従うことで、アプリのナビゲーションをユーザーにとって予測可能で信頼できるものにすることができます。
+<p itemprop="description">使いやすいアプリでは、ナビゲーションに統一性があります。統一性がなく、動作の読めないアプリほど使いにくいものはありません。
+Android 3.0 では、全体的なナビゲーション動作が大きく変わりました。
+Back ボタンと Up ボタンのガイドラインに従えば、ユーザーにとってわかりやすく、信頼できるナビゲーションを実装できます。
 </p>
-<p>Android 2.3 以前のアプリ内でのナビゲーションはシステムの <em>Back</em> ボタンを使って行われてきました。Android 3.0 よりアクションバーが導入され、第 2 のナビゲーション メカニズムとして <em>Up</em> ボタンが登場しました。このボタンはアプリアイコンと左向きのキャラットで構成されています。
-
+<p>Android 2.3 以前のアプリのナビゲーションはシステムの <em>Back</em> ボタンで行っていました。
+Android 3.0 よりアクションバーが導入され、第 2 のナビゲーション メカニズムとして <em>Up</em> ボタンが登場しました。このボタンはアプリアイコンと左向きのキャレットで表されています。
 </p>
 
 <img src="{@docRoot}design/media/navigation_with_back_and_up.png">
 
-<h2 id="up-vs-back">Up と Back</h2>
+<h2 id="up-vs-back">Up ボタンと Back ボタンの違い</h2>
 
 <p>Up ボタンは、画面間の階層関係に基づいてアプリ内を移動するために使います。
-たとえば、画面 A がアイテムのリストを表示し、アイテムを選択すると（そのアイテムの詳細を表示する）画面 B に移動する場合、画面 B には画面 A に戻るための Up ボタンを用意する必要があります。
+たとえば、画面 A でアイテムのリストを表示し、アイテムを選択すると（そのアイテムの詳細を表示する）画面 B に移動する場合、画面 B には画面 A に戻るための Up ボタンが必要です。
 
 </p>
-<p>画面がアプリの最上位（つまり、アプリのホーム）であれば、Up ボタンを表示すべきではありません。
+<p>画面がアプリのトップ レベル（アプリのホーム）であれば、Up ボタンを表示する必要はありません。
 </p>
 
-<p>システムの Back ボタンはユーザーが最近使用した画面を、さかのぼって順番に移動する場合に使用されます。
-通常このナビゲーションはアプリの階層ではなく、画面を表示した順番に基づいています。
+<p>システムの Back ボタンは、最近使用した画面をさかのぼって順番に移動する場合に使用します。
+通常、このナビゲーションはアプリの階層ではなく、画面を表示した順番に基づいています。
 </p>
 
-<p>前に表示していた画面が現在の画面の親階層となる場合は、Back ボタンを押すとUp ボタンを押したときと同じ結果になります &mdash; これはよくある動作です。
+<p>前に表示していた画面が現在の画面の親階層となる場合は、Back ボタンを押すと Up ボタンを押したときと同じ結果になります &mdash; これは一般的な動作です。
 
-ただし、Up ボタンではユーザーが確実にアプリ内に留まるのに対して、Back ボタンを使えばホームスクリーンに、さらには別のアプリに戻ることさえできます。
+ただし、Up ボタンではユーザーの移動がアプリ内に限られるのに対して、Back ボタンではホーム画面や、別のアプリにも戻れます。
 </p>
 
 <img src="{@docRoot}design/media/navigation_up_vs_back_gmail.png">
 
-<p>Back ボタンは、画面間を直接ナビゲーションするだけでなく、次のような動作もサポートします。
+<p>Back ボタンは、画面間を直接ナビゲーションするだけでなく、次のような動作にも対応しています。
 </p>
 <ul>
 <li>フローティング ウィンドウ（ダイアログ、ポップアップ）を閉じる</li>
 <li>コンテキスト アクションバーを閉じて、選択したアイテムのハイライト表示を解除する</li>
-<li>オンスクリーン キーボード（IME）を非表示にする</li>
+<li>画面上のキーボード（IME）を非表示にする</li>
 </ul>
 <h2 id="within-app">アプリ内でのナビゲーション</h2>
 
-<h4>複数のエントリ ポイントのある画面のナビゲーション</h4>
-<p>画面にアプリ階層内の正確な位置がなく、アプリ内の他のどの画面からでもアクセスできる設定画面などのように複数のエントリ ポイントからアクセスできる場合があります。この場合、Up ボタンは参照元の画面に戻ることを選択する必要があります。これは Back も同様です。
-&mdash;
+<h4>エントリ ポイントが複数ある画面へのナビゲート</h4>
+<p>設定画面のように、アプリ内の他のどの画面からでもアクセスでき、アプリ階層内に定位置がなく、複数のエントリ ポイントからアクセスできる画面もあります。
 
+この場合、Up ボタンは Back ボタンと同じように元の画面に戻ります。
 </p>
-<h4>画面内でビューを変更する</h4>
-<p>画面のビュー オプションを変更しても Up と Back の動作は変わりません。画面はアプリの階層内の同じ位置に留まり、新しいナビゲーション履歴は作成されません。
+<h4>画面内でのビューの変更</h4>
+<p>画面のビュー オプションを変更しても Up ボタンと Back ボタンの動作は変わりません。画面はアプリの階層内の同じ位置にあり、新しいナビゲーション履歴は作成されません。
 </p>
 <p>このようなビューの変更には次のようなものがあります。</p>
 <ul>
-<li>タブや左右のスワイプを使ってビューを切り替える</li>
-<li>ドロップダウン（折りたたみタブ）を使ってビューを切り替える</li>
-<li>リストにフィルタをかける</li>
-<li>リストをソートする</li>
-<li>表示の方法を変える（ズームなど）</li>
+<li>タブや左右のスワイプを使ったビューの切り替え</li>
+<li>ドロップダウン（折りたたみタブ）を使ったビューの切り替え</li>
+<li>リストへのフィルタの適用</li>
+<li>リストの並び替え</li>
+<li>表示方法の変更（ズームなど）</li>
 </ul>
 <h4>兄弟画面間のナビゲーション</h4>
-<p>アプリでアイテムのリストから 1 つのアイテム詳細画面に移動するとき、そのアイテムからリスト内の前後にある別のアイテムへのナビゲーションをサポートするのが望ましいことがよくあります。
+<p>アプリでアイテムのリストから選択して、あるアイテムの詳細画面に移動するとき、そのアイテムからリストの前後にある別のアイテムにナビゲーションできるようにすると使いやすくなる場合があります。
 
-たとえば、Gmail では、スワイプすることで、ある会話から同じ受信トレイの新しいまたは古い会話へ左右に簡単に移動できます。
-画面内でビューを変更する場合と同じように、このようなナビゲーションによって Up または Back の動作は変わりません。
+たとえば、Gmail で左か右にスワイプすると、同じ受信トレイのある会話から新しい会話や古い会話に簡単に移動できます。
+画面内でビューを変更する場合と同様に、このナビゲーションでも Up ボタンまたは Back ボタンの動作は変わりません。
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_siblings_gmail.png">
 
-<p>しかし、参照リストで結び付けられていない関連詳細ビュー間をブラウジングする場合 &mdash; たとえば Play ストアで同じデベロッパーのアプリや同じアーティストのアルバム間をブラウジング場合、その動作はこれとは明らかに異なります。
+<p>ただし、参照リストで結び付けられていない関連詳細ビュー間をブラウジングする場合は例外です。たとえば Play Store で同じデベロッパーのアプリや同じアーティストのアルバム間をブラウジングする場合です。
 
 この場合、各リンクをたどると履歴が作成され、Back ボタンで以前に表示した各画面に戻ることになります。
-Up では常にこれらの関連画面をバイパスして、直前に表示したコンテナ画面に移動します。
+Up ボタンを使用するとこれらの関連画面をバイパスして、直前に表示したコンテナ画面に移動します。
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_siblings_market1.png">
 
-<p>Up の動作を詳細ビューの知識に基づいてより使いやすくすることができます。
-前述の Play ストアの例で、ユーザーが直前に表示した書籍から映画版の詳細に移動したとします。
-その場合、Up でユーザーが前に表示していないコンテナ（映画）に戻ることができます。
+<p>詳細ビューを応用すれば、Up ボタンを使いやすくできます。
+前述の Play Store の例で、直前に表示した書籍から映画版の詳細に移動したとします。
+その場合、Up ボタンを使用すると前に表示していないコンテナ（映画）に戻ることができます。
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_siblings_market2.png">
 
-<h2 id="into-your-app">ホームスクリーンのウィジェットと通知によるアプリへのナビゲーション</h2>
+<h2 id="into-your-app">ホーム画面のウィジェットと通知を使用したアプリへのナビゲーション</h2>
 
-<p>ホームスクリーンのウィジェットや通知を使ってユーザーがアプリ階層内の深い階層にある画面に直接移動できるようにします。
-たとえば、Gmail の受信ボックスのウィジェットと新しいメッセージ通知はどちらも受信トレイ画面をバイパスし、会話ビューを直接表示できます。
+<p>ホーム画面のウィジェットや通知を使用して、アプリの深い階層にある画面に直接移動できるようにします。
+たとえば、Gmail の受信トレイのウィジェットと新しいメッセージ通知をタップすると、どちらも受信トレイ画面をバイパスし、会話ビューを直接表示できます。
 </p>
 
 <p>この両方の機能で、Up ボタンを次のように処理します。</p>
 
 <ul>
-<li><em>通常アプリ内の特定の画面から移動先画面に移動する場合</em>、Up でその画面に移動します。
+<li><em>通常どおりにアプリの特定の画面から移動先画面に移動する場合</em>、Up ボタンを使用するとその画面に移動します。
 </li>
-<li><em>それ以外の場合は</em>、Up でアプリの最上位（「ホーム」）画面に移動します。</li>
+<li><em>それ以外の場合は</em>、Up ボタンを使用するとアプリのトップレベル（[ホーム]）の画面に移動します。</li>
 </ul>
 
-<p>Back ボタンの場合は、アプリの最上位画面への完全な上向きナビゲーション パスをタスクのバックスタックに挿入してナビゲーションをより予測可能なものにする必要があります。
-この設定によって、アプリにどのように入ったか忘れたユーザーは、終了前のアプリの最上位画面に移動できます。
+<p>Back ボタンの場合は、アプリのトップ レベルの画面に直接ナビゲートできるパスをタスクのバック スタックに挿入して、わかりやすいナビゲーションにします。
+こうすることで、アプリをどのように起動したか覚えていなくても、トップ レベルの画面に移動してから終了できます。
 
 </p>
 
-<p>たとえば Gmail のホームスクリーンのウィジェットには、その作成画面に直接移動するボタンがあります。
-作成画面の Up または Back で受信トレイが表示され、そこから Back ボタンでホームに移動します。
+<p>たとえば Gmail のホーム画面のウィジェットには、作成画面に直接移動するボタンがあります。
+作成画面の Up ボタンまたは Back ボタンで受信トレイが表示され、そこから Back ボタンでホームに移動します。
 </p>
 
 <img src="{@docRoot}design/media/navigation_from_outside_back.png">
 
 <h4>間接通知</h4>
 
-<p>アプリで複数のイベントに関する情報を同時に表示する必要がある場合、1 つの通知を使ってユーザーをインタースティシャル画面に導くことができます。
-この画面にはこれらのイベントがまとめてあり、アプリのさらに深い階層に移動するためのパスが示されます。このスタイルの通知を<em>間接通知</em>と呼びます。
-
+<p>アプリで複数のイベントに関する情報を同時に表示する必要がある場合、通知を 1 つにまとめてそこからインタースティシャル画面に遷移させることができます。
+この画面にはこれらのイベントの要約が表示されており、アプリのさらに深い階層に移動するパスが示されます。
+このスタイルの通知を<em>間接通知</em>と呼びます。
 </p>
 
-<p>標準（直接）通知とは異なり、間接通知のインタースティシャル画面から Back を押すとユーザーは通知がトリガーされた地点に戻ります &mdash; バックスタックには追加の画面は挿入されません。
+<p>標準（直接）通知とは異なり、間接通知のインタースティシャル画面で Back ボタンを押すと、通知がトリガーされた画面に戻ります。バックスタックには追加の画面は挿入されません。
 
-ユーザーがインタースティシャル画面からアプリに移動すると、Up および Back は前述した標準通知の場合と同様に動作します。つまりインタースティシャル画面に戻るのではなくアプリ内でナビゲーションします。
+ユーザーがインタースティシャル画面からアプリに移動すると、Up ボタンと Back ボタンは前述の標準通知と同様に動作します。つまり、インタースティシャル画面に戻るのではなくアプリ内で遷移します。
 
 </p>
 
-<p>たとえば Gmail のユーザーがカレンダーから間接通知を受け取ったとします。この通知をタップするとインタースティシャル画面が開き、複数の異なるイベントに関するリマインダーが表示されます。
+<p>たとえば Gmail がカレンダーから間接通知を受け取ったとします。この通知をタップするとインタースティシャル画面が開き、複数の異なるイベントのリマインダーが表示されます。
 
-インタースティシャル画面で Back をタップすると Gmail に戻ります。特定のイベントをタップすると、インタースティシャル画面から完全なカレンダー アプリに移動し、そのイベントの詳細が表示されます。
+インタースティシャル画面で Back ボタンをタップすると Gmail に戻ります。特定のイベントをタップすると、インタースティシャル画面からカレンダー アプリに移動し、そのイベントの詳細が表示されます。
 
-イベントの詳細から、Up および Back を使うとカレンダーの最上位ビューが表示されます。</p>
+イベントの詳細画面で Up ボタンや Back ボタンを使うと、カレンダーのトップ ビューに移動します。</p>
 
 <img src="{@docRoot}design/media/navigation_indirect_notification.png">
 
 <h4>ポップアップ通知</h4>
 
-<p><em>ポップアップ通知</em>は通知ドロワーをバイパスしてユーザーの前に直接表示されます。
-ポップアップ通知はめったに使われません。<strong>タイムリーな応答が要求され、ユーザーのコンテキストの中断が必要な場合に使われます</strong>。
-たとえばトークでは、このスタイルを使って友人からのビデオチャットへの参加に関する招待状についてユーザーに通知します。というのも、この招待状は数秒後に自動的に期限切れになるからです。
+<p><em>ポップアップ通知</em>は通知ドロワーをバイパスし、直接表示される通知です。
+ポップアップ通知はほとんど使われません。<strong>タイムリーな応答が要求され、ユーザーの操作の中断が必要な場合にのみ使うべきです</strong>。
+たとえばトークでは、友人からのビデオチャットへの招待が数秒後に自動的に期限切れとなる場合、このスタイルを使ってユーザーに通知します。
 
 </p>
 
-<p>ナビゲーション動作の点から、ポップアップ通知は間接通知のインタースティシャル画面の動作に厳密に従います。
-Back でポップアップ通知は閉じます。ユーザーがポップアップから通知元のアプリに移動すると、Up と Back は標準通知のルールに従い、アプリ内でナビゲーションします。
+<p>ナビゲーションでは、間接通知のインタースティシャル画面の動作に慎重に従ってポップアップ通知を行います。
+Back ボタンでポップアップ通知を閉じます。ポップアップから通知対象のアプリに移動すると、Up ボタンと Back ボタンは標準通知のルールに従って、そのアプリ内で通常のナビゲーションを実行します。
 
 </p>
 
 <img src="{@docRoot}design/media/navigation_popup_notification.png">
 
-<h2 id="between-apps">アプリ間のナビゲーション</h2>
-
-<p>Android システムの基本的な利点の 1 つにアプリ同士がそれぞれをアクティブにできる機能があります。これによりユーザーは特定のアプリから別のアプリへ直接移動できます。
-たとえば写真を撮影する必要があるアプリでは、カメラアプリをアクティブにすることができます。カメラアプリは写真を参照元のアプリに戻します。これはデベロッパーにとっては他のアプリのコードを簡単に利用できるという点で、またユーザーにとっては通常実行するアクションに対して一貫した操作を実行できるという点で大きなメリットです。
+<h2 id="between-apps">アプリ間ナビゲーション</h2>
 
+<p>Android システムの基本的な利点の 1 つに、アプリが別のアプリを起動できる機能があります。これを使用すると、あるアプリから別のアプリへ直接移動できます。
+たとえば、写真をキャプチャするアプリで、カメラアプリを起動できます。カメラアプリは写真を起動元のアプリに返します。
 
+デベロッパーにとっては他のアプリのコードを簡単に利用できるという点で、ユーザーにとってはよく実行するアクションを常に同じ操作で実行できるという点で大きなメリットです。
 
 </p>
 
-<p>アプリ間のナビゲーションを理解するには、次に説明する Android フレームワークの動作を理解することが重要です。
+<p>アプリ間ナビゲーションを理解するには、次に説明する Android フレームワークの動作を理解する必要があります。
 </p>
 
 <h4>アクティビティ、タスク、インテント</h4>
 
-<p>Android における<strong>アクティビティ</strong>とは情報の画面と、ユーザーが実行できるすべての関連アクションを定義するアプリケーション コンポーネントです。
-アプリはアクティビティのコレクションで、作成したアクティビティと他のアプリから再利用するアクティビティの両方で構成されています。
+<p>Android における<strong>アクティビティ</strong>とは、情報を表示する画面と、実行できるすべての関連アクションを定義するアプリケーション コンポーネントのことです。
+アプリはアクティビティの集まりで構成され、作成したアクティビティと他のアプリから再利用するアクティビティで構成されています。
 </p>
 
-<p><strong>タスク</strong>とは目標を実現するためにユーザーが従う一連のアクティビティです。1 つのタスクで 1 つのアプリだけのアクティビティを利用することも、複数のアプリのアクティビティを利用することもできます。
+<p><strong>タスク</strong>とは目的の動作を遂行するために実行する、一連のアクティビティのことです。1 つのタスクで 1 つのアプリだけのアクティビティを利用することも、複数のアプリのアクティビティを利用することもできます。
 
 </p>
 
-<p><strong>インテント</strong>とは、あるアプリがアクションの実行に関して別のアプリのサポートが必要であることを示すメカニズムです。
-アプリのアクティビティでそれらのアプリが対応できるインテントを示すことができます。
-「共有」などの一般的なインテントの場合、ユーザーはその要求を実現できる多くのアプリをインストールしている場合があります。
+<p><strong>インテント</strong>とは、アプリがあるアクションを実行するために、別のアプリにアシストを要求するためのシグナルを出すメカニズムです。
+アプリのアクティビティは、どのようなインテントに応答できるか決めることができます。
+「共有」などの一般的なインテントの場合、その要求に対応できるアプリが複数インストールされていることもあります。
 </p>
 
-<h4>例: 共有をサポートするアプリ間のナビゲーション</h4>
-
-<p>アクティビティ、タスク、インテントの連携を理解するには、1 つのアプリが別のアプリを使ってユーザーによるコンテンツの共有を可能にする仕組みを知る必要があります。たとえばホームから Play ストアのアプリを起動すると、新しいタスク A が開始されるとします（以下の図を参照）。
+<h4>例: アプリ間をナビゲートして共有をサポートする</h4>
 
-Play ストア内をナビゲートし、プロンプトで表示された書籍をタップしてその詳細を表示した後もユーザーは同じタスク内に留まり、アクティビティを追加するとタスクは拡張されます。
-「共有」アクションをトリガーすると、共有インテントを処理するよう登録されている（さまざまなアプリの）各アクティビティを示すダイアログがユーザー表示されます。
+<p>アクティビティ、タスク、インテントの連携を理解するには、あるアプリが別のアプリを使ってコンテンツを共有する仕組みについて理解する必要があります。
+たとえば、ホームから Play Store のアプリを起動すると、新しいタスク A が開始されるとします（以下の図を参照）。
+Play Store 内をナビゲートし、おすすめの書籍をタップしてその詳細を表示した後もユーザーは同じタスク内に留まり、アクティビティを追加するとタスクが拡張されます。
+「共有」アクションをトリガーすると、共有インテントを処理するよう登録されている（さまざまなアプリの）各アクティビティを一覧表示するダイアログが表示されます。
 
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_apps_inward.png">
 
-<p>ユーザーが Gmail 経由で共有することを選択すると、Gmail の作成アクティビティがタスク A の続きとして追加されます &mdash; 新しいタスクは作成されません。
-Gmail にバックグラウンドで実行中の独自のタスクがある場合、そのタスクは影響を受けません。
+<p>Gmail で共有するよう選択すると、Gmail の作成アクティビティがタスク A の続きとして追加され、新しいタスクは作成されません。
+Gmail にバックグラウンドで実行中のタスクがある場合、そのタスクは影響を受けません。
 </p>
 
-<p>作成アクティビティからメッセージを送信するか、Back ボタンをタップするとユーザーは書籍の詳細アクティビティに戻ります。
-Back を連続してタップすると Play ストアに戻り、最終的にはホームが表示されます。
+<p>作成アクティビティからメッセージを送信するか、Back ボタンをタップすると書籍の詳細アクティビティに戻ります。
+Back ボタンを連続してタップすると Play Store に戻り、最後にホーム画面が表示されます。
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_apps_back.png">
 
-<p>ただし、作成アクティビティから Up をタップすると、ユーザーは Gmail 内に留まる意思を示すことになります。
-Gmail の会話リストのアクティビティが表示され、新しいタスク B が作成されます。新しいタスクは常にホームをルートとしているため、会話リストからBack をタップするとホームに戻ります。
+<p>ただし、作成アクティビティで Up ボタンをタップすると、Gmail で引き続き作業することになります。
+Gmail の会話リストのアクティビティが表示され、新しいタスク B が作成されます。新しいタスクでは常にホーム画面がルートになるため、会話リストから Back ボタンをタップするとホーム画面に戻ります。
 </p>
 
 <img src="{@docRoot}design/media/navigation_between_apps_up.png">
 
-<p>タスク A はバックグラウンドで維持され、ユーザー後から（たとえば [最近使ったアプリ] 画面経由で）このタスクに戻ることができます。
-Gmail にバックグラウンドで実行中の独自のタスクが既にある場合、そのタスクはタスク B に置き換えられます &mdash; 前のコンテキストはユーザーの新しい目標の導入より破棄されます。
+<p>タスク A はバックグラウンドで待機しているので、後から（たとえば [最近使ったアプリ] 画面から）このタスクに戻ることができます。
+Gmail にバックグラウンドで実行中のタスクが既にある場合、そのタスクはタスク B に置き換えられます。新しいタスクが選択され、前のコンテキストは破棄されます。
 </p>
 
-<p>アプリがアプリ階層内の深い階層にあるアクティビティでインテントを処理するように登録されている場合は、Up ナビゲーションの指定方法について<a href="#into-your-app">ホームスクリーンのウィジェットと通知によるアプリへのナビゲーション</a>をご覧ください。
+<p>深い階層にあるアクティビティでインテントを処理するようアプリで登録されている場合は、Up ナビゲーションの指定方法については、<a href="#into-your-app">ホーム画面のウィジェットと通知を使用したアプリへのナビゲーション</a>をご覧ください。
 
 </p>