1 page.title=Testing Guide 2 page.image=images/cards/card-build_16x9_2x.png 3 page.keywords=previewresources,androidm,testing,permissions 4 5 @jd:body 6 7 <div id="qv-wrapper"> 8 <div id="qv"> 9 <h2>In this document</h2> 10 <ol> 11 <li><a href="#runtime-permissions">Testing Permissions</a></li> 12 <li><a href="#doze-standby">Testing Doze and App Standby</a></li> 13 <li><a href="#ids">Auto Backup and Device Identifiers</a></li> 14 </ol> 15 </div> 16 </div> 17 18 <p> 19 The Android M Developer Preview gives you an opportunity to ensure your apps work with the next 20 version of the platform. This preview includes a number of APIs and behavior changes that can 21 impact your app, as described in the <a href="{@docRoot}preview/api-overview.html">API 22 Overview</a> and <a href="{@docRoot}preview/behavior-changes.html">Behavior Changes</a>. In testing 23 your app with the preview, there are some specific system changes that you should focus on to 24 ensure that users have a good experience. 25 </p> 26 27 <p> 28 This guide describes the what and how to test preview features with your app. You should 29 prioritize testing of these specific preview features, due to their high potential impact on your 30 app's behavior: 31 </p> 32 33 <ul> 34 <li><a href="#runtime-permissions">Permissions</a> 35 </li> 36 <li><a href="#doze-standby">Doze and App Standby</a> 37 </li> 38 <li><a href="#ids">Auto Backup and Device Identifiers</a></li> 39 </ul> 40 41 <p> 42 For more information about how to set up devices or virtual devices with a preview system image 43 for testing, see <a href="{@docRoot}preview/setup-sdk.html">Set up the Preview SDK</a>. 44 </p> 45 46 47 <h2 id="runtime-permissions">Testing Permissions</h2> 48 49 <p> 50 The new <a href="{@docRoot}preview/features/runtime-permissions.html">Permissions</a> model 51 changes the way that permissions are allocated to your app by the user. Instead of granting all 52 permissions during the install procedure, your app must ask the user for individual permissions 53 at runtime. For users this behavior provides more granular control over each apps activities, as 54 well as better context for understanding why the app is requesting a specific permission. Users 55 can grant or revoke the permissions granted to an app individually at any time. This feature of 56 the preview is most likely to have an impact on your app's behavior and may prevent some of your 57 app features from working, or they may work in a degraded state. 58 </p> 59 60 <p class="caution"> 61 This change affects all apps running on the new platform, even those not targeting the new 62 platform version. The platform provides a limited compatibility behavior for legacy apps, but you 63 should begin planning your apps migration to the new permissions model now, with a goal of 64 publishing an updated version of your app at the official platform launch. 65 </p> 66 67 68 <h3 id="permission-test-tips">Test tips</h3> 69 70 <p> 71 Use the following test tips to help you plan and execute testing of your app with the new 72 permissions behavior. 73 </p> 74 75 <ul> 76 <li>Identify your apps current permissions and the related code paths.</li> 77 <li>Test user flows across permission-protected services and data.</li> 78 <li>Test with various combinations of granted/revoked permission.</li> 79 <li>Use the {@code adb} tool to manage permssions from the command line: 80 <ul> 81 <li>List permissions and status by group: 82 <pre>adb shell pm list permissions -d -g</pre> 83 </li> 84 <li>Grant or revoke one or more permissions using the following syntax:<br> 85 <pre>adb shell pm [grant|revoke] <permission.name> ...</pre> 86 </li> 87 </ul> 88 </li> 89 <li>Analyze your app for services that use permissions.</li> 90 </ul> 91 92 <h3 id="permission-test-strategy">Test strategy</h3> 93 94 <p> 95 The permissions change affects the structure and design of your app, as well as 96 the user experience and flows you provide to users. You should assess your apps current 97 permissions use and start planning for the new flows you want to offer. The official release of 98 the platform provides compatibility behavior, but you should plan on updating your app and not 99 rely on these behaviors. 100 </p> 101 102 <p> 103 Identify the permissions that your app actually needs and uses, and then find the various code 104 paths that use the permission-protected services. You can do this through a combination of 105 testing on the new platform and code analysis. In testing, you should focus on opting in to 106 runtime permissions by changing the apps {@code targetSdkVersion} to the preview version. For 107 more information, see <a href="{@docRoot}preview/setup-sdk.html#">Set up the Preview SDK</a>. 108 </p> 109 110 <p> 111 Test with various combinations of permissions revoked and added, to highlight the user flows that 112 depend on permissions. Where a dependency is not obvious or logical you should consider 113 refactoring or compartmentalizing that flow to eliminate the dependency or make it clear why the 114 permission is needed. 115 </p> 116 117 <p> 118 For more information on the behavior of runtime permissions, testing, and best practices, see the 119 <a href="{@docRoot}preview/features/runtime-permissions.html">Permissions</a> developer 120 preview page. 121 </p> 122 123 124 <h2 id="doze-standby">Testing Doze and App Standby</h2> 125 126 <p> 127 The power saving features of Doze and App Standby limit the amount of background processing that 128 your app can perform when a device is in an idle state or while your app is not in focus. The 129 restrictions the system may impose on apps include limited or no network access, 130 suspended background tasks, suspended Notifications, ignored wake requests, and alarms. To ensure 131 that your app behaves properly with these power saving optimizations, you should test your app by 132 simulating these low power states. 133 </p> 134 135 <h4 id="doze">Testing your app with Doze</h4> 136 137 <p>To test Doze with your app:</p> 138 139 <ol> 140 <li>Configure a hardware device or virtual device with a M Preview system image.</li> 141 <li>Connect the device to your development machine and install your app.</li> 142 <li>Run your app and leave it active.</li> 143 <li>Simulate the device going into Doze mode by running the following commands: 144 145 <pre> 146 $ adb shell dumpsys battery unplug 147 $ adb shell dumpsys deviceidle step 148 $ adb shell dumpsys deviceidle -h 149 </pre> 150 151 </li> 152 <li>Observe the behavior of your app when the device is re-activated. Make sure it 153 recovers gracefully when the device exits Doze.</li> 154 </ol> 155 156 157 <h4 id="standby">Testing apps with App Standby</h4> 158 159 <p>To test the App Standby mode with your app:</p> 160 161 <ol> 162 <li>Configure a hardware device or virtual device with a M Preview system image.</li> 163 <li>Connect the device to your development machine and install your app.</li> 164 <li>Run your app and leave it active.</li> 165 <li>Simulate the app going into standby mode by running the following commands: 166 167 <pre> 168 $ adb shell am broadcast -a android.os.action.DISCHARGING 169 $ adb shell am set-idle <packageName> true 170 </pre> 171 172 </li> 173 <li>Simulate waking your app using the following command: 174 <pre>$ adb shell am set-idle <packageName> false</pre> 175 </li> 176 <li>Observe the behavior of your app when it is woken. Make sure it recovers gracefully 177 from standby mode. In particular, you should check if your app's Notifications and background 178 jobs continue to function as expected.</li> 179 </ol> 180 181 <h2 id="ids">Auto Backup for Apps and Device-Specific Identifiers</h2> 182 183 <p>If your app is persisting any device-specific identifiers, such as Google 184 Cloud Messaging registration ID, in internal storage, 185 make sure to follow best practices to exclude the storage 186 location from auto-backup, as described in <a href="{@docRoot}preview/backup/index.html">Auto 187 Backup for Apps</a>. </p> 188
