Lines Matching refs:permissions
25 <li><a href="{@docRoot}guide/topics/security/permissions.html">Permissions</a></li>
33 default system and file permissions and avoid difficult decisions about security.</p>
41 security functionality such as cryptography, permissions, and secure
48 <li>User-granted permissions to restrict access to system features and user data.</li>
49 <li>Application-defined permissions to control application data on a per-app basis.</li>
80 offers read and write permissions to other apps and can make
126 </a> for reading and writing, or distinct permissions for reading and writing
127 within the manifest. We recommend that you limit your permissions to those
129 easier to add permissions later to expose new functionality than it is to take
136 Signature permissions do not require user confirmation,
148 that activates the component. The scope of these permissions can be further
178 share resources and data. They do this by declaring the permissions they need for additional
185 <p>We recommend minimizing the number of permissions that your app requests.
186 Not having access to sensitive permissions reduces the risk of
187 inadvertently misusing those permissions, can improve user adoption, and makes
192 any permissions, that is preferable. For example, rather than requesting access
199 <p>In addition to requesting permissions, your application can use the <a
200 href="{@docRoot}guide/topics/manifest/permission-element.html">{@code <permissions>}</a>
204 other than user confirmed permissions where possible because permissions can
207 protection level</a> on permissions for IPC communication between applications
222 <p>Generally, you should strive to define as few permissions as possible while
226 permissions</a> cover many situations. Where appropriate,
227 perform access checks using existing permissions.</p>
232 protection level</a>. Signature permissions are transparent
348 Limiting permissions to read-only or write-only can also reduce the potential
575 appropriate permissions. In those circumstances, you may also consider
608 <p>A service can protect individual IPC calls into it with permissions, by
612 declarative permissions in the manifest, since those are less prone to
626 application manifest, and therefore you cannot apply declarative permissions
627 directly to them. They generally inherit permissions declared in the
661 may want to apply security permissions to receivers using the <code><a
664 prevent applications without appropriate permissions from sending an intent to
685 security permissions as the application APK. The user made a decision to
766 with very limited permissions. This is discussed in more detail in the <a
768 Overview</a> and you should be familiar with application permissions even if