implement new organization for Training classes
This also moves a few of the documents from API Guides > Best Practices
into the new courses for best practices.
This is also dependent on CL Ieac8a97a8d6fda41a3682241901150cfe16afc4d
which generates the list of classes/lessons on each course landing page.
Change-Id: I8132f72f78d844c3b035c7aa269ad3b88a25d02a
diff --git a/docs/html/training/security-tips.jd b/docs/html/training/security-tips.jd
new file mode 100644
index 0000000..88d6017
--- /dev/null
+++ b/docs/html/training/security-tips.jd
@@ -0,0 +1,759 @@
+page.title=Security Tips
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+<h2>In this document</h2>
+<ol>
+ <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>
+<ol>
+<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>
+</ol>
+</div></div>
+
+
+<p>Android has security features built
+into the operating system that significantly reduce the frequency and impact of
+application security issues. The system is designed so you can typically build your apps with
+default system and file permissions and avoid difficult decisions about security.</p>
+
+<p>Some of the core security features that help you build secure apps
+include:
+<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 filesystem 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>Nevertheless, it is important that you be familiar with the Android
+security best practices in this document. Following these practices as general coding habits
+will reduce 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>
+
+<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. This
+protection is implemented by Android and is sufficient for most
+applications.</p>
+
+<p>You should generally avoid using 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 on data format. If you want to share your data with other
+app processes, you might 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 might
+choose to encrypt local files using a key that is not directly accessible to the
+application. For example, a key can be placed in a {@link java.security.KeyStore}
+and protected 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, you should not store sensitive information using
+external storage.</p>
+
+<p>As with data from any untrusted source, you should <a href="#InputValidation">perform input
+validation</a> when handling data from external storage.
+We strongly recommend that you 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 {@code "true"} to allow other apps to access the stored data.
+</p>
+
+<p>When creating a {@link android.content.ContentProvider}
+that will be 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 distinct permissions for reading and writing
+within the manifest. We recommend that you 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 break 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">
+<grant-uri-permission element></a></code>.</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>Do not have a false sense of security about the write permission. Consider
+that the write permission allows SQL statements which 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 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>We recommend minimizing the number of permissions that your app requests
+Not having access to sensitive permissions reduces the risk of
+inadvertently misusing those permissions, can improve user adoption, and makes
+your app less for attackers. Generally,
+if a permission is not required for your app to function, do not 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 <permissions>}</a>
+to protect IPC that is security sensitive and will be 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 only available because it has a specific permission, but does
+not require that permission of any clients of it’s IPC interface. More
+details on the potential impacts, and frequency of this type of problem is
+provided in this research paper published at USENIX: <a
+href="http://www.cs.berkeley.edu/~afelt/felt_usenixsec2011.pdf">http://www.cs.be
+rkeley.edu/~afelt/felt_usenixsec2011.pdf</a></p>
+
+
+
+<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 only allow access by applications signed by the same developer
+as 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 will be 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 non-technical challenge for you as the developer
+while also confusing your users,
+which is why we discourage the use of the "dangerous" permission level.</p>
+
+
+
+
+
+<h2 id="Networking">Using Networking</h2>
+
+<p>Network transactions are inherently risky for security, because it involves 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. We prefer use of 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>We have seen some applications use <a
+href="http://en.wikipedia.org/wiki/Localhost">localhost</a> network ports for
+handling sensitive IPC. We discourage this approach since these interfaces are
+accessible by other applications on the device. Instead, you should use an Android IPC
+mechanism where authentication is possible such as with a {@link android.app.Service}. (Even
+worse than using loopback is to bind to INADDR_ANY since then your application
+may receive requests from anywhere.)</p>
+
+<p>Also, one common issue that warrants repeating is to make sure that you do
+not 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, we strongly recommend the use of <a
+href="{@docRoot}guide/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—Do
+not 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 does
+have platform-level countermeasures that reduce the exposure of applications to
+input validation issues and you should use those features where possible. Also
+note that selection of type-safe languages tends to reduce the likelihood of
+input validation issues.</p>
+
+<p>If you are using native code, then 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">buffer overflows</a>, <a
+href="http://en.wikipedia.org/wiki/Double_free#Use_after_free">use after
+free</a>, and <a
+href="http://en.wikipedia.org/wiki/Off-by-one_error">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 do not solve the underlying problem.
+You can prevent these vulneratbilities by careful 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">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 cannot use the security features above, we strongly recommend the use
+of well-structured data formats and verifying 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 the information, do not store or transmit the data.
+Finally, 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 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
+usernames, keep in mind that some jurisdictions may require you to provide a
+privacy policy explaining your use and storage of that data. So 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 a personal information, don’t
+provide it. In general, reducing the access to personal information by your
+application will reduce the potential for problems in this area.</p>
+
+<p>If access to sensitive data is required, evaluate whether that information
+must be transmitted to a server, or whether the operation can be performed on
+the client. Consider running any code using sensitive data on the client to
+avoid transmitting user data.</p>
+
+<p>Also, make sure that you do not inadvertently expose user data to other
+application on the device through overly permissive IPC, world writable files,
+or network sockets. This 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. Do not
+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">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 does not directly use JavaScript within a {@link android.webkit.WebView}, do
+<em>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. Server-side
+headers like <code>no-cache</code> can also be used to indicate that an application should
+not cache particular content.</p>
+
+
+
+
+<h3 id="Credentials">Handling Credentials</h3>
+
+<p>In general, we recommend minimizing the frequency of asking for user
+credentials—to make phishing attacks more conspicuous, and less likely to be
+successful. Instead use an authorization token and refresh it.</p>
+
+<p>Where possible, username and password should not be stored on the device.
+Instead, perform initial authentication using the username and password
+supplied by the user, and then use a short-lived, service-specific
+authorization token.</p>
+
+<p>Services that will be 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 do not store
+passwords on the device.</p>
+
+<p>After using {@link android.accounts.AccountManager} to retrieve an
+{@link android.accounts.Account}, {@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 to be used only by applications that you create, then you
+can verify the application which accesses the {@link android.accounts.AccountManager} using
+{@link android.content.pm.PackageManager#checkSignatures checkSignature()}.
+Alternatively, if only one application will use 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 find yourself needing to implement your own protocol, we strongly
+recommend that you <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, {@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 like
+ {@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. We strongly encourage you to 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 <service>}</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 do not
+actually want to expose functionality as IPC but you don’t want to rewrite
+the code.</p>
+
+<p>If your IPC is intended to be accessible to other applications, you can
+apply a security policy by using the <a
+href="{@docRoot}guide/topics/manifest/permission-element.html">{@code <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>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>Note that ordered broadcasts can be “consumed” by a recipient, so they
+may not be delivered to all applications. If you are sending an intent that muse be delivered
+to a specific receiver, then you must use an explicit intent that declares the receiver
+by nameintent.</p>
+
+<p>Senders of an intent can verify that the recipient has a permission
+specifying a non-Null permission with the method call. Only applications with that
+permission will receive the intent. If data within a broadcast intent may be
+sensitive, you should consider applying a permission to make sure that
+malicious applications cannot 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. You should perform input validation within your intent receiver to
+confirm that it is properly formatted for the invoked receiver, service, or
+activity.</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, then 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 will need to declare
+a corresponding <code><a
+href="{@docRoot}guide/topics/manifest/uses-permission-element.html"><uses-permission></a>
+</code> element in their own manifest to be
+able to start, stop, or bind to the service.</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. We generally recommend using 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>We strongly encourage designing 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, those controls must be
+explicitly added as code in the {@link android.os.Binder} or {@link android.os.Messenger}
+interface.</p>
+
+<p>If 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 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">
+<receiver></a></code> element within the application manifest. This will
+prevent 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. Finally, it can 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 made a decision to
+install your application based on your identity, and they are expecting 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, then 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}. We have seen many instances of applications
+attempting 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 users device to modify the
+content on the device, respectively.</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 cannnot
+access your code or private data.</p>
+
+<p>If you're interested in diving deeper on the subject of virtual machine security,
+we recommend that you 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">
+http://www.securingjava.com/toc.html</a></li>
+<li><a
+href="https://www.owasp.org/index.php/Java_Security_Resources">
+https://www.owasp.org/index.php/Java_Security_Resources</a></li>
+</ul></p>
+
+<p>This document is focused on the areas which 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—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, we encourage developers to 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 going to
+use native code. Linux security practices are beyond the scope of this document,
+but one of the most popular resources is “Secure Programming for
+Linux and Unix HOWTO”, available at <a
+href="http://www.dwheeler.com/secure-programs">
+http://www.dwheeler.com/secure-programs</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>
+