Working with Permissions Android

The Android operating system has been locked down so that applications have limited capability to adversely affect operations outside their process space. Instead, Android applications run within the bubble of their own virtual machine, with their own Linux user account (and related permissions).

Registering Permissions Your Application Requires

Android applications have no permissions by default. Instead, any permissions for shared resources or privileged access—whether it’s shared data, such as the Contacts database, or access to underlying hardware, such as the built-in camera—must be explicitly registered within the Android manifest file. These permissions are granted when the application is installed.

The following XML excerpt for the preceding Android manifest file defines a ermission using the <uses-permission> tag to gain access to the built-in camera:

A complete list of the permissions can be found in the android.Manifest.permission class. Your application manifest should include only the permissions required to run. The user is informed what permissions each Android application requires at install time.

You might find that, in certain cases, permissions are not enforced (you can operate without the permission). In these cases, it is prudent to request the permission anyway for two reasons. First, the user is informed that the application is performing those sensitive actions, and second, that permission could be enforced in a later SDK version.

Registering Permissions Your Application Grants to Other Applications

Applications can also define their own permissions by using the <permission> tag. Permissions must be described and then applied to specific application components, such as Activities, using the android:permission attribute.

Permissions can be enforced at several points:

  • When starting an Activity or Service
  • When accessing data provided by a content provider
  • At the function call level
  • When sending or receiving broadcasts by an Intent

Permissions can have three primary protection levels: normal, dangerous, and signature. The normal protection level is a good default for fine-grained permission enforcement within the application. The dangerous protection level is used for higherrisk Activities, which might adversely affect the device. Finally, the signature protection level permits any application signed with the same certificate to use that component for controlled application inter operability.

Permissions can be broken down into categories, called permission groups, which describe or warn why specific Activities require permission. For example, permissions might be applied for Activities that expose sensitive user data such as location and personal information (android. permission- group.LOCATION and android. permission group. PERSONAL_ INFO), access underlying hardware (android.permissiongroup. HARDWARE_ CONTROLS), or perform operations that might incur fees to the user (android .permission -group.COST_MONEY). A complete list of permission groups is available within the Manifest .permission _group class.

Enforcing Content Provider Permissions at the Uri Level

You can also enforce fine-grained permissions at the Uri level using the <grant-uri- permissions> tag.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Android Topics