page.title=テストガイド page.image=images/cards/card-build_16x9_2x.png page.keywords=プレビュー リソース,Android M,テスト,パーミッション @jd:body

本書の内容

  1. パーミッションをテストする
  2. Doze と App Standby をテストする
  3. 自動バックアップと端末識別子

Android M Developer Preview を利用すると、次期バージョンのプラットフォームでアプリが動作するか確認できます。 Android M Developer Preview には、API の概要動作の変更点に記載されているように、アプリに影響を与える可能性のある多くの API と動作の変更が含まれています。 Android M Developer Preview でアプリをテストする時には、アプリの良好な使用感を確保するために、システムのいくつかの変更点に特に注意する必要があります。

このガイドでは、アプリで Android M Developer Preview の機能の何をどのようにテストすればよいか説明します。以下の機能は、アプリの動作に大きな影響を与える可能性があるので、優先してテストする必要があります。

テスト用のプレビュー システム イメージを使用した端末または仮想端末のセットアップ方法の詳細については、Preview SDK のセットアップをご覧ください。

パーミッションをテストする

パーミッション モデルの変更により、ユーザーがアプリにパーミッションを付与する方法が変わりました。 アプリでは、インストール時にすべてのパーミッションを要求するのではなく、実行時に個々のパーミッションをユーザーに要求する必要があります。 これにより、ユーザーは、各アプリのアクティビティをより細かくコントロールできるようになるだけではなく、アプリが各パーミッションを要求する理由をこれまでよりもよく理解できるようになります。 ユーザーは、いつでもアプリに個別にパーミッションを付与したり、付与したパーミッションを個別に取り消したりできます。 この機能は、アプリの動作に大きな影響を与える可能性があり、アプリの一部の機能が動作しなくなったり、限定された機能しか使えなくなったりする可能性もあります。

この変更は、アプリがこの新しいバージョンを対象にしているかどうかにかかわらず、この新しいプラットフォーム上で実行されるすべてのアプリに影響します。 このプラットフォームはレガシーアプリに限定的な互換動作を提供しますが、公式版のプラットフォームのリリースに合わせてアップデート版のアプリを公開できるように、新しいパーミッション モデルに対応させるためのアプリの移行を今から計画することを強くお勧めします。

テストのヒント

以下のテストのヒントを活用して、アプリでの新しいパーミッション動作のテストを計画し、実行してください。

テスト方針

このパーミッションの変化は、アプリの構造と設計、ユーザーが体験する使用感とフローに影響を与えます。 アプリの現在のパーミッション利用の状況を調査し、新しいフローの検討を開始する必要があります。 このプラットフォームの公式リリースは互換動作を提供しますが、互換動作に頼ることなくアプリのアップデートを計画することを強くお勧めします。

まずアプリが実際に必要とし使用しているパーミッションを特定してから、パーミッションで保護されたサービスを使用している各コードパスを探してください。 これには、新しいプラットフォーム上でのテストと、コードの解析が必要です。 テストでは、アプリの {@code targetSdkVersion} をこのプレビュー版に変えて、実行時パーミッションのオプトインに重点的にテストする必要があります。 詳細については、Preview SDK のセットアップをご覧ください。

パーミッションの取り消しと追加のさまざまな組み合わせをテストし、パーミッションに依存するユーザーフローを確認します。 パーミッションへの依存性が明白または論理的ではない箇所では、依存性を取り除くため、またはパーミッションが必要な理由を明白にするために、フローのリファクタリングまたはコンパートメント化を検討する必要があります。

実行時パーミッションの動作、テスト、ベスト プラクティスについては、Developer Preview ページのパーミッションをご覧ください。

Doze と App Standby をテストする

省電力機能である Doze と App Standby により、端末がアイドル状態のときやそのアプリにフォーカスがないときに、アプリが実行できるバックグラウンド処理の量が制限されます。 システムによってアプリに加えられる可能性のある制限には、ネットワーク アクセスの制限や停止、バックグラウンド タスクの停止、通知の停止、ウェイク リクエストの無視、アラームなどがあります。 これらの省電力のための最適化が行われた状態で確実にアプリが適切に動作するように、これらの省電力状態をシミュレートしてアプリをテストする必要があります。

アプリで Doze をテストする

アプリで Doze をテストするには:

  1. M Preview のシステム イメージを使用して、ハードウェア端末または仮想端末を構成します。
  2. 端末を開発マシンに接続し、アプリをインストールします。
  3. アプリを実行し、アクティブ状態のままにします。
  4. 以下のコマンドを実行して、端末の Doze モードへの移行をシミュレートします。
    $ adb shell dumpsys battery unplug
    $ adb shell dumpsys deviceidle step
    $ adb shell dumpsys deviceidle -h
    
  5. 端末がアクティブ状態に戻ったときのアプリの動作を観察します。端末が Doze モードから抜けるときに、アプリがスムーズに復帰することを確認します。

アプリで App Standby をテストする

アプリで App Standby モードをテストするには:

  1. M Preview のシステム イメージを使用して、ハードウェア端末または仮想端末を構成します。
  2. 端末を開発マシンに接続し、アプリをインストールします。
  3. アプリを実行し、アクティブ状態のままにします。
  4. 以下のコマンドを実行して、アプリのスタンバイ モードへの移行をシミュレートします。
    $ adb shell am broadcast -a android.os.action.DISCHARGING
    $ adb shell am set-idle <packageName> true
    
  5. 以下のコマンドを使用して、アプリのウェイクをシミュレートします。
    $ adb shell am set-idle <packageName> false
  6. アプリがウェイク状態に戻ったときのアプリの動作を観察します。アプリがスタンバイ モードからスムーズに復帰することを確認します。 特に、アプリの通知とバックグラウンド ジョブが想定通りの動作を続けているかを確認する必要があります。

アプリの自動バックアップと端末固有識別子

アプリが、Google Cloud Messaging の登録 ID などの何らかの端末固有の識別子を内部ストレージに保持している場合、アプリの自動バックアップの説明に従って、そのストレージのロケーションを自動バックアップの対象から除外してください。