Lines Matching refs:permissions

3 page.keywords=permissions, runtime, preview
13 permissions at runtime, instead of install time.</li>
14 <li>Users can revoke permissions at any time from the app Settings
16 <li>Your app needs to check that it has the permissions it needs every
57 The M Developer Preview introduces a new app permissions model which
59 running on the M Preview supports the new permissions model, the user does not have to
60 grant any permissions when they install or upgrade the app. Instead, the app
61 requests permissions as it needs them, and the system shows a dialog to the
66 If an app supports the new permissions model, it can still be installed and
67 run on devices running older versions of Android, using the old permissions
76 With the M Developer Preview, the platform introduces a new app permissions
83 permissions it needs in the manifest, as in earlier Android platforms.
89 <code>CONTACTS</code> permission group contains permissions to read and
96 permissions listed in the manifest that fall under {@link
98 For example, alarm clock and internet permissions fall under {@link
101 how normal permissions are handled, see <a href="#normal">Normal
105 <p>The system may also grant the app signature permissions, as
107 permissions</a>. The user is <em>not</em> prompted to grant any permissions
121 require permissions. Here's a summary of the development practices you should
131 granted that permission. You do not need to check for permissions that
146 <img src="images/app-permissions-screen_2x.png"
147 srcset="images/app-permissions-screen.png 1x, images/app-permissions-screen_2x.png 2x"
156 permissions at any time. If a user turns off an app's permissions, the app
158 needed permissions before performing any restricted actions.
164 <em>must</em> use the new permissions model.
169 implement the new permissions model. Google is updating these apps over
176 permissions without first ensuring the caller has the requisite permissions
183 Related permissions are divided into <em>permission groups</em> to allow
184 users to grant related permissions to an app in a single action. The user
195 <code>SEND_SMS</code> and <code>RECEIVE_SMS</code> permissions, which both
206 System components and signature permissions
211 permissions listed in the manifest that fall under
214 app more permissions:
219 the permissions listed in their manifests.
222 <li>If the app requests permissions in the manifest that fall under {@link
225 those permissions, the system grants the requesting app those permissions on
226 installation. Apps cannot request signature permissions at runtime.</li>
235 the old permissions model even on M Preview devices. When the user installs
236 the app, the system asks the user to grant all permissions listed in the
242 turn off permissions for any app (including legacy apps) from the app's
243 Settings screen. If a user turns off permissions for a legacy app, the system
252 If you install an app using the new permissions model on a device that is not
255 the user to grant all declared permissions at install time.
301 If you use permissions:
340 permissions model. This means that in addition to declaring your needed
341 permissions in the manifest, you must also check to see if you have the
342 permissions at run time, and request the permissions if you do not already
347 Enabling the new permissions model
351 To enable the new M Developer Preview permissions model, set the app's
354 enables all the new permissions features.
372 element, you can add new permissions
373 to updated versions of your app without forcing users to grant permissions
382 The system does not prompt the user to grant any permissions when they install
383 the app, and the app requests permissions as they are needed.
387 Prompting for permissions
391 If your app uses the new M Developer Preview permissions model, the user is
392 not asked to grant all permissions when the app is first launched on a device
393 running the M Preview. Instead, your app requests permissions as they are
400 permissions model. When the user installs the app, they are prompted to grant
401 all the permissions your app requests in its manifest, except for those
402 permissions which are labeled with <code>&lt;uses-permission-sdk-m&gt;</code>.
408 This permissions model is only supported on devices running the M Developer
421 handling permissions</a>.
432 app's permissions at any time. For example, if a user wants to use an app to
598 <h4 id="explain-need">Explain why the app needs permissions</h4>
628 <h4 id="request-permissions">Request permissions if necessary</h4>
632 request the appropriate permission or permissions. The app passes the
633 permission or permissions it wants, and also an integer "request code".
669 in <a href="#explain-need">Explain why the app needs permissions</a>.
672 <h4 id="handle-response">Handle the permissions request response</h4>
675 When an app requests permissions, the system presents a dialog box to the
688 String permissions[], int[] grantResults) {
705 // permissions this app might request
732 handles permissions properly. You cannot assume that your app has any
733 particular permissions when it runs. When the app is first launched, it is
734 likely to have no permissions, and the user can revoke or restore permissions
743 permissions settings you need to try.
752 how your app handles permissions.
756 Install with permissions
762 app and grants all permissions listed in its manifest:
770 Grant and revoke permissions
775 (pm)</a> commands to grant and revoke permissions to an installed app.
807 The new permissions model gives users a smoother experience, and makes it
814 <h3 id="bp-what-you-need">Only ask for permissions you need</h3>
825 of asking for permissions. If your app needs to take pictures with the
838 If you confront the user with a lot of requests for permissions at once, you may
840 for permissions as you need them.
844 In some cases, one or more permissions might be absolutely essential to your
845 app. In that case, it might make sense to ask for all the permissions as soon
857 permissions at the end of the tutorial sequence.
861 Explain why you need permissions
865 The permissions dialog shown by the system when you call {@link
869 wants the permissions before calling {@link
885 can explain what permissions are needed. For example, the photography app's
891 so you still need to check for and request permissions during the app's
895 <h3 id="support-lib">Support library methods for handling permissions</h3>
899 for managing permissions. The support library methods work properly on any
909 The v4 support library provides the following permissions methods:
966 platform methods that require runtime permissions on behalf of a third-party
972 mode the app's permissions are not actually revoked; instead, access to the
974 methods verify app permissions in both normal and legacy modes.
978 The v13 support library provides the following permissions methods:
1008 <h3 id="normal">Normal permissions</h3>
1011 Many permissions are designated as {@link
1015 those permissions. For example, users would reasonably want to know whether
1027 permissions, and users cannot revoke these permissions.
1031 If your app declares that it needs normal permissions, the app does not need
1034 requestPermissions()} for those permissions. Since you declared the
1035 permissions in the manifest, you can be sure your app was granted those
1036 permissions at install time.
1039 <p>Currently, the following permissions are classified as {@link