xref: /frameworks/base/docs/html/training/articles/security-tips.jd

page.title=Security Tips
page.article=true
@jd:body

<div id="tb-wrapper">
<div id="tb">
<h2>In this document</h2>
<ol class="nolist">
  <li><a href="#StoringData">Storing data</a></li>
  <li><a href="#Permissions">Using permissions</a></li>
  <li><a href="#Networking">Using networking</a></li>
  <li><a href="#InputValidation">Performing input validation</a></li>
  <li><a href="#UserData">Handling user data</a></li>
  <li><a href="#WebView">Using WebView</a></li>
  <li><a href="#Crypto">Using cryptography</a></li>
  <li><a href="#IPC">Using interprocess communication</a></li>
  <li><a href="#DynamicCode">Dynamically loading code</a></li>
  <li><a href="#Dalvik">Security in a virtual machine</a></li>
  <li><a href="#Native">Security in native code</a></li>
</ol>
<h2>See also</h2>
<ul>
<li><a href="http://source.android.com/tech/security/index.html">Android
  Security Overview</a></li>
<li><a href="{@docRoot}guide/topics/security/permissions.html">Permissions</a></li>
</ul>
</div></div>


<p>Android has built-in security features that significantly reduce the frequency and impact of
application security issues. The system is designed so that you can typically build your apps with
the default system and file permissions and avoid difficult decisions about security.</p>

<p>The following core security features help you build secure apps:
<ul>
<li>The Android Application Sandbox, which isolates your app data and code execution
from other apps.</li>
<li>An application framework with robust implementations of common
security functionality such as cryptography, permissions, and secure
<acronym title="Interprocess Communication">IPC</acronym>.</li>
<li>Technologies like ASLR, NX, ProPolice, safe_iop, OpenBSD dlmalloc, OpenBSD
calloc, and Linux mmap_min_addr to mitigate risks associated with common memory
management errors.</li>
<li>An encrypted file system that can be enabled to protect data on lost or
stolen devices.</li>
<li>User-granted permissions to restrict access to system features and user data.</li>
<li>Application-defined permissions to control application data on a per-app basis.</li>
</ul>

<p>It is important that you be familiar with the Android
security best practices in this document. Following these practices as general coding habits
 reduces the likelihood of inadvertently introducing security issues that
adversely affect your users.</p>



<h2 id="StoringData">Storing data</h2>

<p>The most common security concern for an application on Android is whether the data
that you save on the device is accessible to other apps. There are three fundamental
ways to save data on the device:</p>

<ul>
<li>Internal storage.</li>
<li>External storage.</li>
<li>Content providers.</li>
</ul>

The following paragraphs describe the security issues associated with each approach.

<h3 id="InternalStorage">Using internal storage</h3>

<p>By default, files that you create on <a
href="{@docRoot}guide/topics/data/data-storage.html#filesInternal">internal
storage</a> are accessible only to your app.
 Android implements this protection, and it's sufficient for most applications.</p>

<p>Generally, avoid the {@link android.content.Context#MODE_WORLD_WRITEABLE} or
{@link android.content.Context#MODE_WORLD_READABLE} modes for
<acronym title="Interprocess Communication">IPC</acronym> files because they do not provide
the ability to limit data access to particular applications, nor do they
provide any control of data format. If you want to share your data with other
app processes, instead consider using a
<a href="{@docRoot}guide/topics/providers/content-providers.html">content provider</a>, which
offers read and write permissions to other apps and can make
dynamic permission grants on a case-by-case basis.</p>

<p>To provide additional protection for sensitive data, you can
 encrypt local files using a key that is not directly accessible to the
application. For example, you can place a key in a {@link java.security.KeyStore}
and protect it with a user password that is not stored on the device.  While this
does not protect data from a root compromise that can monitor the user
inputting the password,  it can provide protection for a lost device without <a
href="http://source.android.com/tech/encryption/index.html">file system
encryption</a>.</p>


<h3 id="ExternalStorage">Using external storage</h3>

<p>Files created on <a
href="{@docRoot}guide/topics/data/data-storage.html#filesExternal">external
storage</a>, such as SD cards, are globally readable and writable. Because
external storage can be removed by the user and also modified by any
application, don't store sensitive information using
external storage.</p>

<p>You should <a href="#InputValidation">Perform input validation</a> when handling
data from external storage as you would with data from any untrusted source.
You should not store executables or
class files on external storage prior to dynamic loading.  If your app
does retrieve executable files from external storage, the files should be signed and
cryptographically verified prior to dynamic loading.</p>


<h3 id="ContentProviders">Using content providers</h3>

<p><a href="{@docRoot}guide/topics/providers/content-providers.html">Content providers</a>
offer a structured storage mechanism that can be limited
to your own application or exported to allow access by other applications.
If you do not intend to provide other
applications with access to your {@link android.content.ContentProvider}, mark them as <code><a
href="{@docRoot}guide/topics/manifest/provider-element.html#exported">
android:exported=false</a></code> in the application manifest. Otherwise, set the <code><a
href="{@docRoot}guide/topics/manifest/provider-element.html#exported">android:exported</a></code>
attribute to {@code true} to allow other apps to access the stored data.
</p>

<p>When creating a {@link android.content.ContentProvider}
that is exported for use by other applications, you can specify a single
<a href="{@docRoot}guide/topics/manifest/provider-element.html#prmsn">permission
</a> for reading and writing, or you can specify distinct permissions for reading and writing.
You should limit your permissions to those
required to accomplish the task at hand. Keep in mind that it’s usually
easier to add permissions later to expose new functionality than it is to take
them away and impact existing users.</p>

<p>If you are using a content provider
for sharing data between only your own apps, it is preferable to use the
<a href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">{@code
android:protectionLevel}</a> attribute set to {@code signature} protection.
Signature permissions do not require user confirmation,
so they provide a better user experience and more controlled access to the
content provider data when the apps accessing the data are
<a href="{@docRoot}tools/publishing/app-signing.html">signed</a> with
the same key.</p>

<p>Content providers can also provide more granular access by declaring the <a
href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn">{@code
android:grantUriPermissions}</a> attribute and using the {@link
android.content.Intent#FLAG_GRANT_READ_URI_PERMISSION} and {@link
android.content.Intent#FLAG_GRANT_WRITE_URI_PERMISSION} flags in the
{@link android.content.Intent} object
that activates the component.  The scope of these permissions can be further
limited by the <code><a
href="{@docRoot}guide/topics/manifest/grant-uri-permission-element.html">
&lt;grant-uri-permission&gt;</a></code> element.</p>

<p>When accessing a content provider, use parameterized query methods such as
{@link android.content.ContentProvider#query(Uri,String[],String,String[],String) query()},
{@link android.content.ContentProvider#update(Uri,ContentValues,String,String[]) update()}, and
{@link android.content.ContentProvider#delete(Uri,String,String[]) delete()} to avoid
potential SQL injection from untrusted sources. Note that using parameterized methods is not
sufficient if the <code>selection</code> argument is built by concatenating user data
prior to submitting it to the method.</p>

<p>Don't have a false sense of security about the write permission.
 The write permission allows SQL statements that make it possible for some
data to be confirmed using creative <code>WHERE</code> clauses and parsing the
results. For example, an attacker might probe for the presence of a specific phone
number in a call log by modifying a row only if that phone number already
exists. If the content provider data has predictable structure, the write
permission may be equivalent to providing both reading and writing.</p>







<h2 id="Permissions">Using permissions</h2>

<p>Because Android sandboxes applications from each other, applications must explicitly
share resources and data. They do this by declaring the permissions they need for additional
capabilities not provided by the basic sandbox, including access to device features such as
the camera.</p>


<h3 id="RequestingPermissions">Requesting permissions</h3>

<p>You should minimize the number of permissions that your app requests.
Restricting access to sensitive permissions reduces the risk of
inadvertently misusing those permissions, improves user adoption, and makes
your app less vulnerable for attackers. Generally,
if a permission is not required for your app to function, don't request it.</p>

<p>If it's possible to design your application in a way that does not require
any permissions, that is preferable.  For example, rather than requesting access
to device information to create a unique identifier, create a <a
href="{@docRoot}reference/java/util/UUID.html">GUID</a> for your application
(see the section about <a href="#UserData">Handling user data</a>). Or, rather than
using external storage (which requires permission), store data
on the internal storage.</p>

<p>In addition to requesting permissions, your application can use the <a
href="{@docRoot}guide/topics/manifest/permission-element.html">{@code &lt;permission&gt;}</a>
 element to protect IPC that is security sensitive and is exposed to other
applications, such as a {@link android.content.ContentProvider}.
In general, we recommend using access controls
other than user confirmed permissions where possible because permissions can
be confusing for users. For example, consider using the <a
href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature
protection level</a> on permissions for IPC communication between applications
provided by a single developer.</p>

<p>Do not leak permission-protected data. This occurs when your app exposes
data over IPC that is available only because your app has permission to access
that data. The clients of your app's IPC interface may not have that same
data-access permission. More details on the frequency and potential effects
of this issue appear in the research paper <a
href="https://www.usenix.org/legacy/event/sec11/tech/full_papers/Felt.pdf" class="external-link">
Permission Re-Delegation: Attacks and Defenses
</a>, published at USENIX.



<h3 id="CreatingPermissions">Creating permissions</h3>

<p>Generally, you should strive to define as few permissions as possible while
satisfying your security requirements.  Creating a new permission is relatively
uncommon for most applications, because the <a
href="{@docRoot}reference/android/Manifest.permission.html">system-defined
permissions</a> cover many situations.  Where appropriate,
perform access checks using existing permissions.</p>

<p>If you must create a new permission, consider whether you can accomplish
your task with a <a
href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature
protection level</a>.  Signature permissions are transparent
to the user and allow access only by applications signed by the same developer
as the application performing the permission check.</p>

<p>If you create a permission with the <a
href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">dangerous
protection level</a>, there are a number of complexities
that you need to consider:
<ul>
<li>The permission must have a string that concisely expresses to a user the
security decision they are required to make.</li>
<li>The permission string must be localized to many different languages.</li>
<li>Users may choose not to install an application because a permission is
confusing or perceived as risky.</li>
<li>Applications may request the permission when the creator of the permission
has not been installed.</li>
</ul>

<p>Each of these poses a significant nontechnical challenge for you as the developer
while also confusing your users,
which is why we discourages the use of the <em>dangerous</em> permission level.</p>





<h2 id="Networking">Using networking</h2>

<p>Network transactions are inherently risky for security, because they involve transmitting
data that is potentially private to the user. People are increasingly aware of the privacy
concerns of a mobile device, especially when the device performs network transactions,
so it's very important that your app implement all best practices toward keeping the user's
data secure at all times.</p>

<h3 id="IPNetworking">Using IP networking</h3>

<p>Networking on Android is not significantly different from other Linux
environments.  The key consideration is making sure that appropriate protocols
are used for sensitive data, such as {@link javax.net.ssl.HttpsURLConnection} for
secure web traffic. You should use HTTPS over HTTP anywhere that HTTPS is
supported on the server, because mobile devices frequently connect on networks
that are not secured, such as public Wi-Fi hotspots.</p>

<p>Authenticated, encrypted socket-level communication can be easily
implemented using the {@link javax.net.ssl.SSLSocket}
class.  Given the frequency with which Android devices connect to unsecured
wireless networks using Wi-Fi, the use of secure networking is strongly
encouraged for all applications that communicate over the network.</p>

<p>Some applications use <a
href="http://en.wikipedia.org/wiki/Localhost" class="external-link">localhost</a> network ports for
handling sensitive IPC.  You should not use this approach because these interfaces are
accessible by other applications on the device. Instead, use an Android IPC
mechanism where authentication is possible, such as with a {@link android.app.Service}.
Binding to INADDR_ANY is worse than using loopback because then your application
may receive requests from anywhere.</p>

<p>Make sure that you don't
 trust data downloaded from HTTP or other insecure protocols.  This includes
validation of input in {@link android.webkit.WebView} and
any responses to intents issued against HTTP.</p>


<h3>Using telephony networking</h3>

<p>The <acronym title="Short Message Service">SMS</acronym> protocol was primarily designed for
user-to-user communication and is not well-suited for apps that want to transfer data.
Due to the limitations of SMS, you should use <a
href="{@docRoot}google/gcm/index.html">Google Cloud Messaging</a> (GCM)
and IP networking for sending data messages from a web server to your app on a user device.</p>

<p>Beware that SMS is neither encrypted nor strongly
authenticated on either the network or the device. In particular, any SMS receiver
should expect that a malicious user may have sent the SMS to your application. Don't
 rely on unauthenticated SMS data to perform sensitive commands.
Also, you should be aware that SMS may be subject to spoofing and/or
interception on the network.  On the Android-powered device itself, SMS
messages are transmitted as broadcast intents, so they may be read or captured
by other applications that have the {@link android.Manifest.permission#READ_SMS}
permission.</p>





<h2 id="InputValidation">Performing input validation</h2>

<p>Insufficient input validation is one of the most common security problems
affecting applications, regardless of what platform they run on. Android
has platform-level countermeasures that reduce the exposure of applications to
input validation issues, and you should use those features where possible. Also
note that the selection of type-safe languages tends to reduce the likelihood of
input validation issues.</p>

<p>If you are using native code, any data read from files, received over
the network, or received from an IPC has the potential to introduce a security
issue.  The most common problems are <a
href="http://en.wikipedia.org/wiki/Buffer_overflow" class="external-link">buffer overflows</a>, <a
href="http://en.wikipedia.org/wiki/Double_free#Use_after_free" class="external-link">use after
free</a>, and <a
href="http://en.wikipedia.org/wiki/Off-by-one_error" class="external-link">off-by-one errors</a>.
Android provides a number of technologies like <acronym
title="Address Space Layout Randomization">ASLR</acronym> and <acronym
title="Data Execution Prevention">DEP</acronym> that reduce the
exploitability of these errors, but they don't solve the underlying problem.
You can prevent these vulnerabilities by carefully handling pointers and managing
buffers.</p>

<p>Dynamic, string-based languages such as JavaScript and SQL are also subject
to input validation problems due to escape characters and <a
href="http://en.wikipedia.org/wiki/Code_injection" class="external-link">script injection</a>.</p>

<p>If you are using data within queries that are submitted to an SQL database or a
content provider, SQL injection may be an issue.  The best defense is to use
parameterized queries, as is discussed in the above section about <a
href="#ContentProviders">content providers</a>.
Limiting permissions to read-only or write-only can also reduce the potential
for harm related to SQL injection.</p>

<p>If you can't use the security features above, you should make sure to use
well-structured data formats and verify that the data conforms to the
expected format. While blacklisting of characters or character-replacement can
be an effective strategy, these techniques are error prone in practice and
should be avoided when possible.</p>





<h2 id="UserData">Handling user data</h2>

<p>In general, the best approach for user data security is to minimize the use of APIs that access
sensitive or personal user data. If you have access to user data and can avoid
storing or transmitting it, don't store or transmit the data.
Consider if there is a way that your application logic can be
implemented using a hash or non-reversible form of the data.  For example, your
application might use the hash of an email address as a primary key to
avoid transmitting or storing the email address.  This reduces the chances of
inadvertently exposing data, and it also reduces the chance of attackers
attempting to exploit your application.</p>

<p>If your application accesses personal information such as passwords or
user names, keep in mind that some jurisdictions may require you to provide a
privacy policy explaining your use and storage of that data. Following the
security best practice of minimizing access to user data may also simplify
compliance.</p>

<p>You should also consider whether your application might be inadvertently
exposing personal information to other parties such as third-party components
for advertising or third-party services used by your application. If you don't
know why a component or service requires personal information, don’t
provide it.  In general, reducing the access to personal information by your
application reduces the potential for problems in this area.</p>

<p>If your app requires access to sensitive data, evaluate whether you need to
 transmit it to a server or you can run the operation on
the client. Consider running any code using sensitive data on the client to
avoid transmitting user data. Also, make sure that you do not inadvertently expose user
 data to other
applications on the device through overly permissive IPC, world-writable files,
or network sockets. Overly permissive IPC is a special case of leaking permission-protected data,
discussed in the <a href="#RequestingPermissions">Requesting Permissions</a> section.</p>

<p>If a <acronym title="Globally Unique Identifier">GUID</acronym>
is required, create a large, unique number and store it.  Don't
use phone identifiers such as the phone number or IMEI, which may be associated
with personal information.  This topic is discussed in more detail in the <a
href="http://android-developers.blogspot.com/2011/03/identifying-app-installations.html"
>Android Developer Blog</a>.</p>

<p>Be careful when writing to on-device logs.
In Android, logs are a shared resource and are available
to an application with the {@link android.Manifest.permission#READ_LOGS} permission.
Even though the phone log data
is temporary and erased on reboot, inappropriate logging of user information
could inadvertently leak user data to other applications.</p>






<h2 id="WebView">Using WebView</h2>

<p>Because {@link android.webkit.WebView} consumes web content that can include HTML
 and JavaScript,
improper use can introduce common web security issues such as <a
href="http://en.wikipedia.org/wiki/Cross_site_scripting" class="external-link">
cross-site-scripting</a>
(JavaScript injection).  Android includes a number of mechanisms to reduce
the scope of these potential issues by limiting the capability of
 {@link android.webkit.WebView} to
the minimum functionality required by your application.</p>

<p>If your application doesn't directly use JavaScript within a {@link android.webkit.WebView},
 <em>do not</em> call
 {@link android.webkit.WebSettings#setJavaScriptEnabled setJavaScriptEnabled()}.
Some sample code uses this method, which you might repurpose in production
application, so remove that method call if it's not required. By default,
{@link android.webkit.WebView} does
not execute JavaScript, so cross-site-scripting is not possible.</p>

<p>Use {@link android.webkit.WebView#addJavascriptInterface
addJavaScriptInterface()} with
particular care because it allows JavaScript to invoke operations that are
normally reserved for Android applications.  If you use it, expose
{@link android.webkit.WebView#addJavascriptInterface addJavaScriptInterface()} only to
web pages from which all input is trustworthy.  If untrusted input is allowed,
untrusted JavaScript may be able to invoke Android methods within your app.  In general, we
recommend exposing {@link android.webkit.WebView#addJavascriptInterface
addJavaScriptInterface()} only to JavaScript that is contained within your application APK.</p>

<p>If your application accesses sensitive data with a
{@link android.webkit.WebView}, you may want to use the
{@link android.webkit.WebView#clearCache clearCache()} method to delete any files stored
locally. You can also use server-side
headers such as <code>no-cache</code> to indicate that an application should
not cache particular content.</p>

<p>Devices running platforms older than Android 4.4 (API level 19)
use a version of {@link android.webkit webkit} that has a number of security issues.
As a workaround, if your app is running on these devices, it
must confirm that {@link android.webkit.WebView} objects display only trusted
content. To make sure your app isn’t exposed to
potential vulnerabilities in SSL, use the updatable security {@link
java.security.Provider Provider} object as described in <a
href="{@docRoot}training/articles/security-gms-provider.html">Updating Your
Security Provider to Protect Against SSL Exploits</a>. If your application must
render content from the open web, consider providing your own renderer so
you can keep it up to date with the latest security patches.</p>


<h3 id="Credentials">Handling credentials</h3>

<p>To make phishing attacks more conspicuous and less likely to be
successful, minimize the frequency of asking for user
credentials. Instead use an authorization token and refresh it.</p>

<p>Where possible, don't store user names and passwords on the device.
Instead, perform initial authentication using the user name and password
 supplied by the user, and then use a short-lived, service-specific
authorization token.</p>

<p>Services that are accessible to multiple applications should be accessed
using {@link android.accounts.AccountManager}. If possible, use the
{@link android.accounts.AccountManager} class to invoke a cloud-based service and don't store
passwords on the device.</p>

<p>After using {@link android.accounts.AccountManager} to retrieve an
{@link android.accounts.Account}, use {@link android.accounts.Account#CREATOR}
before passing in any credentials so that you do not inadvertently pass
credentials to the wrong application.</p>

<p>If credentials are used only by applications that you create, you
can verify the application that accesses the {@link android.accounts.AccountManager} using
{@link android.content.pm.PackageManager#checkSignatures checkSignature()}.
Alternatively, if only one application uses the credential, you might use a
{@link java.security.KeyStore} for storage.</p>





<h2 id="Crypto">Using cryptography</h2>

<p>In addition to providing data isolation, supporting full-filesystem
encryption, and providing secure communications channels, Android provides a
wide array of algorithms for protecting data using cryptography.</p>

<p>In general, try to use the highest level of pre-existing framework
implementation that can  support your use case.  If you need to securely
retrieve a file from a known location, a simple HTTPS URI may be adequate and
requires no knowledge of cryptography.  If you need a secure
tunnel, consider using {@link javax.net.ssl.HttpsURLConnection} or
{@link javax.net.ssl.SSLSocket} rather than writing your own protocol.</p>

<p>If you do need to implement your own protocol, you should <em>not</em>
implement your own cryptographic algorithms. Use
existing cryptographic algorithms such as those in the implementation of AES or
RSA provided in the {@link javax.crypto.Cipher} class.</p>

<p>Use a secure random number generator, {@link java.security.SecureRandom},
to initialize any cryptographic keys generated by {@link javax.crypto.KeyGenerator}.
Use of a key that is not generated with a secure random
number generator significantly weakens the strength of the algorithm and may
allow offline attacks.</p>

<p>If you need to store a key for repeated use, use a mechanism, such as
  {@link java.security.KeyStore}, that
provides a mechanism for long term storage and retrieval of cryptographic
keys.</p>





<h2 id="IPC">Using interprocess communication</h2>

<p>Some apps attempt to implement IPC using traditional Linux
techniques such as network sockets and shared files. However, you should instead
use Android system functionality for IPC such as {@link android.content.Intent},
{@link android.os.Binder} or {@link android.os.Messenger} with a {@link
android.app.Service}, and {@link android.content.BroadcastReceiver}.
The Android IPC mechanisms allow you to verify the identity of
the application connecting to your IPC and set security policy for each IPC
mechanism.</p>

<p>Many of the security elements are shared across IPC mechanisms.
If your IPC mechanism is not intended for use by other applications, set the
{@code android:exported} attribute to {@code false} in the component's manifest element,
such as for the <a
href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code &lt;service&gt;}</a>
element.  This is useful for applications that consist of multiple processes
within the same UID or if you decide late in development that you don't
actually want to expose functionality as IPC, but you don’t want to rewrite
the code.</p>

<p>If your IPC is accessible to other applications, you can
apply a security policy by using the <a
href="{@docRoot}guide/topics/manifest/permission-element.html">{@code &lt;permission>}</a>
element. If IPC is between your own separate apps that are signed with the same key,
it is preferable to use {@code signature} level permission in the <a
href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">{@code
android:protectionLevel}</a>.</p>




<h3>Using intents</h3>

<p>For activities and broadcast receivers, intents are the preferred mechanism for
 asynchronous IPC in Android.
Depending on your application requirements, you might use {@link
android.content.Context#sendBroadcast sendBroadcast()}, {@link
android.content.Context#sendOrderedBroadcast sendOrderedBroadcast()},
or an explicit intent to a specific application component.</p>

<p class="caution"><strong>Caution:</strong> If you use an intent to bind to a
 {@link android.app.Service}, ensure that your app is secure by using an
 <a href="{@docRoot}guide/components/intents-filters.html#Types">explicit</a>
intent. Using an implicit intent to start a service is a
security hazard because you can't be certain what service will respond to the intent,
and the user can't see which service starts. Beginning with Android 5.0 (API level 21),
 the system
throws an exception if you call {@link android.content.Context#bindService bindService()}
with an implicit intent.</p>

<p>Note that ordered broadcasts can be <em>consumed</em> by a recipient, so they
may not be delivered to all applications.  If you are sending an intent that must be delivered
to a specific receiver, you must use an explicit intent that declares the receiver
by name.</p>

<p>Senders of an intent can verify that the recipient has permission
 by specifying a non-null permission with the method call.  Only applications with that
permission receive the intent. If data within a broadcast intent may be
sensitive, you should consider applying a permission to make sure that
malicious applications can't register to receive those messages without
appropriate permissions. In those circumstances, you may also consider
invoking the receiver directly, rather than raising a broadcast.</p>

<p class="note"><strong>Note:</strong> Intent filters should not be considered
a security feature. Components
can be invoked with explicit intents and may not have data that would conform to the intent
filter. To
confirm that it is properly formatted for the invoked receiver, service, or
activity, perform input validation within your intent receiver.</p>




<h3 id="Services">Using services</h3>

<p>A {@link android.app.Service} is often used to supply functionality for other applications to
use. Each service class must have a corresponding <a
href="{@docRoot}guide/topics/manifest/service-element.html">{@code <service>}</a>
 declaration in its
manifest file.</p>

<p>By default, services are not exported and cannot be invoked by any other
application. However, if you add any intent filters to the service declaration, it is exported
by default. It's best if you explicitly declare the <a
href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code
android:exported}</a> attribute to be sure it behaves as you'd like.
Services can also be protected using the <a
href="{@docRoot}guide/topics/manifest/service-element.html#prmsn">{@code android:permission}</a>
attribute. By doing so, other applications need to declare
a corresponding <code><a
href="{@docRoot}guide/topics/manifest/uses-permission-element.html">&lt;uses-permission&gt;</a>
</code> element in their own manifest to be
able to start, stop, or bind to the service.</p>

<p class="note"><strong>Note:</strong> If your app targets Android 5.0 (API level 21) or later,
 you should use the {@link android.app.job.JobScheduler} to execute background
 services. For more information about {@link android.app.job.JobScheduler}, see its
 {@link android.app.job.JobScheduler API-reference documentation}.</p>

<p>A service can protect individual IPC calls into it with permissions, by
calling {@link android.content.Context#checkCallingPermission
checkCallingPermission()} before executing
the implementation of that call. You should use the
declarative permissions in the manifest, since those are less prone to
oversight.</p>



<h3>Using binder and messenger interfaces</h3>

<p>Using {@link android.os.Binder} or {@link android.os.Messenger} is the
preferred mechanism for RPC-style IPC in Android. They provide a well-defined
interface that enables mutual authentication of the endpoints, if required.</p>

<p>You should design your app interfaces in a manner that does not require
interface-specific permission checks. {@link android.os.Binder} and
{@link android.os.Messenger} objects are not declared within the
application manifest, and therefore you cannot apply declarative permissions
directly to them.  They generally inherit permissions declared in the
application manifest for the {@link android.app.Service} or {@link
android.app.Activity} within which they are
implemented.  If you are creating an interface that requires authentication
and/or access controls, you must explicitly add those controls
 as code in the {@link android.os.Binder} or {@link android.os.Messenger}
interface.</p>

<p>If you are providing an interface that does require access controls, use {@link
android.content.Context#checkCallingPermission checkCallingPermission()}
to verify whether the
caller has a required permission. This is especially important
before accessing a service on behalf of the caller, as the identify of your
application is passed to other interfaces.  If you are invoking an interface provided
by a {@link android.app.Service}, the {@link
android.content.Context#bindService bindService()}
 invocation may fail if you do not have permission to access the given service.
 If calling an interface provided locally by your own application, it may be
useful to use the {@link android.os.Binder#clearCallingIdentity clearCallingIdentity()}
to satisfy internal security checks.</p>

<p>For more information about performing IPC with a service, see
<a href="{@docRoot}guide/components/bound-services.html">Bound Services</a>.</p>



<h3 id="BroadcastReceivers">Using broadcast receivers</h3>

<p>A {@link android.content.BroadcastReceiver} handles asynchronous requests initiated by
an {@link android.content.Intent}.</p>

<p>By default, receivers are exported and can be invoked by any other
application. If your {@link android.content.BroadcastReceiver}
is intended for use by other applications, you
may want to apply security permissions to receivers using the <code><a
href="{@docRoot}guide/topics/manifest/receiver-element.html">
&lt;receiver&gt;</a></code> element within the application manifest.  This
prevents applications without appropriate permissions from sending an intent to
the {@link android.content.BroadcastReceiver}.</p>








<h2 id="DynamicCode">Dynamically loading code</h2>

<p>We strongly discourage loading code from outside of your application APK.
Doing so significantly increases the likelihood of application compromise due
to code injection or code tampering. It also adds complexity around version
management and application testing. It can also make it impossible to
verify the behavior of an application, so it may be prohibited in some
environments.</p>

<p>If your application does dynamically load code, the most important thing to
keep in mind about dynamically-loaded code is that it runs with the same
security permissions as the application APK.  The user makes a decision to
install your application based on your identity, and the user expects that
you provide any code run within the application, including code that is
dynamically loaded.</p>

<p>The major security risk associated with dynamically loading code is that the
code needs to come from a verifiable source. If the modules are included
directly within your APK, they cannot be modified by other applications.
This is true whether the code is a native library or a class being loaded using
{@link dalvik.system.DexClassLoader}.  Many applications
attempt to load code from insecure locations, such as downloaded from the
network over unencrypted protocols or from world-writable locations such as
external storage. These locations could allow someone on the network to modify
the content in transit or another application on a user's device to modify the
content on the device.</p>





<h2 id="Dalvik">Security in a virtual machine</h2>

<p>Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android,
but many of the concerns regarding secure code in other virtual machines also apply to Android.
In general, you shouldn't concern yourself with security issues relating to the virtual machine.
Your application runs in a secure sandbox environment, so other processes on the system can't
access your code or private data.</p>

<p>If you're interested in learning more about virtual machine security,
 familiarize yourself with some
existing literature on the subject. Two of the more popular resources are:
<ul>
<li><a href="http://www.securingjava.com/toc.html" class="external-link">
Securing Java</a></li>
<li><a
href="https://www.owasp.org/index.php/Category:Java#tab=Related_3rd_Party_Projects"
 class="external-link">
Related 3rd party Projects</a></li>
</ul></p>

<p>This document focuses on areas that are Android specific or
different from other VM environments.  For developers experienced with VM
programming in other environments, there are two broad issues that may be
different about writing apps for Android:
<ul>
<li>Some virtual machines, such as the JVM or .net runtime, act as a security
boundary, isolating code from the underlying operating system capabilities.  On
Android, the Dalvik VM is not a security boundary&mdash;the application sandbox is
implemented at the OS level, so Dalvik can interoperate with native code in the
same application without any security constraints.</li>

<li>Given the limited storage on mobile devices, it’s common for developers
to want to build modular applications and use dynamic class loading.  When
doing this, consider both the source where you retrieve your application logic
and where you store it locally. Do not use dynamic class loading from sources
that are not verified, such as unsecured network sources or external storage,
because that code might be modified to include malicious behavior.</li>
</ul>



<h2 id="Native">Security in native code</h2>

<p>In general, you should use the Android SDK for
application development, rather than using native code with the
<a href="{@docRoot}tools/sdk/ndk/index.html">Android NDK</a>.  Applications built
with native code are more complex, less portable, and more like to include
common memory-corruption errors such as buffer overflows.</p>

<p>Android is built using the Linux kernel, and being familiar with Linux
development security best practices is especially useful if you are
using native code. Linux security practices are beyond the scope of this document,
but one of the most popular resources is <a href="http://www.dwheeler.com/secure-programs"
 class="external-link">Secure Programming HOWTO - Creating Secure Software</a>.</p>

<p>An important difference between Android and most Linux environments is the
Application Sandbox.  On Android, all applications run in the Application
Sandbox, including those written with native code.  At the most basic level, a
good way to think about it for developers familiar with Linux is to know that
every application is given a unique <acronym title="User Identifier">UID</acronym>
with very limited permissions. This is discussed in more detail in the <a
href="http://source.android.com/tech/security/index.html">Android Security
Overview</a>, and you should be familiar with application permissions even if
you are using native code.</p>