Android Permissions Demystified
Adrienne Porter Felt, Erika Chin, Steve Hanna, Dawn Song, David Wagner
{ apf, emc, sch, dawnsong, daw }@ cs.berkeley.edu
University of California, Berkeley
ABSTRACT
Android provides third-party applications with an extensive
API that includes access to phone hardware, settings, and
user data. Access to privacy- and security-relevant parts of
the API is controlled with an install-time application permis-
sion system. We study Android applications to determine
whether Android developers follow least privilege with their
permission requests. We built Stowaway, a tool that detects
overprivilege in compiled Android applications. Stowaway
determines the set of API calls that an application uses and
then maps those API calls to permissions. We used auto-
mated testing tools on the Android API in order to build
the permission map that is necessary for detecting overpriv-
ilege. We apply Stowaway to a set of 940 applications and
find that about one-third are overprivileged. We investigate
the causes of overprivilege and find evidence that developers
are trying to follow least privilege but sometimes fail due to
insufficient API documentation.
Categories and Subject Descriptors
D.2.5 [Software Engineering]: Testing and Debugging;
D.4.6 [Operating Systems]: Security and Protection—ac-
cess controls
General Terms
Security
Keywords
Android, permissions, least privilege
1. INTRODUCTION
Android’s unrestricted application market and open source
have made it a popular platform for third-party applications.
As of 2011, the Android Market includes more applications
than the Apple App Store [10]. Android supports third-
party development with an extensive API that provides ap-
plications with access to phone hardware (e.g., the camera),
WiFi and cellular networks, user data (e.g., received text
messages), and phone settings.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
CCS’11, October 17–21, 2011, Chicago, Illinois, USA.
Access to privacy- and security-relevant parts of Android’s
rich API is controlled by an install-time application permis-
sion system. Each application must declare upfront what
permissions it requires, and the user is notified during in-
stallation about what permissions it will receive. If a user
does not want to grant a permission to an application, he or
she can cancel the installation process.
Install-time permissions can provide users with control
over their privacy and reduce the impact of bugs and vul-
nerabilities in applications. However, an install-time per-
mission system is ineffective if developers routinely request
more permissions than they require. Overprivileged applica-
tions expose users to unnecessary permission warnings and
increase the impact of a bug or vulnerability. We study An-
droid applications to determine whether Android developers
follow least privilege or overprivilege their applications.
We present a tool, Stowaway, that detects overprivilege
in compiled Android applications. Stowaway is composed
of two parts: a static analysis tool that determines what
API calls an application makes, and a permission map that
identifies what permissions are needed for each API call. An-
droid’s documentation does not provide sufficient permission
information for such an analysis, so we empirically deter-
mined Android 2.2’s access control policy. Using automated
testing techniques, we achieved 85% coverage of the Android
API. Our permission map provides insight into the Android
permission system and enables us to identify overprivilege.
We apply Stowaway to 940 Android applications from the
Android Market and find that about one-third of applica-
tions are overprivileged. The overprivileged applications
generally request few extra privileges: more than half only
contain one extra permission, and only 6% request more
than four unnecessary permissions. We investigate causes
of overprivilege and find that many developer errors stem
from confusion about the permission system. Our results
indicate that developers are trying to follow least privilege,
which supports the potential effectiveness of install-time per-
mission systems like Android’s.
Android provides developer documentation, but its per-
mission information is limited. The lack of reliable per-
mission information may cause developer error. The doc-
umentation lists permission requirements for only 78 meth-
ods, whereas our testing reveals permission requirements for
1, 259 methods (a sixteen-fold improvement over the docu-
mentation). Additionally, we identify 6 errors in the Android
permission documentation. This imprecision leaves develop-
ers to supplement reference material with guesses and mes-
sage boards. Developer confusion can lead to overprivileged
applications, as the developer adds unnecessary permissions
in an attempt to make the application work correctly.
Contributions. We provide the following contributions:
1. We developed Stowaway, a tool for detecting overpriv-
ilege in Android applications. We evaluate 940 appli-
cations from the Android Market with Stowaway and
find that about one-third are overprivileged.
2. We identify and quantify patterns of developer error
that lead to overprivilege.
3. Using automated testing techniques, we determine An-
droid’s access control policy. Our results represent a
fifteen-fold improvement over the documentation.
Other existing tools [11, 12] and future program analyses
could make use of our permission map to study permission
usage in Android applications. Stowaway and the permis-
sion map data are available at android-permissions.org.
Organization. Section 2 provides an overview of Android
and its permission system, Section 3 discusses our API test-
ing methodology, and Section 4 describes our analysis of the
Android API. Section 5 describes our static analysis tools
for detecting overprivilege, and Section 6 discusses our ap-
plication overprivilege analysis.
2. THE ANDROID PERMISSION SYSTEM
Android has an extensive API and permission system. We
first provide a high-level overview of the Android application
platform and permissions. We then present a detailed de-
scription of how Android permissions are enforced.
2.1 Android Background
Android smartphone users can install third-party appli-
cations through the Android Market [3] or Amazon App-
store [1]. The quality and trustworthiness of these third-
party applications vary widely, so Android treats all appli-
cations as potentially buggy or malicious. Each application
runs in a process with a low-privilege user ID, and applica-
tions can access only their own files by default. Applications
are written in Java (possibly accompanied by native code),
and each application runs in its own virtual machine.
Android controls access to system resources with install-
time permissions. Android 2.2 defines 134 permissions, cat-
egorized into three threat levels:
1. Normal permissions protect access to API calls that
could annoy but not harm the user. For example,
SET_WALLPAPER controls the ability to change the user’s
background wallpaper.
2. Dangerous permissions control access to potentially
harmful API calls, like those related to spending money
or gathering private information. For example, Dan-
gerous permissions are required to send text messages
or read the list of contacts.
3. Signature/System permissions regulate access to the
most dangerous privileges, such as the ability to con-
trol the backup process or delete application pack-
ages. These permissions are difficult to obtain: Sig-
nature permissions are granted only to applications
that are signed with the device manufacturer’s certifi-
cate, and SignatureOrSystem permissions are granted
to applications that are signed or installed in a spe-
cial system folder. These restrictions essentially limit
Signature/System permissions to pre-installed applica-
tions, and requests for Signature/System permissions
by other applications will be ignored.
Applications can define their own permissions for the pur-
pose of self-protection, but we focus on Android-defined per-
missions that protect system resources. We do not consider
developer-defined permissions at any stage of our analysis.
Similarly, we do not consider Google-defined permissions
that are included in Google applications like Google Reader
but are not part of the operating system.
Permissions may be required when interacting with the
system API, databases, and the message-passing system.
The public API [2] describes 8, 648 methods, some of which
are protected by permissions. User data is stored in Con-
tent Providers, and permissions are required for operations
on some system Content Providers. For example, applica-
tions must hold the READ_CONTACTS permission in order to
execute READ queries on the Contacts Content Provider.
Applications may also need permissions to receive Intents
(i.e., messages) from the operating system. Intents notify
applications of events, such as a change in network connec-
tivity, and some Intents sent by the system are delivered
only to applications with appropriate permissions. Further-
more, permissions are required to send Intents that mimic
the contents of system Intents.
2.2 Permission Enforcement
We describe how the system API, Content Providers, and
Intents are implemented and protected. To our knowledge,
we are the first to describe the Android permission enforce-
ment mechanisms in detail.
2.2.1 The API
API Structure. The Android API framework is composed
of two parts: a library that resides in each application’s vir-
tual machine and an implementation of the API that runs in
the system process(es). The API library runs with the same
permissions as the application it accompanies, whereas the
API implementation in the system process has no restric-
tions. The library provides syntactic sugar for interacting
with the API implementation. API calls that read or change
global phone state are proxied by the library to the API im-
plementation in the system process.
API calls are handled in three steps (Figure 1). First, the
application invokes the public API in the library. Second,
the library invokes a private interface, also in the library.
The private interface is an RPC stub. Third, the RPC stub
initiates an RPC request with the system process that asks a
system service to perform the desired operation. For exam-
ple, if an application calls ClipboardManager.getText(),
the call will be relayed to IClipboard$Stub$Proxy, which
proxies the call to the system process’s ClipboardService.
An application can use Java reflection [19] to access all
of the API library’s hidden and private classes, methods,
and fields. Some private interfaces do not have any corre-
sponding public API; however, applications can still invoke
them using reflection. These non-public library methods
are intended for use by Google applications or the frame-
work itself, and developers are advised against using them
because they may change or disappear between releases [17].
Nonetheless, some applications use them. Java code running
in the system process is in a separate virtual machine and
therefore immune to reflection.
Application
Application Process System Processes
Dalvik Virtual Machine
C Library
Native
Application
Component
Dalvik Virtual Machine
Native Code
Binder
Service1
Thread
Thread
Binder
ServiceN
API Library
...
Public
API
RPC Stub
IBinder
Hidden
Figure 1: The architecture of the Android platform. Permission checks occur in the system process.
Permissions. To enforce permissions, various parts of the
system invoke a permission validation mechanism to check
whether a given application has a specified permission. The
permission validation mechanism is implemented as part of
the trusted system process, and invocations of the permis-
sion validation mechanism are spread throughout the API.
There is no centralized policy for checking permissions when
an API is called. Rather, mediation is contingent on the cor-
rect placement of permission validation calls.
Permission checks are placed in the API implementation
in the system process. When necessary, the API implemen-
tation calls the permission validation mechanism to check
that the invoking application has the necessary permissions.
In some cases, the API library may also redundantly check
these permissions, but such checks cannot be relied upon:
applications can circumvent them by directly communicat-
ing with the system process via the RPC stubs. Permission
checks therefore should not occur in the API library. In-
stead, the API implementation in the system process should
invoke the permission validation mechanism.
A small number of permissions are enforced by Unix groups,
rather than the Android permission validation mechanism.
In particular, when an application is installed with the INTER-
NET, WRITE_EXTERNAL_STORAGE, or BLUETOOTH permissions, it
is assigned to a Linux group that has access to the pertinent
sockets and files. Thus, the Linux kernel enforces the access
control policy for these permissions. The API library (which
runs with the same rights as the application) can accordingly
operate directly on these sockets and files, without needing
to invoke the API implementation in the system process.
Native Code. Applications can include native code in ad-
dition to Java code, but native code is still beholden to the
permission system. Attempts to open sockets or files are me-
diated by Linux permissions. Native code cannot communi-
cate directly with the system API. Instead, the application
must create Java wrapper methods to invoke the API on
behalf of the native code. Android permissions are enforced
as usual when the API calls are executed.
2.2.2 Content Providers
System Content Providers are installed as standalone ap-
plications, separate from the system process and API library.
They are protected with both static and dynamic permission
checks, using the same mechanisms that are available to ap-
plications to protect their own Content Providers.
Static declarations assign separate read and write per-
missions to a given Content Provider. By default, these
permissions are applied to all resources stored by the Con-
tent Provider. Restrictions can also be applied at a finer
granularity by associating permissions with a path (e.g.,
content://a/b). For example, a Content Provider that
stores both public and private notes might want to set a
default permission requirement for the whole Content Pro-
vider, but then allow unrestricted access to the public notes.
Extra permission requirements can similarly be set for cer-
tain paths, making data under those paths accessible only
if the calling application has the default permissions for the
provider as well as the path-specific permissions.
Content Providers can also enforce permissions program-
matically: the Content Provider code that handles a query
can explicitly call the system’s permission validation mech-
anism to require certain permissions. This gives the devel-
oper greater control over the granularity of the permission
enforcement mechanism, allowing her to selectively require
permissions for query values or database data.
2.2.3 Intents
Android’s Intent system is used extensively for inter- and
intra-application communication. To prevent applications
from mimicking system Intents, Android restricts who may
send certain Intents. All Intents are sent through the Ac-
tivityManagerService (a system service), which enforces this
restriction. Two techniques are used to restrict the sending
of system Intent. Some Intents can only be sent by appli-
cations with appropriate permissions. Other system Intents
can only be sent by processes whose UID matches the sys-
tem’s. Intents in the latter category cannot be sent by appli-
cations, regardless of what permissions they hold, because
these Intents must originate from the system process.
Applications may also need permissions to receive some
system Intents. The OS uses the standard Android mecha-
nism for restricting its Intent recipients. An application (in
this case, the OS) may restrict who can receive an Intent by
attaching a permission requirement to the Intent [13].
3. PERMISSION TESTING
METHODOLOGY
Android’s access control policy is not well documented,
but the policy is necessary to determine whether applica-
tions are overprivileged. To address this shortcoming, we
empirically determined the access control policy that An-
droid enforces. We used testing to construct a permission
map that identifies the permissions required for each method
in the Android API. In particular, we modified Android 2.2’s
permission verification mechanism to log permission checks
as they occur. We then generated unit test cases for API
calls, Content Providers, and Intents. Executing these tests
allowed us to observe the permissions required to interact
with system APIs. A core challenge was to build unit tests
that obtain call coverage of all platform resources.
3.1 The API
As described in §2.2.1, the Android API provides applica-
tions with a library that includes public, private, and hidden
classes and methods. The set of private classes includes the
RPC stubs for the system services.
1
All of these classes and
methods are accessible to applications using Java reflection,
so we must test them to identify permission checks. We con-
ducted testing in three phases: feedback-directed testing;
customizable test case generation; and manual verification.
3.1.1 Feedback-Directed Testing
For the first phase of testing, we used Randoop, an auto-
mated, feedback-directed, object-oriented test generator for
Java [20, 22]. Randoop takes a list of classes as input and
searches the space of possible sequences of methods from
these classes. We modified Randoop to run as an Android
application and to log every method it invokes. Our modi-
fications to Android log every permission that is checked by
the Android permission validation mechanism, which lets us
deduce which API calls trigger permission checks.
Randoop searches the space of methods to find methods
whose return values can be used as parameters for other
methods. It maintains a pool of valid initial input sequences
and parameters, initially seeded with primitive values (e.g.,
int and String). Randoop builds test sequences incremen-
tally by randomly selecting a method from the test class’s
methods and selecting sequences from the input pool to
populate the method’s arguments. If the new sequence is
unique, then it is executed. Sequences that complete suc-
cessfully (i.e., without generating an exception) are added
to the sequence pool. Randoop’s goal is full coverage of the
test space. Unlike comparable techniques [4,9,21], Randoop
does not need a sample execution trace as input, making
large-scale testing such as API fuzzing more manageable.
Because Randoop uses Java reflection to generate the test
methods from the supplied list of classes, it supports test-
ing non-public methods. We modified Randoop to also test
nested classes of the input classes.
Limitations. Randoop’s feedback-guided space exploration
is limited by the objects and input values it has access to.
If Randoop cannot find an object of the correct type needed
to invoke a method in the sequence pool, then it will never
try to invoke the method. The Android API is too large to
test all interdependent classes at once, so in practice many
objects are not available in the sequence pool. We mitigated
this problem by testing related classes together (for example,
Account and AccountManager) and adding seed sequences
that return common Android-specific data types. Unfortu-
nately, this was insufficient to produce valid input parame-
ters for many methods. Many singleton object instances can
only be created through API calls with specific parameters;
1
The operating system also includes many internal methods
that make permission checks. However, applications cannot
invoke them because they are not currently exposed with
RPC stubs. Since we are focused on the application-facing
API, we do not test or discuss these permission checks.
for example, a WifiManager instance can be obtained by call-
ing android.content.Context.getSystemService(String)
with the parameter "wifi". We addressed this by augment-
ing the input pool with specific primitive constants and se-
quences. Additionally, some API calls expect memory ad-
dresses that store specific values for parameters, which we
were unable to solve at scale.
Randoop also does not handle ordering requirements that
are independent of input parameters. In some cases, An-
droid expects methods to precede each other in a very spe-
cific order. Randoop only generates sequence chains for the
purpose of creating arguments for methods; it is not able to
generate sequences to satisfy dependencies that are not in
the form of an input variable. Further aggravating this prob-
lem, many Android methods with underlying native code
generate segmentation faults if called out of order, which
terminates the Randoop testing process.
3.1.2 Customizable Test Case Generation
Randoop’s feedback-directed approach to testing failed to
cover certain types of methods. When this happened, there
was no way to manually edit its test sequences to control
sequence order or establish method pre-conditions. To ad-
dress these limitations and improve coverage, we built our
own test generation tool. Our tool accepts a list of method
signatures as input, and outputs at least one unit test for
each method. It maintains a pool of default input parame-
ters that can be passed to methods to be called. If multiple
values are available for a parameter, then our tool creates
multiple unit tests for that method. (Tests are created com-
binatorially when multiple parameters of the same method
have multiple possible values.) It also generates tests using
null values if it cannot find a suitable parameter. Because
our tool separates test case generation from execution, a hu-
man tester can edit the test sequences produced by our tool.
When tests fail, we manually adjust the order of method
calls, introduce extra code to satisfy method pre-conditions,
or add new parameters for the failing tests.
Our test generation tool requires more human effort than
Randoop, but it is effective for quickly achieving coverage
of methods that Randoop was unable to properly invoke.
Overseeing and editing a set of generated test cases pro-
duced by our tool is still substantially less work than manu-
ally writing test cases. Our experience with large-scale API
testing was that methods that are challenging to invoke by
feedback-directed testing occur often enough to be problem-
atic. When a human tester has the ability to edit failing
sequences, these methods can be properly invoked.
3.1.3 Manual Verification
The first two phases of testing generate a map of the per-
mission checks performed by each method in the API. How-
ever, these results contain three types of inconsistencies.
First, the permission checks caused by asynchronous API
calls are sometimes incorrectly associated with subsequent
API calls. Second, a method’s permission requirements can
be argument-dependent, in which case we see intermittent
or different permission checks for that method. Third, per-
mission checks can be dependent on the order in which API
calls are made. To identify and resolve these inconsistencies,
we manually verified the correctness of the permission map
generated by the first two phases of testing.
We used our customizable test generation tool to create
tests to confirm the permission(s) associated with each API
method in our permission map. We carefully experimented
with the ordering and arguments of the test cases to en-
sure that we correctly matched permission checks to asyn-
chronous API calls and identified the conditions of permis-
sion checks. When confirming permissions for potentially
asynchronous or order-dependent API calls, we also created
confirmation test cases for related methods in the perti-
nent class that were not initially associated with permission
checks. We ran every test case both with and without their
required permissions in order to identify API calls with mul-
tiple or substitutable permission requirements. If a test case
throws a security exception without a permission but suc-
ceeds with a permission, then we know that the permission
map for the method under test is correct.
Testing The Internet Permission. Applications can access
the Internet through the Android API, but other packages
such as java.net and org.apache also provide Internet ac-
cess. In order to determine which methods require access
to the Internet, we scoured the documentation and searched
the Internet for any and all methods that suggest Internet
access. Using this list, we wrote test cases to determine
which of those methods require the INTERNET permission.
3.2 Content Providers
Our Content Provider test application executes query,
insert, update, and delete operations on Content Pro-
vider URIs associated with the Android system and pre-
installed appliactions. We collected a list of URIs from the
android.provider package to determine the core set of Con-
tent Providers to test. We additionally collected Content
Provider URIs that we discovered during other phases of
testing. For each URI, we attempted to execute each type
of database operation without any permissions. If a security
exception was thrown, we recorded the required permission.
We added and tested combinations of permissions to iden-
tify multiple or substitutable permission requirements. Each
Content Provider was tested until security exceptions were
no longer thrown for a given operation, indicating the mini-
mum set of permissions required to complete that operation.
In addition to testing, we also examined the system Content
Providers’ static permission declarations.
3.3 Intents
We built a pair of applications to send and receive In-
tents. The Android documentation does not provide a sin-
gle, comprehensive list of the available system Intents, so we
scraped the public API to find string constants that could
be the contents of an Intent.
2
We sent and received Intents
with these constants between our test applications. In order
to test the permissions needed to receive system broadcast
Intents, we triggered system broadcasts by sending and re-
ceiving text messages, sending and receiving phone calls,
connecting and disconnecting WiFi, connecting and discon-
necting Bluetooth devices, etc. For all of these tests, we
recorded whether permission checks occurred and whether
the Intents were delivered or received successfully.
2
For those familiar with Android terminology, we searched
for Intent action strings.
4. PERMISSION MAP RESULTS
Our testing of the Android application platform resulted
in a permission map that correlates permission requirements
with API calls, Content Providers, and Intents. In this sec-
tion, we discuss our coverage of the API, compare our results
to the official Android documentation, and present charac-
teristics of the Android API and permission map.
4.1 Coverage
The Android API consists of 1, 665 classes with a total
of 16, 732 public and private methods. We attained 85%
coverage of the Android API through two phases of testing.
(We define a method as covered if we executed it without
generating an exception; we do not measure branch cover-
age.) Randoop attained an initial method coverage of 60%,
spread across all packages. We supplemented Randoop’s
coverage with our proprietary test generation tool, accom-
plishing close to 100% coverage of the methods that belong
to classes with at least one permission check.
The uncovered portion of the API is due to native calls
and the omission of second-phase tests for packages that did
not yield permission checks in the first phase. First, native
methods often crashed the application when incorrect pa-
rameters were supplied, making them difficult to test. Many
native method parameters are integers that represent point-
ers to objects in native code, making it difficult to supply
correct parameters. Approximately one-third of uncovered
methods are native calls. Second, we decided to omit sup-
plemental tests for packages that did not reveal permission
checks during the Randoop testing phase. If Randoop did
not trigger at least one permission check in a package, we
did not add more tests to the classes in the package.
4.2 Comparison With Documentation
Clear and well-developed documentation promotes correct
permission usage and safe programming practices. Errors
and omissions in the documentation can lead to incorrect
developer assumptions and overprivilege. Android’s docu-
mentation of permissions is limited, which is likely due to
their lack of a centralized access control policy. Our test-
ing identified 1, 259 API calls with permission checks. We
compare this to the Android 2.2 documentation.
We crawled the Android 2.2 documentation and found
that it specifies permission requirements for 78 methods.
The documentation additionally lists permissions in several
class descriptions, but it is not clear which methods of the
classes require the stated permissions. Of the 78 permission-
protected API calls in the documentation, our testing indi-
cates that the documentation for 6 API calls is incorrect. It
is unknown to us whether the documentation or implemen-
tation is wrong; if the documentation is correct, then these
discrepancies may be security errors.
Three of the documentation errors list a different permis-
sion than was found through testing. In one place, the doc-
umentation claims an API call is protected by the Danger-
ous permission MANAGE_ACCOUNTS, when it actually can be
accessed with the lower-privilege Normal permission GET_
ACCOUNTS. Another error claims an API call requires the
ACCESS_COARSE_UPDATES permission, which does not exist.
As a result, 5 of the 900 applications that we study in §6.2
request this non-existent permission. A third error states
that a method is protected with the BLUETOOTH permission,
when the method is in fact protected with BLUETOOTH_ADMIN.
