diff --git a/docs/html/preview/testing/guide.jd b/docs/html/preview/testing/guide.jd new file mode 100644 index 0000000000000..1879268757627 --- /dev/null +++ b/docs/html/preview/testing/guide.jd @@ -0,0 +1,176 @@ +page.title=Testing Guide +page.image=images/cards/card-set-up_16-9_2x.png + +@jd:body + +
+
+

In this document

+
    +
  1. Testing Runtime Permissions
    2. +
  2. Testing Doze and App Standby
    3. +
+
+
+ +

+ The Android M Developer Preview gives you an opportunity to ensure your apps work with the next + version of the platform. This preview includes a number of APIs and behavior changes that can + impact your app, as described in the API + Overview and Behavior Changes. In testing + your app with the preview, there are some specific system changes that you should focus on to + ensure that users have a good experience. +

+ +

+ This guide describes the what and how to test preview features with your app. You should + prioritize testing of these specific preview features, due to their high potential impact on your + app's behavior: +

+ + + +

+ For more information about how to set up devices or virtual devices with a preview system image + for testing, see Set up the Preview SDK. +

+ + +

Testing Runtime Permissions

+ +

+ The Runtime Permissions feature + changes the way that permissions are allocated to your app by the user. Instead of granting all + permissions during the install procedure, your app must ask the user for individual permissions + at runtime. For users this behavior provides more granular control over each app’s activities, as + well as better context for understanding why the app is requesting a specific permission. Users + can grant or revoke the permissions granted to an app individually at any time. This feature of + the preview is most likely to have an impact on your app's behavior and may prevent some of your + app features from working, or they may work in a degraded state. +

+ +

+ This change that affects all apps running on the new platform, even those not targeting the new + platform version. The platform provides a limited compatibility behavior for legacy apps, but you + should begin planning your app’s migration to the new permissions model now, with a goal of + publishing an updated version of your app at the official platform launch. +

+ + +

Test tips

+ +

+ Use the following test tips to help you plan and execute testing of your app with the new + permissions behavior. +

+ + + +

Test strategy

+ +

+ The Runtime Permissions change affects the structure and design of your app, as well as + the user experience and flows you provide to users. You should assess your app’s current + permissions use and start planning for the new flows you want to offer. The official release of + the platform provides compatibility behavior, but you should plan on updating your app and not + rely on these behaviors. +

+ +

+ Identify the permissions that your app actually needs and uses, and then find the various code + paths that use the permission-protected services. You can do this through a combination of + testing on the new platform and code analysis. In testing, you should focus on opting in to + runtime permissions by changing the app’s {@code targetSdkVersion} to the preview version. For + more information, see Set up the Preview SDK. +

+ +

+ Test with various combinations of permissions revoked and added, to highlight the user flows that + depend on permissions. Where a dependency is not obvious or logical you should consider + refactoring or compartmentalizing that flow to eliminate the dependency or make it clear why the + permission is needed. +

+ +

+ For more information on the behavior of Runtime Permissions, testing, and best practices, see the + Runtime Permissions developer + preview page. +

+ + +

Testing Doze and App Standby

+ +

+ The power saving features of Doze and App Standby limits the amount of background processing that + your app can perform when a device is in an idle state or while your app is not in focus. The + restrictions the system may impose on apps include limited or no network access, + suspended background tasks, suspended Notifications, ignored wake requests, and alarms. To ensure + that your app behaves properly with these power saving optimizations, you should test your app by + simulating these low power states. +

+ +

Testing your app with Doze

+ +

To test Doze with your app:

+ +
    +
  1. Configure a hardware device or virtual device with a M Preview system image.
    2. +
  2. Connect the device to your development machine and install your app.
    3. +
  3. Run your app and leave it active.
    4. +
  4. Simulate the device going into Doze mode by running the following commands: + +
    +$ adb shell dumpsys battery unplug
+$ adb shell dumpsys deviceidle step
+$ adb shell dumpsys deviceidle -h
+
    + +
    5. +
  5. Observe the behavior of your app when the device is re-activated. Make sure it + recovers gracefully when the device exits Doze.
    6. +
+ + +

Testing apps with App Standby

+ +

To test the App Standby mode with your app:

+ +
    +
  1. Configure a hardware device or virtual device with a M Preview system image.
    2. +
  2. Connect the device to your development machine and install your app.
    3. +
  3. Run your app and leave it active.
    4. +
  4. Simulate the app going into standby mode by running the following commands: + +
    +$ adb shell am broadcast -a android.os.action.DISCHARGING
+$ adb shell am set-idle <packageName> true
+
    + +
    5. +
  5. Simulate waking your app using the following command: + 
    $ adb shell am set-idle <packageName> false
    +
    6. +
  6. Observe the behavior of your app when it is woken. Make sure it recovers gracefully + from standby mode. In particular, you should check if your app's Notifications and background + jobs continue to function as expected.
    7. +