Explain the Android security model

     

The Android security model is primarily based on a sandbox and permission mechanism. Each 
application is running in a specific Dalvik virtual machine with a unique user ID assigned to it, 
which means the application code runs in isolation from the code of all other applications. 
Therefore, one application has not granted access to other applications’ files.
Android application has been signed with a certificate with a private key Know the owner of 
the application is unique. This allows the author of the application will be identified if needed. 
When an application is installed in the phone is assigned a user ID, thus avoiding it from 
affecting it other applications by creating a sandbox for it. This user ID is permanent on which 
devices and applications with the same user ID are allowed to run in a single process. This is a 
way to ensure that a malicious application has Cannot access / compromise the data of the 
genuine application. It is mandatory for an application to list all the resources it will Access 
during installation. Terms are required of an application, in the installation process should be 
user-based or interactive Check with the signature of the application.
Declaring and Using Permissions
The purpose of a permission is to protect the privacy of an Android user. Android apps must 
request permission to access sensitive user data (such as contacts and SMS), as well as certain 
system features (such as camera and internet). Depending on the feature, the system might grant 
the permission automatically or might prompt the user to approve the request. 
Permissions are divided into several protection levels. The protection level affects whether 
runtime permission requests are required. There are three protection levels that affect third￾party apps: normal, signature, and dangerous permissions.
Normal permissions: Normal permissions cover areas where your app needs to access data or 
resources outside the app’s sandbox, but where there’s very little risk to the user’s privacy or   __________________________________________________________________________________________
Page No: 5 | 41
the operation of other apps. For example, permission to set the time zone is a normal 
permission. If an app declares in its manifest that it needs a normal permission, the system 
automatically grants the app that permission at install time. The system doesn’t prompt the user 
to grant normal permissions, and users cannot revoke these permissions.
Signature permissions: The system grants these app permissions at install time, but only when 
the app that attempts to use permission is signed by the same certificate as the app that defines 
the permission. 
Dangerous permissions: Dangerous permissions cover areas where the app wants data or 
resources that involve the user’s private information, or could potentially affect the user’s 
stored data or the operation of other apps. For example, the ability to read the user’s contacts is 
a dangerous permission. If an app declares that it needs a dangerous permission, the user must
explicitly grant the permission to the app. Until the user approves the permission, your app 
cannot provide functionality that depends on that permission. To use a dangerous permission, 
your app must prompt the user to grant permission at runtime. For more details about how the 
user is prompted, see Request prompt for dangerous permission.