diff --git a/docs/html-intl/intl/ja/preview/backup/index.jd b/docs/html-intl/intl/ja/preview/backup/index.jd new file mode 100644 index 0000000000000..b558cdd0843c7 --- /dev/null +++ b/docs/html-intl/intl/ja/preview/backup/index.jd @@ -0,0 +1,327 @@ +page.title=アプリの自動バックアップ +page.tags=バックアップ, previewresources, androidm +page.keywords=バックアップ,自動バックアップ,プレビュー +page.image=images/cards/card-auto-backup_2x.png +@jd:body + +
+ アプリ内のデータ作成や環境設定は、多大な労力と時間を必要とする作業です。 +端末が破損したり、新しい端末にアップグレードしたりする場合に、そのデータを保持することが、快適な操作性を提供する上で非常に重要です。 +Android M Preview を実行する端末では、アプリデータを Google ドライブに自動的にバックアップすることで、前述のような状況でも快適な操作性を実現できます。 + +アプリデータは、ユーザーが端末を変更したりアップグレードしたりした場合に自動的に復元されます。 + +
+ ++ 自動バックアップは、Android M Preview を実行する端末にインストールされているすべてのアプリで有効になっています。追加のアプリコードは必要ありません。 +ユーザーは、自動データ バックアップを使用しないよう選択することもできます。 +また、バックアップするアプリのデータを制限することもできます。 +
+ ++ このドキュメントでは、新しいシステムの動作と、バックアップするアプリデータを指定する方法について説明します。 + +
+ ++ 自動バックアップ機能では、アプリがユーザーの端末上に作成するデータを、ユーザーの Google ドライブ アカウントにアップロードして暗号化することで、そのデータを保持します。 +開発者やユーザーにデータ ストレージの費用が発生することはなく、保存されたデータはユーザー個人のドライブ容量にはカウントされません。 +M Preview の期間中、ユーザーは 1 つの Android アプリにつき最大 25 MB までのデータを保存できます。 + +
+ ++ 自動バックアップは、端末がアイドル中で、電源に接続されていて、Wi-Fi に接続されている場合に、24 時間ごとに実行されます。 +これらの条件を満たしたとき、バックアップ マネージャー サービスが利用可能なすべてのバックアップ データをクラウドにアップロードします。 +ユーザーが新しい端末に切り替えたり、バックアップされたアプリをアンインストールしたり再インストールしたりした場合、復元操作によりバックアップされたデータが新しくインストールされたアプリのデータ ディレクトリにコピーされます。 + + +
+ ++ 注: アプリが以前の Android バックアップ サービスを利用している場合、この新しい動作は適用されず、既存のバックアップ動作が引き続き適用されます。 + + +
+ + ++ 一時ファイルやキャッシュなど、バックアップする必要のないアプリデータもあるため、自動バックアップ サービスではデフォルトで一部のデータ ファイルを除外します。 + +
+ ++ 前のセクションの自動除外ファイル一覧にあるものを除いて、M Preview 端末にインストールされたすべてのアプリで作成されるデータがバックアップ対象です。 +そこからさらに、アプリ マニフェストの設定を使用して、アプリからバックアップするデータを制限したり設定したりできます。 + +
+ ++ アプリに必要なデータとその保存方法によって、特定のファイルやディレクトリを対象とするか、除外するかの明確なルールが必要になる場合があります。 +自動バックアップ サービスでは、XML 構成ファイルとアプリ マニフェストを使ってそのようなバックアップ ツールを設定できます。 + +アプリ マニフェストでは、次の例のように、バックアップ スキームの構成ファイルを指定できます。 + +
+ ++<?xml version="1.0" encoding="utf-8"?> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" + xmlns:tools="http://schemas.android.com/tools" + package="com.my.appexample"> + <uses-sdk android:minSdkVersion="MNC"/> + <uses-sdk android:targetSdkVersion="MNC"/> + <app ... + android:fullBackupContent="@xml/mybackupscheme"> + </app> + ... +</manifest> ++ +
+ このサンプル コードでは、android:fullBackupContent 属性がアプリの開発プロジェクトの res/xml/ ディレクトリにある mybackupscheme.xml という名前の XML ファイルを指定しています。
+
+この構成ファイルには、バックアップ対象とするファイルのルールが含まれています。
+次のサンプル コードは、バックアップから特定のファイルを除外する構成ファイルを示しています。
+
+
+<?xml version="1.0" encoding="utf-8"?> +<full-backup-content> + <exclude domain="database" path="device_info.db"/> +</full-backup-content> ++ +
+ この例のバックアップ構成では、特定のデータベース ファイルのみをバックアップから除外しています。 + それ以外のファイルはすべてバックアップされます。 +
+ ++ バックアップ サービスの設定では、バックアップに含める、または除外するファイルを指定できます。 +データ バックアップ設定の xml ファイルの構文は次のとおりです。 +
+ ++<full-backup-content> + <include domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> + <exclude domain=["file" | "database" | "sharedpref" | "external" | "root"] path="string" /> +</full-backup-content> ++ +
+ 次のエレメントと属性を使って、バックアップに含める、または除外するファイルを指定できます。 + +
+ +<include>。システムにデフォルトでアプリのすべてのデータをバックアップさせるのではなく、バックアップするリソースを自身で指定する場合、このエレメントを使用します。
+<include> タグを指定すると、システムはこのエレメントで指定されたリソースのみをバックアップします。
+
+
+ <exclude>。バックアップから除外するリソースを指定するには、このエレメントを使用します。
+システムは、このエレメントで指定されたリソース以外のすべてのアプリ データをバックアップします。
+
+ domain. バックアップに含める、または除外するリソースのタイプ。この属性を指定する際に有効な値:
+
+ root。リソースがアプリのルート ディレクトリにあることを指定します。
+ file。
+{@link android.content.Context#getFilesDir getFilesDir()} メソッドで返されるディレクトリ内のリソースに相当します。
+ database。
+{@link android.content.Context#getDatabasePath getDatabasePath()} メソッドや
+{@link android.database.sqlite.SQLiteOpenHelper} クラスを使用して返されるデータベースに相当します。
+ sharedpref。
+{@link android.content.Context#getSharedPreferences getSharedPreferences()} メソッドで返される
+{@link android.content.SharedPreferences} オブジェクトに相当します。
+ external。リソースが外部ストレージにあることを指定し、
+{@link android.content.Context#getExternalFilesDir getExternalFilesDir()}
+ メソッドで返されるディレクトリ内のファイルに相当します。
+ path。バックアップに含める、または除外するリソースへのファイルパス。
+
+
+ マニフェストのアプリ エレメントにある android:allowBackup 属性を false に設定すると、一切のデータを自動バックアップしないように選択できます。
+
+この設定を、次のサンプル コードで示します。
+
+<?xml version="1.0" encoding="utf-8"?> +<manifest xmlns:android="http://schemas.android.com/apk/res/android" + xmlns:tools="http://schemas.android.com/tools" + package="com.my.appexample"> + <uses-sdk android:minSdkVersion="MNC"/> + <uses-sdk android:targetSdkVersion="MNC"/> + <app ... + android:allowBackup="false"> + </app> + ... +</manifest> ++ + +
+ バックアップ設定を作成したら、アプリでデータが保存され、正常に復元されることをテストして確認する必要があります。 + +
+ + ++ バックアップで XML ファイルがどのように解析されるかを確認するため、テストのバックアップを実行する前にログ機能を有効にします。 + +
+ ++$ adb shell setprop log.tag.BackupXmlParserLogging VERBOSE ++ +
手動でバックアップを実行するには、まず次のコマンドを呼び出してバックアップ マネージャーを初期化する必要があります。 + +
+ ++$ adb shell bmgr run ++ +
+ 次に、次のコマンドを使って、アプリのパッケージ名を <PACKAGE> パラメータで指定して手動でアプリケーションをバックアップします。
+
+
+$ adb shell bmgr fullbackup <PACKAGE>+ + +
+ アプリのバックアップ後に手動で復元を開始するには、アプリのパッケージ名を <PACKAGE> パラメータで指定します。
+
+
+$ adb shell bmgr restore <PACKAGE> ++ +
+ 警告: このアクションを実行すると、アプリが停止し、復元操作を実行する前にデータが消去されます。 + +
+ ++ アプリをアンインストールしてから再インストールすることで、アプリの復元プロセスを開始します。アプリのインストールが完了すると、アプリデータが自動的にクラウドから復元されます。 + +
+ + ++ 問題が発生した場合は、[設定] > [バックアップ]でバックアップをオン/オフに切り替え、端末を工場出荷時の状態にリセットするか、次のコマンドを呼び出して、バックアップ データと関連メタデータを消去できます。 + + +
+ +$ adb shell bmgr wipe <TRANSPORT> <PACKAGE>+ +
+ <TRANSPORT> には、com.google.android.gms というプレフィクスが付く必要があります。
+ Transport の一覧を取得するには、次のコマンドを呼び出します。
+
$ adb shell bmgr list transports+ +
自動バックアップ サービスには、次のような既知の問題があります。
+ ++ Android M Preview SDK には、アプリとプラットフォームの次期リリースで提供される新しい API とのテストに役立つ開発ツール、Android システム ファイル、ライブラリ ファイルが含まれています。 +このドキュメントでは、アプリのテスト用にダウンロードできる Preview のコンポーネントを入手する方法について説明します。 + +
+ + ++ Preview SDK Android SDK マネージャー経由でダウンロードできます。Preview SDK のダウンロードと設定の詳細については、Set Up the Preview SDK をご覧ください。 + +
+ + ++ デベロッパー ドキュメントのダウンロード パッケージでは、詳細な Preview の API リファレンス情報や API の比較レポートが提供されます。 +
+ +| 説明 | +ダウンロード / チェックサム | +
|---|---|
| Android M Preview デベロッパー ドキュメント |
+ m-preview-1-developer-docs.zip + MD5: b65201b0d35416f5a1b7a071b52854a7 + SHA-1: d47e856aa65e06897e6edd902ad8d2b1f05ac3ec + |
+
| 端末 | +ダウンロード / チェックサム | +
|---|---|
| Nexus 5(GSM/LTE) "hammerhead" |
+ hammerhead-MPZ44Q-preview-55d76d3a.tgz + MD5:9e2631b06c6525e401ceaae3677ff320 + SHA-1:55d76d3a379b18f3363f28d8a462c236ab96fc36 + |
+
| Nexus 6 "shamu" |
+ shamu-MPZ44Q-preview-c1d6506a.tgz + MD5:307cbf9dab0a38df4ab2639d02be12aa + SHA-1: c1d6506a74094bdb2f4b8677c7fe4967334f9ea8 + |
+
| Nexus 9 "volantis" |
+ volantis-MPZ44Q-preview-d15ad483.tgz + MD5: fae40377fd999d2b09128665c915264d + SHA-1:7ab05f96093b2cb370b226f65931202714cbc2ca + |
+
| Nexus Player "fugu" |
+ fugu-MPZ44Q-preview-2406ba05.tgz + MD5:815902141a85cc65e7725f005cad31d5 + SHA-1:2406ba0598dea1e69110497ac0bc8e16789bc8fb + |
+
+ テスト用に端末イメージを使用するには、互換性のある端末にインストールする必要があります。次の手順に従って、システム イメージをインストールします。 + +
+ ++ 注: 開発用端末に Preview のシステム イメージをフラッシュすると、OTA アップデートを通じて次のプレビュー リリースに自動的にアップグレードされます。 + +
+ ++ Preview をアンインストールして、工場出荷時の仕様に戻すには、 +developers.google.com/android にアクセス +して、端末にフラッシュするイメージをダウンロードします。同じページの手順に従って端末にイメージをフラッシュします。 + +
+ + + + + + + + diff --git a/docs/html-intl/intl/ja/preview/features/app-linking.jd b/docs/html-intl/intl/ja/preview/features/app-linking.jd new file mode 100644 index 0000000000000..92da0b42ae825 --- /dev/null +++ b/docs/html-intl/intl/ja/preview/features/app-linking.jd @@ -0,0 +1,123 @@ +page.title=App Links +page.image=images/cards/card-app-linking_2x.png +page.keywords=applinking,deeplinks,intents +@jd:body + ++ Android インテント システムは、アプリでコンテンツや要求を処理できるようにする柔軟なメカニズムです。 + 複数のアプリが、それぞれのインテント フィルタに一致する URI パターンを宣言できます。デフォルトのローンチ ハンドラを持たないウェブリンクをユーザーがクリックしたとき、一致するインテント フィルタが宣言されているアプリの一覧から選択するダイアログがプラットフォームによってユーザーに表示されます。 + + +
+ ++ Android M Developer Preview でサポートされる App Links では、既存のリンク処理が改善され、アプリ開発者が所有するウェブドメインとアプリを関連付けられるようになりました。 +デベロッパーがこの関連を作成すると、プラットフォームが特定のウェブリンクの処理に使用するデフォルトのアプリを自動的に決めることができ、ユーザーにアプリを選択させる操作をスキップできます。 + + +
+ + ++ ウェブサイトのオーナーは、アプリのリンクを設定するための関連を宣言する必要があります。サイトのオーナーは、ドメインのよく知られた場所で {@code statements.json} という名前の JSON ファイルをホストすることで、アプリとの関係を宣言します。 + + +
+ +http://<domain>:<optional port>/.well-known/statements.json+ +
+ 注: + M Developer Preview の間、JSON ファイルは http プロトコルを介して検証されます。プラットフォームの正式リリースでは、ファイルは暗号化された https プロトコルで検証されます。 + +
+ ++ この JSON ファイルは、このドメイン下の URL のデフォルトのハンドラとして使用する必要のある Android アプリを示します。 +アプリは、次のフィールドに基づいて識別されます。 +
+ +keytool -list -v -keystore my-release-key.keystore+
+ 次のファイル一覧は、 +{@code statements.json} ファイルのコンテンツと形式の例を示しています。 +
+ +
+[{
+ "relation": ["delegate_permission/common.handle_all_urls"],
+ "target": {
+ "namespace": "android_app",
+ "package_name": "<package name>",
+ "sha256_cert_fingerprints": ["6C:EC:C5:0E:34:AE....EB:0C:9B"]
+ }
+}]
+
+
+
++ アプリから、インテント フィルタのデータ エレメントのホスト名で定義されたアプリのリンクを、それぞれのウェブドメインでホストされる {@code statements.json} ファイルに対してプラットフォームが自動的に検証するよう要求できます。 + +アプリリンクの検証を要求するには、次のマニフェスト コード スニペットのように {@code android:autoVerify} + 属性をマニフェスト内の目的のインテント フィルタに追加します。 + +
+ ++<activity ...> + <intent-filter android:autoVerify="true"> + <action android:name="android.intent.action.VIEW" /> + <category android:name="android.intent.category.DEFAULT" /> + <category android:name="android.intent.category.BROWSABLE" /> + <data android:scheme="http" android:host="www.android.com" /> + <data android:scheme="https" android:host="www.android.com" /> + </intent-filter> +</activity> ++ +
+ {@code android:autoVerify} 属性がアプリ マニフェストに存在する場合、プラットフォームはアプリのインストール時にアプリのリンクを検証しようとします。 +プラットフォームがアプリのリンクを正常に検証できない場合、アプリはウェブリンクの処理に適したアプリとして設定されません。 +次回ユーザーがいずれかのリンクを開いたとき、プラットフォームはユーザーに再度ダイアログを表示します。 + + +
+ ++ 注: テスト時に、ユーザーがシステムの設定アプリを使ってサポートされているリンクを開くアプリを明示的に有効にしていると、誤検出が原因で検証が失敗する場合があります。この場合、ダイアログは表示されず、リンクは直接アプリに送られますが、これは検証が成功したからではなく、ユーザーの設定に基づいて動作したからです。 + + + +
+ + ++ ユーザーが希望する方法で URL を処理するように、ユーザー側でアプリのリンク設定を変更できます。アプリのリンクは、システムの設定アプリの [設定] > [アプリ] > [アプリ情報] > [デフォルトでの起動] で確認、管理できます。 + + +
diff --git a/docs/html-intl/intl/ja/preview/index.jd b/docs/html-intl/intl/ja/preview/index.jd new file mode 100644 index 0000000000000..180f5ea1c3ec6 --- /dev/null +++ b/docs/html-intl/intl/ja/preview/index.jd @@ -0,0 +1,67 @@ +page.title=Android M Developer Preview +page.tags="preview", +meta.tags="preview, M preview", androidm +fullpage=true +section.landing=true +header.hide=1 +footer.hide=1 +@jd:body + + + ++Android SDK Preview をインストールする前に、次の利用規約に同意する必要があります。 +以下に記載するとおり、これは、Android SDK のプレビュー バージョンであり、変更される可能性があります。デベロッパーご自身の責任においてご使用ください。Android SDK Preview は安定したリリースではなく、お使いのコンピュータ システム、端末、データに深刻な影響を与える可能性のあるエラーまたは欠陥が含まれている場合があります。 +
+ ++以下は、Android SDK Preview の使用許諾契約です(以下「本契約」)。 +
++ 以下のコードサンプルは、M Developer Preview 用に提供しています。サンプルを Android Studio でダウンロードするには、[File] > [Import Samples] メニュー オプションを選択します。 + +
+ ++ 注: 以下のダウンロード可能なプロジェクトは、Gradle と Android Studio でご利用いただくために提供しています。 + +
+ + ++ Android M では、システムのパーミッションの仕組みが変わります。ユーザーは、パーミッション要求の承認をインストール時ではなく、実行時に求められるようになります。 +このサンプルでは、このパーミッションの要求方法を紹介しています。 + +
+ + + ++ このサンプルでは、アプリで端末の資格情報を認証手段として使用する方法を紹介しています。 +
+ + + ++ このサンプルでは、ユーザーを認証するために登録された指紋をアプリで識別する方法を紹介しています。 + +
+ + + ++ Android M では、アプリの設定の自動バックアップが導入されました。このサンプルでは、設定のバックアップを管理するためにアプリにフィルタリング ルールを追加する方法を紹介しています。 + +
+ + + +
+ このサンプルでは、Camera2 API を使用して、RAW カメラバッファをキャプチャし、DNG ファイルとして保存する方法を紹介しています。
+
+
+ このサンプルでは、その時点でアプリに表示されている通知の数を NotificationManager を使って調べる方法を紹介しています。
+
+
+
M Developer Preview SDK は、Android SDK Manager から入手できます。このドキュメントは、Android SDK Manager の使用方法やプロジェクトの作成方法などの Android アプリ開発についての知識をお持ちの方を対象にしています。 + +Android アプリを初めて開発する場合は、まず Building Your First App のトレーニング レッスンをご覧ください。 + +
+ +Developer Preview は、現在プレビュー段階にある Android Studio 1.3 に最適化されています。 +Preview SDK をご使用になる場合は、Android Studio 1.3 のプレビュー版をインストールすることをお勧めします。 +
+ +注意: Android Studio 1.3 の Canary プレビューは、現在も開発中です。 +メインの開発用マシンを Developer Preview のテストに使用する場合、テスト用に 2 つ目の Android Studio をインストールできます。 + +
+ +Android Studio 1.3 プレビューをインストールするには:
+ +OSX では、Android Studio の [Preferences] ウィンドウで、[Appearance & Behavior] パネルを見つけることができます。 + +
+開発環境に Preview SDK コンポーネントを追加するには:
+ +OSX では、Android Studio の [Preferences] ウィンドウで、[Appearance & Behavior] パネルを見つけることができます。 + +
+上記の手順を完了すると、開発環境でプレビュー コンポーネントを利用できるようになります。 +
+ + ++ プレビュー API を使用するには、プレビュー コンポーネントを使用するために開発プロジェクトを作成または更新する必要があります。 + +
+ + ++ Preview SDK を使用してプロジェクトを作成するときには、Android Studio を使用することをお勧めします。Creating a Project に記載されている手順に従い、プロジェクト ウィザードで [Form Factors] 画面が表示されるまで操作を進めます。 + +次に、以下の手順に従い、Preview SDK 用に構成されたプロジェクトを作成します。 + +
+ +
+ 既存のプロジェクトを使用する場合は、プロジェクト構成を変更してプレビュー API を有効にする必要があります。開発環境で、モジュールの build.gradle ファイルを開き、次のように値を設定します。
+
+
+
compileSdkVersion に 'android-MNC' を設定します。minSdkVersion に 'MNC' を設定します。targetSdkVersion に 'MNC' を設定します。+ Preview SDK でアプリをテストするには、プレビュー版のプラットフォームを使用して構成した端末または仮想端末が必要です。 +互換端末をお持ちの場合、テスト用にプレビュー プラットフォームをインストールできます。 +互換端末をお持ちでない場合は、テスト用に仮想端末を構成できます。 +
+ ++ Nexus 5、Nexus 6、Nexus 9、Android TV をお持ちの場合は、アプリのテスト用にこれらの端末にプレビュー システム イメージをインストールできます。Android Virtual Device Manager ツールを使用すると、Android Studio 内から仮想端末をプレビュー版のプラットフォームでセットアップできます。 + + + +
+ ++ 重要: 端末にプレビュー イメージをインストールすると、端末からすべてのデータが削除されます。そのため、プレビュー イメージをインストールする前にすべてのデータをバックアップする必要があります。 + +
+ ++ Android Virtual Device Manager ツールを使用すると、Android Studio 内からプレビュー版のプラットフォームで仮想端末をセットアップできます。 + +
+ +AVD マネージャーで AVD を作成するには:
+ ++ テスト用の仮想端末の作成についての詳細は、Managing Virtual Devices をご覧ください。 +
diff --git a/docs/html-intl/intl/ja/preview/support.jd b/docs/html-intl/intl/ja/preview/support.jd new file mode 100644 index 0000000000000..2f00a47aa237b --- /dev/null +++ b/docs/html-intl/intl/ja/preview/support.jd @@ -0,0 +1,67 @@ +page.title=サポート +page.image=images/cards/card-support_16-9_2x.png + +@jd:body + ++ M Developer Preview についてのバグの報告やフィードバックがありましたら Issue Tracker でIssue を作成してください。 + + +
+ ++ また、M Developer Preview Google+ コミュニティにご参加いただくと、開発上の問題についての相談やディスカッションを行うことができます。 + + +
+ +
M Developer Preview, Revision 1 (2015 年 5 月)
+
+
+ Android M Developer Preview を利用すると、次期バージョンのプラットフォームでアプリが動作するか確認できます。 +Android M Developer Preview には、API の概要と動作の変更点に記載されているように、アプリに影響を与える可能性のある多くの API と動作の変更が含まれています。 + +Android M Developer Preview でアプリをテストする時には、アプリの良好な使用感を確保するために、システムのいくつかの変更点に特に注意する必要があります。 + + +
+ ++ このガイドでは、アプリで Android M Developer Preview の機能の何をどのようにテストすればよいか説明します。以下の機能は、アプリの動作に大きな影響を与える可能性があるので、優先してテストする必要があります。 + + +
+ ++ テスト用のプレビュー システム イメージを使用した端末または仮想端末のセットアップ方法の詳細については、Preview SDK のセットアップをご覧ください。 + +
+ + ++ パーミッション モデルの変更により、ユーザーがアプリにパーミッションを付与する方法が変わりました。 +アプリでは、インストール時にすべてのパーミッションを要求するのではなく、実行時に個々のパーミッションをユーザーに要求する必要があります。 + +これにより、ユーザーは、各アプリのアクティビティをより細かくコントロールできるようになるだけではなく、アプリが各パーミッションを要求する理由をこれまでよりもよく理解できるようになります。 +ユーザーは、いつでもアプリに個別にパーミッションを付与したり、付与したパーミッションを個別に取り消したりできます。 +この機能は、アプリの動作に大きな影響を与える可能性があり、アプリの一部の機能が動作しなくなったり、限定された機能しか使えなくなったりする可能性もあります。 + + +
+ ++ この変更は、アプリがこの新しいバージョンを対象にしているかどうかにかかわらず、この新しいプラットフォーム上で実行されるすべてのアプリに影響します。 +このプラットフォームはレガシーアプリに限定的な互換動作を提供しますが、公式版のプラットフォームのリリースに合わせてアップデート版のアプリを公開できるように、新しいパーミッション モデルに対応させるためのアプリの移行を今から計画することを強くお勧めします。 + + +
+ + ++ 以下のテストのヒントを活用して、アプリでの新しいパーミッション動作のテストを計画し、実行してください。 + +
+ +adb shell pm list permissions -d -g+
adb shell pm [grant|revoke] <permission.name> ...+
+ このパーミッションの変化は、アプリの構造と設計、ユーザーが体験する使用感とフローに影響を与えます。 +アプリの現在のパーミッション利用の状況を調査し、新しいフローの検討を開始する必要があります。 +このプラットフォームの公式リリースは互換動作を提供しますが、互換動作に頼ることなくアプリのアップデートを計画することを強くお勧めします。 + + +
+ ++ まずアプリが実際に必要とし使用しているパーミッションを特定してから、パーミッションで保護されたサービスを使用している各コードパスを探してください。 +これには、新しいプラットフォーム上でのテストと、コードの解析が必要です。 +テストでは、アプリの {@code targetSdkVersion} をこのプレビュー版に変えて、実行時パーミッションのオプトインに重点的にテストする必要があります。 +詳細については、Preview SDK のセットアップをご覧ください。 + +
+ ++ パーミッションの取り消しと追加のさまざまな組み合わせをテストし、パーミッションに依存するユーザーフローを確認します。 +パーミッションへの依存性が明白または論理的ではない箇所では、依存性を取り除くため、またはパーミッションが必要な理由を明白にするために、フローのリファクタリングまたはコンパートメント化を検討する必要があります。 + + +
+ ++ 実行時パーミッションの動作、テスト、ベスト プラクティスについては、Developer Preview ページのパーミッションをご覧ください。 + + +
+ + ++ 省電力機能である Doze と App Standby により、端末がアイドル状態のときやそのアプリにフォーカスがないときに、アプリが実行できるバックグラウンド処理の量が制限されます。 +システムによってアプリに加えられる可能性のある制限には、ネットワーク アクセスの制限や停止、バックグラウンド タスクの停止、通知の停止、ウェイク リクエストの無視、アラームなどがあります。 + +これらの省電力のための最適化が行われた状態で確実にアプリが適切に動作するように、これらの省電力状態をシミュレートしてアプリをテストする必要があります。 + + +
+ +アプリで Doze をテストするには:
+ ++$ adb shell dumpsys battery unplug +$ adb shell dumpsys deviceidle step +$ adb shell dumpsys deviceidle -h ++ +
アプリで App Standby モードをテストするには:
+ ++$ adb shell am broadcast -a android.os.action.DISCHARGING +$ adb shell am set-idle <packageName> true ++ +
$ adb shell am set-idle <packageName> false+
アプリが、Google Cloud Messaging の登録 ID などの何らかの端末固有の識別子を内部ストレージに保持している場合、アプリの自動バックアップの説明に従って、そのストレージのロケーションを自動バックアップの対象から除外してください。 + + + +
diff --git a/docs/html-intl/intl/ja/preview/testing/performance.jd b/docs/html-intl/intl/ja/preview/testing/performance.jd new file mode 100644 index 0000000000000..1c3ae02290f1c --- /dev/null +++ b/docs/html-intl/intl/ja/preview/testing/performance.jd @@ -0,0 +1,656 @@ +page.title=表示パフォーマンスのテスト +page.image=images/cards/card-test-performance_2x.png +page.keywords=パフォーマンス,fps,ツール + +@jd:body + + ++ ユーザー インターフェース(UI)のパフォーマンスをテストすることで、アプリが機能面での要件に合うだけでなく、ユーザーがアプリをスムーズに操作でき、毎秒安定して 60 フレーム(why 60fps?)で、フレームのドロップや遅延なしで、言い換えればジャンクなしで実行されるようにします。 + + +このドキュメントでは、UI のパフォーマンスを測定することができるツールについて説明し、UI パフォーマンスの測定値をテストで活用する方法を提示します。 + + +
+ + ++ パフォーマンスを改善するには、まずシステムのパフォーマンスを測定し、次にパイプラインのさまざまな箇所で発生している問題を診断し識別する必要があります。 + + +
+ ++ dumpsys は端末上で動作し、システム サービスの状態についての情報をダンプする Android ツールです。 + +gfxinfo コマンドを dumpsys に渡すと、記録中に実行されたアニメーションのフレームに関連するパフォーマンス情報が logcat に出力されます。 + + +
+ ++> adb shell dumpsys gfxinfo <PACKAGE_NAME> ++ +
+ このコマンドは、フレーム タイミング データの複数の異なるバリアントを生成することがあります。 +
+ ++ M Preview では、このコマンドは、プロセスの生存期間全体を通して収集したフレームのデータの集計結果を logcat に出力します。 +次に例を示します。 +
+ ++Stats since: 752958278148ns +Total frames rendered: 82189 +Janky frames: 35335 (42.99%) +90th percentile: 34ms +95th percentile: 42ms +99th percentile: 69ms +Number Missed Vsync: 4706 +Number High input latency: 142 +Number Slow UI thread: 17270 +Number Slow bitmap uploads: 1542 +Number Slow draw: 23342 ++ +
+ これらのデータは、アプリのレンダリングのパフォーマンスと多くのフレームの全体での安定性を大まかに示します。 + +
+ + ++ M Preview では、gfxinfo のための新しいコマンド、framestats が採用され、最新のフレームのフレーム タイミングのきわめて詳細な情報を提供します。そのため、より正確に問題を追跡しデバッグできるようになります。 + + +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> framestats ++ +
+ このコマンドは、アプリによって生成された最新 120 フレームのフレーム タイミング情報を、ナノ秒の精度を持つタイムスタンプを使用して出力します。以下は、adb dumpsys gfxinfo + <PACKAGE_NAME> framestats による未加工の出力例です。 + +
+ ++0,49762224585003,49762241251670,9223372036854775807,0,49762257627204,49762257646058,49762257969704,49762258002100,49762265541631,49762273951162,49762300914808,49762303675954, +0,49762445152142,49762445152142,9223372036854775807,0,49762446678818,49762446705589,49762447268818,49762447388037,49762453551527,49762457134131,49762474889027,49762476150120, +0,49762462118845,49762462118845,9223372036854775807,0,49762462595381,49762462619287,49762462919964,49762462968454,49762476194547,49762476483454,49762480214964,49762480911527, +0,49762479085548,49762479085548,9223372036854775807,0,49762480066370,49762480099339,49762481013089,49762481085850,49762482232152,49762482478350,49762485657620,49762486116683, ++ +
+ この出力の各行が、アプリによって生成される 1 つのフレームを示します。各ラインは、フレームを生成するパイプラインの各段階で費やされた時間を出力する固定された数の列を持ちます。 +次のセクションでは、各列が何を示しているかも含めて、フォーマットを詳細に説明します。 + +
+ + ++ データは CSV 形式で出力されるため、お好みのスプレッドシート ツールに簡単に貼り付けたり、スクリプトで簡単に集計して解析したりできます。 +以下のリストは、出力データ列のフォーマットを説明しています。 +すべてのタイムスタンプはナノ秒単位で出力されます。 +
+ ++ このデータは、別の方法でも使用できます。たとえば、さまざまな遅延バケットでのフレームの処理にかかった時間(FRAME_COMPLETED - INTENDED_VSYNC)の分布を示す下記のヒストグラムは、単純ですが役に立ちます。 + +このグラフを一目見るだけで、大部分のフレームは 16 ミリ秒の限界線(赤色の線)を大きく下回った良好な状態であるけれども、いくつかのフレームが限界線を著しく上回っていることがわかります。 + +ヒストグラムで時間の経過に伴う変化を確認することで、大規模な変化が起きているのか、新しい外れ値が作成されているのか知ることができます。 +また、データに含まれる多くのタイムスタンプに基づいて、入力待ち時間、レイアウトにかかった時間、その他のこれに類する興味を引く指標をグラフにできます。 + + +
+ +
+
+
+
+ [開発者向けオプション] で [GPUレンダリングのプロフィール作成] を [adb shell dumpsys gfxinfo] に設定すると、adb shell dumpsys gfxinfo コマンドにより、最新の 120 フレームのタイミング情報が、いくつかの異なるカテゴリに分かれて、タブ区切りで出力されます。
+
+
+このデータは、描画パイプラインのどの部分の処理が遅いのかを大まかに知るのに役に立ちます。
+
+
+ 上記の framestats と同様に、お好みのスプレッドシート ツールに簡単に貼り付けたり、スクリプトで簡単に集計し解析したりできます。 + +以下のグラフは、アプリによって生成された多くのフレームが時間を費やした箇所の内訳を示しています。 + +
+ +
+
++ このグラフは、gfxinfo を実行し、出力結果をコピーし、スプレッドシート アプリケーションに貼り付け、データを積み上げ棒グラフにしたものです。 + +
+ ++ 各縦棒は、アニメーションの 1 フレームを示し、その高さはそのフレームを処理するのにかかるミリ秒の数を示しています。 +また、縦棒の色分けされた各部分は、レンダリング パイプラインの各段階を示しています。これにより、ボトルネックを生んでいる可能性があるのはアプリケーションのどの箇所か確認できます。 + +レンダリング パイプラインとその最適化方法に関する詳細は、Invalidations, Layouts and Performance のビデオをご覧ください。 + + +
+ + ++ Framestats と簡易フレーム タイミングの両方とも、非常に短いウィンドウを通じて、約 2 秒相当のレンダリングについてデータを収集しています。 +たとえば、収集するデータを特定のアニメーションだけに限定したい場合、このタイミング データ収集用ウィンドウを正確にコントロールするには、すべてのカウンタをリセットし収集したデータを集計します。 + + +
+ ++>adb shell dumpsys gfxinfo <PACKAGE_NAME> reset ++ +
+ これは、ダンプ コマンドとあわせて使用することもでき、フレームの 2 秒未満のウィンドウを続けてキャプチャしながら、通常の流れで収集しリセットできます。 + + +
+ + ++ パフォーマンスの低下を見つけることは、問題を見つけだし、アプリケーションの状態を良好に維持するための最初のステップです。 +ただし、dumpsys は、ただ問題の存在とその相対的な深刻度を明らかにするだけです。 +さらに、パフォーマンスの問題の具体的な原因を突き止め、解決するための適切な方法を見つける必要があります。 +それには、systrace ツールを利用することをお勧めします。 + +
+ + ++ Android のレンダリング パイプラインの仕組み、一般的な問題、それらの問題の修正方法についての詳細は、以下の資料が役に立ちます。 + + +
+ ++ UI パフォーマンスのテスト手法の 1 つに、対象のアプリ上で一連のユーザー操作を人間のテスターに実行してもらい、目視でジャンクを探すかツール主体の手法を使用して長い時間を費やしてジャンクを見つけるかのいずれかの方法をとるというものがあります。 + +ただし、この人の力による方法は危険を伴います。フレームレートの変化に気付く能力は、人によって大きく異なります。また、この方法は、多くの時間が必要で単調で退屈なものであり、ミスも起こりがちです。 + + +
+ ++ より効率的な手法は、自動化された UI テストにより主要なパフォーマンス指標のログを取って解析することです。 +Android M Developer Preview には、アプリケーションのアニメーションに対するジャンクの量と深刻度を簡単に確認することができ、現在のパフォーマンスを確認し将来のパフォーマンス目標を実現するための適切なプロセスを構築するために使用できる新しいログ記録機能が含まれています。 + + + +
+ ++ このドキュメントでは、この新しいログ機能によるデータを使用してパフォーマンス テストを自動化するための手法について紹介します。 + +
+ ++ この手法には、鍵となるアクションが 2 つあります。何をどのようにテストするかということを明確にすることと、自動化されたテスト環境をセットアップし管理することです。 + + +
+ + ++ 自動化されたテストを実行する前に、テストの仕様や必要になる可能性があるものを適切に把握するために、いくつかの大まかな決定をしておくことが重要です。 + +
+ ++ パフォーマンスの低さがユーザーの目に最も多く触れるのは、アニメーションのスムーズさが失われる場合です。 +そのため、どのタイプの UI アクションをテストするか決めるときに、ユーザーが最もよく見る重要なアニメーションまたはユーザーの使用感にとって最も重要なアニメーションにフォーカスすると効果があります。 + +以下にいくつかの一般的なシナリオをご紹介します。 +
+ ++ チームのエンジニア、デザイナー、プロダクト マネージャーと連携して、テスト範囲のこれらの重要な製品アニメーションの優先順位を決めてください。 + +
+ ++ 具体的なパフォーマンス目標を明確にし、その目標に合わせてテストを作成しデータを収集することが重要な場合もあります。 +次に例を示します。 +
+ ++ 上記のすべての場合で、複数のバージョンのアプリケーションでのパフォーマンスを示すヒストリカル トラッキングが必要です。 + +
+ ++ アプリケーションのパフォーマンスは、そのアプリケーションが実行される端末によって異なります。端末によっては、メモリが少なく、GPU のパワーが低く、CPU チップが遅いものもあります。 +つまり、あるハードウェアでスムーズに実行できるアニメーションが別のハードウェアではうまく実行できなかったり、さらに悪い場合は、パイプラインの別の箇所にボトルネックを生んだりすることになります。 + +そのため、このようなハードウェアの違いに対処するために、最新のハイエンド端末と、ローエンド端末、タブレットなどの幅広い端末を選んでテストを実行する必要があります。 + +さまざまな CPU 性能、RAM、画面密度、サイズ等の端末を用意してください。 +ハイエンド端末でうまくいったテストが、ローエンド端末では失敗することがあります。 + +
+ ++ UI Automator や Espresso といったツールが、ユーザーがアプリケーション内を移動する動作を自動処理にするために用意されています。 + +これらは、端末でのユーザーの操作を模倣するシンプルなフレームワークです。 +これらのフレームワークを使用するには、一連のユーザー アクションを実行する独自のスクリプトを作成して、端末上で実行します。 + + +
+ +
+ dumpsys gfxinfo と、これらの自動化されたテストを組み合わせることで、テストを実行できる再現可能なシステムを簡単に作成して、特定の条件でのパフォーマンス情報を測定できます。
+
+
+
+ UI テストを実行する機能と、1 つのテストからデータを集めるためのパイプラインを用意したら、次の重要なステップは、複数の端末で、そのテストを複数回実行でき、開発チームの解析用にパフォーマンス データを集計できるフレームワークを用意することです。 + + + +
+ ++ UI テストのフレームワーク(UI Automator など)は、対象の端末やエミュレータ上で直接実行されます。 +dumpsys gfxinfo によるパフォーマンス情報の収集はホストマシンによって行われますが、コマンドの送信は ADB を通じて行われます。 +これらの別々に分かれている処理の自動化を橋渡しするために、MonkeyRunner フレームワークは開発されました。このフレームワークは、ホストマシンで動作するスクリプティング システムで、接続されている端末にコマンドを発行できるとともに、それらの端末からデータを受け取ることもできます。 + + + +
+ ++ UI パフォーマンス テストの適切な自動化のためのスクリプトを作成することで、少なくとも、以下のタスクを MonkeyRunner を利用して実行することが可能になります。 + +
+ ++ 問題のパターンまたはパフォーマンスの低下を確認したら、次に必要なことは問題の解決方法を見つけその方法を実行することです。 +その自動化されたテスト フレームワークがフレームの正確なタイミングの内訳を保存している場合、最近行われたコードやレイアウトの疑わしい変更を調べたり(パフォーマンスが低下している場合)、手作業での調査に切り替えたときにシステムのどの箇所を解析するか絞り込んだりするのに役立ちます。 + + +手作業での調査は、まず systrace から開始することをお勧めします。systrace は、システムのレンダリング パイプラインのすべての段階、すべてのスレッド、コア、およびテスト担当者が定義したカスタム イベントについての正確なタイミング情報を表示します。 + + +
+ ++ レンダリング パフォーマンスのタイミングを取得し測定することには困難を伴います。 +これらの数値は、その本質として、決定的なものではなく、多くの場合、システムの状態、利用可能なメモリ量、サーマル・スロットリング、その地域に最後に日照があった時間などに応じて変動します。 + +つまり同じテストを 2 度実行した場合、近似するが完全に同じではない、わずかに異なる結果が出ることがあるということです。 + + +
+ ++ この方法で適切にデータを集めプロファイリングするには、同じテストを複数回実行し、結果を平均値または中間値として集計します(以下では、この処理を「バッチ」と記載します)。これにより、テストのパフォーマンスの大まかな数字を、正確なタイミングを必要とすることなく取得できます。 + + + +
+ ++ バッチは、コード変更の合間にも、それらの変更がパフォーマンスにもたらす相対的な影響を確認するために使用できます。 +変更前のバッチの平均フレームレートが変更後のバッチよりも大きい場合、通常、WRT パフォーマンスが全面的に改善したと言えます。 + + +
+ ++ つまり、自動化された UI テストでは、この考え方を取り入れることと、テスト中に発生する可能性のある異常を把握しておくことが必要です。 +たとえば、アプリケーションのパフォーマンスが、そのアプリケーションではなく何らかの端末の問題により突然低下した場合、通常時のタイミングを取得するためにバッチを再度実行した方がよいことがあります。 + + + +
+ ++ それでは、測定値を意味のあるものにするには、何回テストを実行すればよいでしょうか。少なくとも 10 回は必要であり、50 回や 100 回などのように回数が多いほど正確な結果が得られます(もちろん、時間と正確さはトレードオフの関係にあります)。 + + +