Android Base Security & SandBox

List of Common Permissions Permissions Interactive Requested Video Examples Download Security Intents Example

Platform Security Architecture

Android seeks to be the safest and most usable operating system for mobile platforms by re-purposing the traditional security controls of the operating system to protect the application and user data system resources (including network)

Also provide isolation of system applications, other applications and the user to achieve these goals, Android offers these key security features: Robust OS level security through the Linux kernel Mandatory application security box (sandbos) for all applications Secure interprocess communication Signature of the application Application-defined and user-granted permissions.

Safety is a wide concept that encompasses and affects different layers and parts. We have security at the level of architecture of the operating system, level of application and level of the set of services of the ecosystem of Google as they can be Google play with its revisions, the OS updates that improve the security of the device and SafetyNet that the correct functioning of the device (E.g. not rooted or malicious apps) and other services such as Android Device Manager that help us locate lost terminals.

Of all the above we will focus on those that affect the development of our app, the SandBox that is the area of ??security that runs our software and with which we interact with end users to give different permissions and access, such as For example to the camera, contacts or external storage system.

App SandBox Security

The goal of sandboxing is to improve security by isolating an application to prevent malware, intruders, system resources or other external applications from interacting with the protected application.

The term sandboxing comes from the idea of ??a child’s sandbox, in which sand and toys are kept inside a small container or walled area. Developers who do not want an application to be affected by external influences can either surround security policies around an application (see the application package) or isolate each application in its own virtual machine (VM), an approach known as micro- Virtualization.

The sandbox have two principal responsabilites, first system isolates the applications from each other, so that they can dialogue, they need to make requests (intents) that we can protect. And second is access control based on read-write-execute permissions. 

The Linux kernel manages this process. Each virtual machine and, as a consequence, each application represents a single process of the Linux kernel.

Permission Request

We recommend minimizing the amount of permissions your app requests.

Lack of access to sensitive permissions reduces the risk of using those permissions inadvertently and erroneously, can improve user capture and makes your app less vulnerable to attackers.

In general, if you do not require permission for your app to work, do not just apply. You can design your application so that it does not require permissions, something that is recommended.

For example, instead of requesting access to device information to create a unique identifier, it creates a GUID for your application (see User Data Handling).

Alternatively, instead of using external storage (which requires permission) you can save data to internal storage.

How To Declare System Permissions

As we said each Android app runs in a test zone with limited access. If an app needs to use resources or information external to its own test zone, it must request the corresponding permission. To state that your app needs a permit, you must mention it in the app manifest.

We recommend that you follow these basic principles when working with Android permissions:

1: Use only the permissions needed for your app to work.

 2: Pay attention to the permissions requested by the libraries.

 3: Be transparent. When you apply for a permit, be clear about the information you access and the reason why you do so that users can make informed decisions. 

4: Make access to the system explicit. No showing messages that can alter to user about security terms, delegate this to the Android System.

Permissions Interactive Requested & Rationale

Starting with Android 6.0 (API level 23), users grant permissions to apps while they are running, not when they install the app. This approach simplifies the app install process, since the user does not need to grant permissions when installing or updating the app. It also gives the user greater control over the functionality of the app;

For example, a user might choose to give a camera app access to this, but not to the location of the device.

The user can revoke the permissions at any time from the configuration screen of the app. In this case when return to app zone where the permissions are needed will be re-requested. If we go back again to the settings of the application and access its permissions we will watch that they have been activated and disabled/enabled manually.

There are three stages one for the permission checking, whether or not it has been authorized checkSelfPermission, and another to know if it is necessary to show the user or not a justification of why we want use the permission shouldShowRequestPermissionRationale. The last step is onRequestPermissionsResult place where check if the user granted the permision and the execute the functionality.

Checking shouldShowRequestPermissionRationale let us indicate whether or not we should show UI message with rationale for requesting a permission. Attention shouldShowRequestPermissionRationale  only return true when a dangerous permission was denied at the first time and the user is trying again to get access to this functionality.

Calm, We’ll see clearly all working together in the next video examples section with code.

We will not stop repeating it until we learn it.

System permissions are divided into two categories, normal and risky:

Normal permissions do not endanger the user’s privacy directly. If your app has normal permission on your manifest, the system automatically grants the permission.

Risky permissions can allow the app to access sensitive user information in this case the user must explicitly authorize your app.

The following are general permissions:


Here we can see captures about how are the permissions requested and where is located the options for to be disabled or enabled by the user.  This is in settings > apps > “select app” > permissions. Great!


List of permissions most commonly used

Permissions Summary


































android.permission.READ_EXTERNAL_STORAGE android.permission.WRITE_EXTERNAL_STORAGE



Full Examples

In the examples we are going to give permissions at run-time to be able to make a phone call and read calendar from our app. Then the simple example code for call phone starts checking on the request of the permissions, in case it is not granted there is a popup shows by Android System about that we have to accept, if it was already verified by the user, then attempt of the Called directly the functionalty. When the request appears to the user the control is taken by Android System, when it accepts, the listener receiving the event is the onRequestPermissionsResult, there we will check that we are dealing with the permission in question and in case of authorization by the user we will execute the call. Great! Let’s look at the code:


In the Use Case of Read the Calendar it is a bit more complicated. As it is a dangerous permit, we have added an additional form with the idea that in case of deny, we can add a dialogue to inform the user about what he is going to do and the reasons,  we archive this  using shouldShowRequestPermissionRationale: this method return a Boolean indicating whether or not we should show UI message with rationale for requesting a permission.

Attention shouldShowRequestPermissionRationale  only return true when a dangerous permission was denied at the first time and the user is trying again to get access to this functionality.


security rationale dialog for previous denied permission.

security rationale dialog for previous denied permission.

The justification explaining the reason for requesting the permission, resolve this with a dialog, let’s see:


Finally the grant permission call back where verify that was granted by the user and in this case call to the functionality.


 We are going to see this in the next top video examples.


1- Video Execution Of Permissions Requested Without Setting On Manifest

In the current example we execute an attempt to make a call (android.permission.CALL_PHONE) telephone, in the manifest file we have configured the use, but in the first execution we have commented the permission. Then in a debugging session a   state of granting permission (-1) is returned, which means that we can not request a permit from those considered dangerous without having configured it in the manifest.



2- Video Execution Of Permissions Requested With Setting On Manifest

In this case we active the permmission android.permission.CALL_PHONE in the manifest file and watch as the call is realize pay attention to te return code is correct in the handler.


Let’s see:


3- Video Execution Of Disabled Permissions In Settings

In this case we are disabled the permission android.permission.CALL_PHONE in the settings  and watch as the call is requesting again the grant to user.

4- Video Execution Of Rationale Show Request Permission

In this example We are working about how showing a message to user for advice that a previous requested permission was denied and it’s necessary for the functionality requested.

The permission READ_CALENDAR is guess to user, it mus be declared in AndroidManifest file, the user wan’t grant this in the first time. Then when retry a message show thanks

Remember that in this case we are using shouldShowRequestPermissionRationale this method return a Boolean indicating whether or not we should show UI with rationale for requesting a permission. Great!.



Android works like sandbox to protect the app from external security access.

In the Manifest.xml we are defining the permissions necesary for the app, system permissions are divided into two categories, normal and risky.

Use the minimal permissions y only the necessary for your app.

Remember use the three steps based on checkSelfPermission, shouldShowRequestPermissionRationale and onRequestPermissionsResult. ShouldShowRequestPermissionRationale indicate whether or not we should show UI message with rationale for requesting a permission. Attention shouldShowRequestPermissionRationale  only return true when a dangerous permission was denied at the first previous time and the user is trying again to get access to this functionality.


Good job, let’s move on to the next chapter, you get along very well.

Download Full Example Security Intents

Security At IntentParameters

All Downloads

git clone

Info Links

Portions of this page are reproduced from work created and shared by the Android Open Source Project and used according to terms described in the Creative Commons 2.5 Attribution License.



One comment

  1. Este capítulo de seguridad me ha parecido estupendo y de gran calidad.
    Gracias keikis ORG

Leave a Reply

Social media & sharing icons powered by UltimatelySocial