Smartphones with open operating systems are getting popular with the passage of time. Increased exposure of open source smartphones also increased the security risk.  Android is one of the most popular open source operating system for mobile platforms. Android provide a base set of permissions to protect phone resources. But still the security area is underdeveloped. This survey is about the current work done on the Android operating system. Some of the techniques, which can give a positive edge to the security area, are analyzed in the present survey paper. These techniques are basically to provide a better security and to make the Android security mechanism more flexible. As the current security mechanism is too rigid. User does not have any control over the usage of an application. User has only two choices, a) allow all permissions and application will install, b) deny all permissions and installation will fail.


Smartphones are spreading day by day all over the world. However its security is still a big issue. The increased capability and computational power of smartphones increased the interest of developers towards the development of applications for this next generation platforms. Smartphones brings the mobility of traditional cell phones and the power of desktop computers in a single package. Weather updates, shopping, e-ticketing, mobile health and social networking, all on single platform with the additional factor of mobility. Where, the term mobility introduces, so the security and privacy becomes a major issue over there. In this emerging environment, applications are not stand alone. Applications expose its specific features to rest of applications installed on the same platform. And also use features of its neighbour applications. Where, this feature increases the functionality of an application, thereby it also welcomes some security threats. Which can’t be ignores in order to achieve a secure platform.

In the present environment of mobile platforms, Android is quite popular and famous open source and well customizable software package for cell phone devices. Android is a Google operating system for mobile platforms with the basic functionality of system utilities, middleware in form of VM and some core application like browser, dialler, calculator and some others as well.

The present applications are not enough to take full benefit of Android. So, third party developers create applications and launch it to the applications of Android Market. Users are able to download and install the launched applications. This is a sign of high availability of applications for users. But at the same time the user need trust full applications, which do not harm their privacy and security issues. Keeping this issue in mind, every application asks for permissions from the user during the time of installation. User has only two choices, either to grant all the required permissions and the application will be install. And once the permissions are granted, Android does not provide any facility to revoke those permissions, unless the user uninstalls the application.  If user denies the permissions so the application will fail installation. There is no mechanism to allow some permission and deny the rest.

Consider a weather update application that reads user’s location from his phone and provide weather updates on the base of time and location. Location information can be received by two ways. Either by taking location information automatically from GPS or the user himself enters his location where GPS is not available. At the time of installation, this application will ask for location permission. If the user grants the permission to the application so, the application will get install. The drawback is that, the application can collect the user location anytime, even user do not wish so. And if the user does not grant permission to the application during installation, so the application will not be install.

II. Background

Android is a Google operating system launched for mobile platforms. The current architecture of Android is explained below:

2.1 Android Layered Architecture

Android architecture composed of four layers. Application layer on top and the rest of three layers are beneath, application framework, Android runtime and Linux kernel.

Linux kernel is used as an abstraction the hardware and the software.

Android runtime’s is a core component of Dalvik virtual machine. Each Android process runs in a separate instance of Dalvik virtual machine.

Application Framework is a built in toolkit. It provides different packages of services to applications.

2.2    Android Application Structure

Android applications are written in java. But Android does not support execution of java byte code. Dx tool is used by Android for the conversion of java code into Dalvik byte code. Every application is assign with a unique Linux user ID call as UID. This functionality allows Dalvik to run multiple applications in a separate process. Those applications who run in a single process, must share a single UID. Otherwise every application will have a separate UID.

Figure 1: Typical ICC between Activities, Services, Content Providers and Broadcast Receivers

2.3    Android’s   Components

Android composed of basic four components. ICC is used for communication between components.

i) Activity: Activity is a visual screen for interaction of user with the application. Depends upon design, an application may consists of one or more activities

ii)Service: Service do not have a visual interface, it runs in the back ground, like play back music and fetching data from the network.

iii)Broadcast Receiver: Broadcast receiver receive broadcast announcements and response to them according to the situation.

iv)Content Provider: Content provider is a SQLite database, which supports the sharing and accessing of data among applications.

2.4    Android Security Policy Enforcement Mechanism

One of the major components of Android mandatory access control is Reference monitor. Which helps in the inter component communication (ICC).  Each component of an application is assign with some permission labels. These labels are used for interaction with the components of other applications. It is possible that a specific component of an application can interact with the component A of other application but can’t interact with the component B of the same application. This happens because of the permission assigns to each component of each application. Whenever a component wants to initiate ICC, the application checks the label of permissions. If the target component’s label is present in that bundle of permissions, ICC establishment is allowed to continue, otherwise denied.

In Android components interact with other components of same or other application through ICC mechanism based upon intents. Intents is mechanism for message passing, that also contains nature of the action to be performed. Intents can be sent to a specific component or can be broadcast to the Android framework. Android framework then passes it to the suitable component. Action strings help in specifying the intents, actually action strings show the type of action to be performed and then Android system take the decision that which component is suitable to perform the required action.

All the permissions are defined in the AndroidManifest.xml file. It also contains metadata related to security policy enforcement. <Permission>  tag specifies the components which can access it. <Intent-Filters>   specify those intents which can be resolved.

2.5    Protection Levels

Android has four permission levels, on the basis of which an application can be install.

i.  Normal: Normal permissions are granted without asking any permission from user.

ii.Dangerous: Dangerous permissions ask for the approval from the user at the time of installation. User has two choices, either grant all permission or deny all. Denying of permissions will stop installation.

iii.Signature: System grants these permissions if the requesting and granting application share the same certificate.

iv. Signature System:  Same as Signature but use for system applications only.

2.6    Limitations

Android permission lacks the modification of permissions. Android policy is very strict. It walks on all or nothing policy. User should allow all permission to allow any installation.

Android do not provide any runtime investigation for the behaviour of application. Once an application installed, so then it can every activity which it wants.

2.7   Mobile Phone Threats

  • Proof of concept: Keeping the Bluetooth device on without the knowledge of the user is an example of this threat. It drained device batteries.
  • Destructive: Deletion of phone book entries without the knowledge of user is an example of this threat.
  • Premeditated spyware:  This category includes location tracking and remote listening.
  • Direct payoff:  Sending sms without the permission of the user is a threat include in this category.
  • Information scavengers: Checking the address book, passwords and cookies without the permission of the user, lie down in this part.
  • Adware: The malware advertisements on cell phones are included in this category.

III.Extending Android Permission Model and Enforcement with User defined runtime constraints

In this paper, author presents a policy enforcement framework for framework for Android that allows users to grant permissions to applications on the basis of their needs. And also to impose constrains on the usage of resources.

3.1   Problem description

Android contain a suit of built in applications like dialler, browser and address book etc. Using the SDK developer can develop their own applications. Applications require some permission which is mentioned in the AndroidMamifest.xml.  These permissions are used for performing sensitive tasks like sms sending, using camera etc. At the time on installation Android asks user to grant permissions to the application to install. User does not have any other choice rather than granting all permissions to the application. Otherwise the application will not get install. Once the permissions are granted then user can not revoke those permissions until user uninstall the specific application.

Granting of a permission to an application results in providing unrestricted access to the resources. Android existing framework does not provide a security check on the usage of resources. For example, if once sms permission is granted to an application. So, that application can start sending sms any time. There is no way to stop it, unless user does not grant all permissions to it.

Four issues: (1) User must grant all permissions to install any application; (2) No way for restricting the granted permissions to an application; (3) As all permissions are based on install time checks, access to resources cannot be restricted based on dynamic constraints and (4) The only way of revoking permissions are to uninstall the application.

3.2   Android Permission Extension Framework

The existing Android application framework does not define specific entry point for execution of applications. There is no main function of applications, as applications are composed of components. So, components can communicate with components of other applications, if they permit them.

Different methods of ApplicationContext class in Android are used to handle the installation of these components. ApplicationContext acts as an interface for intents handling. With the rising of an intent, ApplicationContext two checks, that whether the permissions are associated with the intent and secondly, it checks whether the calling component has been granted with those permissions which are associated with the intent.

The ApplicationContext implements the IActivityManager interface. It uses the concept of binders and parcels, the Inter Process Communication for Android. Binder is the base class for remotable objects, that implements the IBinder interface and

Parcel acts as generic buffer for inter-process messages which are passed with the help of IBinder.

The ApplicationContext creates a parcel with the help of IActivityManager, and decide that calling application has specific permissions. The ActivityManagerService class receives this parcel and extract the PID, UID and the permissions associated with it. After that, send it to the checkPermission method of ActivityManagerService class. Then these arguments are passed to checkComponentPermission, it perform some checks. If the UID is root or system UID then it grants all permissions. For the rest, it will call PackageManagerService which extracts the package name for the pass UID and validate the permissions. If received permission does not match any of those present in the GrantedPermission so, it throws a security exception.

After checking the present security permissions, control is given to AccessManager. For the purpose a hook is placed in the CheckUidpermission of PackageManagerService. As it is the only entry point for permission checking. It throws the UID and the requested permissions to the AccessManager. AccessManager invokes PolicyResolver, it retrieves attached to the related application and using the PolicyEvaluatinonEngine, evaluate it. The policy includes the condition on the basis of which permissions will be denied or granted. EspressionParser retrieves the attribute of application from attribute repository and performs some sort of operations on these attributes.

3.3    Poly Android Installer

Writing policy is complex job for even system administrators. Android targeted at the consumer market and the end users as well. And users cannot complex usage policies. To end this problem the author created Poly. It is an advanced Android application installer. It provides user to specify constraints on the use of an application.

i) Allow: By default Android allows all permissions. This makes the existing Android installer a subset of Poly.

ii) Deny: This approach opposed the current approach of Android, which is all-or-nothing. As this approach give facility to the user to deny any permission by his owns choice. For example if Tom wants download an application and that specific application require some permission, sending sms is one of among those permissions. But Tom wants the application not to send any sms. So Tom will simply tap on the ‘send SMS’ permission and set it to ‘deny’. And still he may be able to install the application and enjoy the rest of facilities provided by that application.

3.4    Constraint Modification at Runtime

One of the limitations of Android security mechanism is the lack of ability of revoking permissions after an application get installs. Uninstalling of an application is the only way to revoke the permissions. Apex allows the user to specify his fine grained constraints at the time of installation through Poly. Once a user come to know that the application is not harmful, and he wants to assign more permissions to it, so Poly will help him in that. For example if a user install an application and grant it some permission and deny the permission of GPS. After some time he realize that this application not harmful and the user wishes to facilitate him with GPS facility as well. For modification the author created a shortcut to the constraint specification activity of Poly in the settings application of Android. (com.android.settings.ManageApplications class). This allows the user to modify constraints he specified at the time of installation. Even after, the application has been installed. And the same rule follows for denying of permissions after installation.

Figure 2: Android Permission Extension (Apex) Framework

IV. Mitigating Android Software Misuse Before It Happens

In this paper, author proposed a framework; know as Kirin to capture security policy that transcends Android applications. Stakeholders’ define some policy invariants, for sack of security. On the base of which, an application will be certified at the time of installation. Mobile phone operating system provides more open APIs for third party applications. That is why the security framework must not only provide per interface permissions, but it should also be capable of supporting “administrative” policies defined by all stakeholders’.

4.1   Contributions

  • The author reverse engineer Android’s security model and present it formally.
  • Author provides a framework for specifying and enforcing stakeholder security policy.
  • Prolog is used for install time installation. Prolog is a common language for security policy evaluation.
  • Author use the proposed framework to identify insecure application policy configurations within Android. Such applications can affect voice, SMS and location services.

4.2    Kirin

In this paper a model is proposed, which states that before   system install any downloaded application package, it must first ensure the applications satisfy all security requirements. If any requirements fail to met, the installation will be terminates. This model, of installation ensures the cell phone will remain in its original secure state, without based on user made security decisions.

The policy pre-processor extracts policy from the target applications package, and converts it to Prolog facts. After that it merges it with the existing policy knowledge. The result of the merger represents the security state of the system, if the installation were to proceed. The policy engine after that uses the temporary policy state to evaluate invariants. Policy engine extract invariants from system policy, user policy and applications policy. On the basis of these invariants, policy engine take the decisions. It automatically generates compliance proofs for the target application. If all the invariants satisfied, so installation will continue. If any of the invariant fails to satisfy so the installation will abort.

4.3 System invariants

Invariant 1: “An application must have explicit permission to make an outgoing voice call.”Android uses CALL_PHONE and CALL_PRIVILEGED permissions, to protect the API from making outgoing calls. An application holding the call permission can indirectly provides its API access via its components interface. This invariant makes it sure the no indirect access should be allowed.

Figure 3: Enhanced Installation Logic. New packages cannot be installed unless all policy in variants passes

Invariant   2: “An application holding a dangerous permission must have no unprotected components”

Android framework introduces “dangerous permissions”. Which states that user should allow permissions to applications at time of installation. For example, sensitive tasks like making call and sending SMS permissions are mark as dangerous. So that, any application asks from user before using these services.

Invariant   3: “Only system applications can interface with hardware”. Android framework introduces high level java APIs for interfacing with hard ware. For the sack of flexibility, Android let any application to interact with the APIs, but with proper permissions. This invariant insures only system applications have direct access to APIs.

4.4    User Privacy Invariants

Invariant 4: “Only system applications can process outgoing calls.”[2] Android framework let applications to receive notifications of outgoing calls, including the destination number. To keep the issue of privacy in eye, user may wish that only system applications should receive such notifications.

Invariant 5:  “Applications that can perform audio record must not have network access or pass data to

an application that has network access”. It is quite dangerous for security, if an application record voice and send it on internet.

Invariant 6: “An application with access to Wifi or Network state must also declare network access.”

4.5 Application invariants

Invariant 7:  “An application can only receive SMS notifications from trusted system components.”Any application has the ability to broadcast intent. But some intent can only be broadcast by system applications. This gives the surety that only system applications can send SMS.

Invariant 8: “An application can only receive location updates from trusted system components.”  Some applications take decision on the base of location so, only the system applications have the right to send the location notification.

4.6 Limitations

Kirin is limited to obtain data from application package metadata. Kirin does not provide any dynamic security check. Kirin provides only install time security.


The author proposed Kirin security service for Android, which provides a lightweight certification of application at the time on installation. To certify applications based on security configuration requires to clearly specifying the unwanted properties. For the identification of Kirin security rules, the author took help of security requirements engineering. On other hand a security language design has been defined, to implement Kirin security service within the Android framework.

  • Methodology for adding new security requirements and flaws in current Android are defined.
  • Practical method of performing lightweight certification of applications at install time is provided.
  • Mitigation of malware rules are mentioned.

5.1 Kirin Security Rules

Security requirements engineering is based upon three basics. 1) Operation of a system in normal environment, 2) assets are entities that someone places value upon, 3) security requirements are actually constraints on the functionality of system to protect assets.

5.2 Identifying Security Requirements

Existing security requirements engineering techniques are referred in order to identify dangerous application configuration.

Step 1: Identify Assets: Assets are defined from features of Android platform.  In the form of label permissions, assets are already defined by Google.

Figure 4: Sample Kirin security rules to mitigate malware

All components of system applications are assets basically. Android defines the RECORD_AUDIO permission to protect the audio recorder. Microphone is an asset in this example, as microphone records the voice of user. Permission are define by Android for making phone calls, and observation of phone state as well.

Step 2: Identify Functional Requirement: In this step the author studied the interaction of applications with phone and with third party applications. Assets and functional description plays a vital role in security threats. When an incoming call is receives so, the system broadcasts intent to the PHONE_STATE action string. And also notify the registered application with the PhoneStateListner. In the same way action NEW_OUTGOING_CALL action string is also broadcasted.

Step 3: Determine Assets Security Goals and Threats: Confidentiality, integrity and availability considers being high security goals. Determination of appropriate goals and determination of methods that how functional requirements can be abused with respect to the remaining security goals is important. If a voice call is record and sends on internet, it is against the confidentiality.

Step 4: Develop Asset’s Security Requirement: Next security requirement from the threat descriptions. Security requirements are constrains on functional requirements. Which defines who can exercise functionality.  Observations says that, eavesdropper requires a) notification of incoming or outgoing call, b) the ability to record audio and c) access to Internet. So an application must not have these rights at the once.

Step 5: Determine Security Mechanism Limitations: The goal of this step is to determine dangerous configurations at only install time. Author is limited to information available in an application manifest file. An application must not have permission for processing outgoing calls, record audio and internet permission.

5.3 Single Permission Security Rules

Dangerous permissions of Android may be too dangerous in some production environment. The SET_DEBUB_APP permission allows an application to turn the debugging for another application. The corresponding API is hidden in the most recent SDK. Third party does not have access to hidden APIs but it is not a substitute for security. Rule1 ensures third party applications do not have the SET_DEBUG_APP permission.

5.4 Multiple Permission Security Rules

Voice and location eavesdropping malware need permissions to record audio and access location information. But at same time legitimate applications also use these permissions. So a rule is need as multiple permission. Rule 2 and 3 protect against the voice eavesdropper. Rule 4 and 5 protect from location tracker.  Rule 6 protects from incoming malware SMS. Rule 6 and 7 consider malware interaction with messages. As SMS can be used as a path for malware. And malware owner will not let user let know about SMS, therefore content provider will be is modified just after receiving a SMS.  Rule 7 does not stop SMS sending, but increase the probability that user becomes aware of the activity. Rule8 makes use of the duality of permission labels.

Permissions are not always enough to differentiate between malware and legitimate behaviour. Rule 9 provides example of a rule considering both permission and an action string.  This stops a malware from replacing the default voice call dialler application without the awareness of the user.


Android system protects the phone from malicious applications, but with limited infrastructure for applications protection.

Permission assignment policy: Applications have limited ability to control, to which the permissions are granted for accessing their interface.

Figure 5: Policy tree illustrating the example policies required by applications

Interface exposure policy: Androids facility is too rigid for controlling of their interface for other applications.

Interface use policy: Limited means of selecting, at run-time, that which applications interface are accessible.

6.1 Application policies

Permission granting policy is an install time policy. Its subparts have a) Protection level based policy. Normal permissions are granted directly, Dangerous permissions are granted by the wish of user, Signature based permission allows only those permissions to be installed which are signed by the same developer. Signature system is used for system applications only. B) Signature based policy, this is same as signature based, but permissions can be allotted even if application A and B are signed by different developers. c) Applications configuration based policy. This policy keeps on check upon the application version etc.

Interaction policy is runtime policy. Its first three parts are as same as install time policy, but it just checks those permissions at runtime. Additional feature in runtime policy is context based policy. For example if a user do not want to allow GPS permission at specific day or time, or a game should not be start, if the battery is low that 10%.

6.2 Install time policy

Saint install-time policy regulates granting of application on the basis of mentioned permissions. An application define permissions, requested application should hold those permissions in order to communicate with the specific application.

AppPolicy provider takes the decision at time of installation and Saint installer enforce it. AppPolicy maintains record of all install and runtime policies. At the time of installation Android installer retrieves the permissions from the manifest file a) it check the AppPolicy provider for each permission. B) AppPolicy provider consults its policy database, and returns a result by keeping the rule in notice. C) installation will proceed only if the conditions satisfy.

6.2 Runtime Policy Enforcement

For the interaction of softwares components with in Android framework, IPC are used. Caller application sends the IPC and callee receives that IPC. If conditions of both caller and callee satisfy, then IPC continues.

First Saint Madiator retrieves policy file from the application, then send it to Saint AppPolicy provider, the conditions and permissions are checked there. If not satisfied, so the IPC is blocked. Otherwise the IPC is directed towards the current Android permission check and after that communication starts between two applications.

6.3 Administrative Policy

Administrative policy defines the control of user towards policy.  If user is not allowed to change the policy so, he cannot use it in very appropriate way. And if allowed to change then it is a compromise on security. Because user may changes it in wrong way. So author leaves this decision upon operating system. Two flags are defined, SaintOverride flag and Override flag. If both flags are yes, then user can change the policy.

Figure 6: Saint Enforcement –Saint enhances the application installation and interaction of policies.

6.4 Operational Policy

Operational policy consists of three type of conditions.

  • Always satisfied
  • Satisfiable
  • Unsatisfiable

6.5 Saint Architecture

Saint architecture was implemented as modification on Android. For policy enforcement, hooks are placed.

A)    Saint Installer:

It is a modified version of Android installer. Saint installer retrieves all permission from the application package, its version and signature etc. Saint policy is implemented in an XML file with the same name of the package. After parsing the package file, it checks the permissions, if do not satisfy so rejected.

B)    Saint Mediator:

1. Starting an Activity: Saint runtime enforcement consists of four components. Starting new activity, binding components to services, receiving broadcast intents and accessing content provider. For starting an activity, intent is generated, Activity Manager Service open the required program if the name of application is mentioned in the intent. But before starting a security hook will check the policy. If name of application is not mentioned in the intent so the intent will be handed over to Resolver activity. If single match found, so application will be started but a hook is there to check the policy. If multiple applications found for the raised intent, so a menu will be open in front of user, and user will select an application. But before that a hook will check the policy.

2. Receiving intent broadcast: Activity Manager will receive intent. If receiver name is mentioned so, it will receive it but a security hook is there to check the policy. If name of receiver is not mentioned first it will be checked in Dynamic BR list and after that in Static BR list. In both cases hook will be placed to check the policy before starting any activity.

3.Accessomg Content Provider: Any application wants to access content provider, so a hook is placed to check that weather the given application has the permissions to access the content provider .

4. Binding components to services: This allows binding intent to a service. Intent binds to a service either by its name mentioned in the intent or intent containing the action string to which the service is registered.


In this survey paper four approaches are discussed for the security of Android. Kirin and Lightweight approaches are basically install time approaches. If once an application grant some permissions, so there is no security mechanism through which Kirin or Lightweight keep check on the behaviour of application during runtime. Kirin cannot keep on check on dynamic broadcasts.

Light weight cannot directly utilize these existing techniques because the current techniques are structured to supplement system and software development. Lightweight cannot guarantee fixed number of SMS is sent during in specific period of time.

Comparatively to Kirin and Lightweight, Apex approach seems to be more feasible. As its architecture is simple and the property which give edge to Apex is its runtime policy. Which keep on check on the application behaviour at runtime, and on base of policy do not let an application to do something which permission is not grant to it. Still some problems are there, the installer currently incorporates a small number of constraints. For a larger user community, study of user requirements is required. Secondly it can create problems if user unknowingly grants such permissions to an application which can produce harmful results. This problem can be solved by the conjunction of Kirin with Apex, by analysing the constrains and permissions to verify that security rules are not being violated.

Also developer should mention in the manifest file of an application, that why the specific permission is required for the functionality of the application. For example, requesting GPS permission, the developer should mention that why GPS is needed by the application.

Semantic Rich Application Centric Security in Android is an approach for the security of Android. This approach provides a good security mechanism for install time, runt time and application to application interaction as well. In this approach security hooks are placed in every require place of Android framework for the insurance of security.

Courtesy of Kamran Habib Khan & Mir Nauman Tahir