Android/frameworks_base
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

am 430e0c77: am f24a3798: am d17356b0: am f2f5b6ef: delete orphaned/redirected files

Browse Source 
* commit '430e0c77aae517bfe45700a81251864723719827':
  delete orphaned/redirected files
This commit is contained in:
Scott Main
2013-04-11 11:45:25 -07:00
committed by Android Git Automerger
parent bc80d99bd9 430e0c77aa
commit 6ca3484c3f
9 changed files with 0 additions and 1418 deletions
Download Patch File Download Diff File Expand all files Collapse all files

261
docs/html/guide/basics/appmodel.jd
View File

@@ -1,261 +0,0 @@
page.title=Application Model
@jd:body
<h1>Android Application Model: Applications, Tasks, Processes, and Threads</h1>
<p>In most operating systems, there is a strong 1-to-1 correlation between
the executable image (such as the .exe on Windows) that an application lives in,
the process it runs in, and the icon and application the user interacts with.
In Android these associations are much more fluid, and it is important to
understand how the various pieces can be put together.</p>
<p>Because of the flexible nature of Android applications, there is some
basic terminology that needs to be understood when implementing the
various pieces of an application:</p>
<ul>
<li><p>An <strong>android package</strong> (or <strong>.apk</strong> for short)
is the file containing an application's code and its resources. This is the
file that an application is distributed in and downloaded by the user when
installing that application on their device.</p></li>
<li><p>A <strong>task</strong> is generally what the user perceives as
an "application" that can be launched: usually a task has an icon in the
home screen through which it is accessed, and it is available as a top-level
item that can be brought to the foreground in front of other
tasks.</p></li>
<li><p>A <strong>process</strong> is a low-level kernel process in which
an application's code is running. Normally all of the code in a
.apk is run in one, dedicated process for that .apk; however, the
{@link android.R.styleable#AndroidManifestApplication_process process} tag
can be used to modify where that code is run, either for
{@link android.R.styleable#AndroidManifestApplication the entire .apk}
or for individual
{@link android.R.styleable#AndroidManifestActivity activity},
{@link android.R.styleable#AndroidManifestReceiver receiver},
{@link android.R.styleable#AndroidManifestService service}, or
{@link android.R.styleable#AndroidManifestProvider provider}, components.</p></li>
</ul>
<h2 id="Tasks">Tasks</h2>
<p>A key point here is: <em>when the user sees as an "application," what
they are actually dealing with is a task</em>. If you just create a .apk
with a number of activities, one of which is a top-level entry point (via
an {@link android.R.styleable#AndroidManifestIntentFilter intent-filter} for
the action <code>android.intent.action.MAIN</code> and
category <code>android.intent.category.LAUNCHER</code>), then there will indeed
be one task created for your .apk, and any activities you start from there
will also run as part of that task.</p>
<p>A task, then, from the user's perspective your application; and from the
application developer's perspective it is one or more activities the user
has traversed through in that task and not yet closed, or an activity stack.
A new task is created by
starting an activity Intent with the {@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK
Intent.FLAG_ACTIVITY_NEW_TASK} flag; this Intent will be used as the root Intent of
the task, defining what task it is. Any activity started without this flag
will run in the same task as the activity that is starting it (unless that
activity has requested a special launch mode, as discussed later). Tasks can
be re-ordered: if you use FLAG_ACTIVITY_NEW_TASK but there is already a task
running for that Intent, the current task's activity stack will be brought
to the foreground instead of starting a new task.</p>
<p>FLAG_ACTIVITY_NEW_TASK must only be used with care: using it says that,
from the user's perspective, a new application starts at this point. If this
is not the behavior you desire, you should not be creating a new task. In
addition, you should only use the new task flag if it is possible for the user
to navigate from home back to where they are and launch the same Intent as a
new task. Otherwise, if the user presses HOME instead of BACK from the task
you have launched, your task and its activities will be ordered behind the
home screen without a way to return to them.</p>
<h3>Task Affinities</h3>
<p>In some cases Android needs to know which task an activity belongs to even when
it is not being launched in to a specific task. This is accomplished through
task affinities, which provide a unique static name for the task that one or more
activities are intended to run in. The default task affinity for an activity
is the name of the .apk package name the activity is implemented in. This
provides the normally expected behavior, where all of the activities in a
particular .apk are part of a single application to the user.</p>
<p>When starting a new activity without the
{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK
Intent.FLAG_ACTIVITY_NEW_TASK} flag, task affinities have no impact on the
task the new activity will run in: it will always run in the task of the
activity that is starting it. However, if the NEW_TASK flag is being used,
then the affinity will be used to determine if a task already exists with
the same affinity. If so, that task will be brought to the front and the
new activity launched at the top of that task.</p>
<p>This behavior is most useful for situations where you must use the
NEW_TASK flag, in particular launching activities from status bar notifications
or home screen shortcuts. The result is that, when the user launches your
application this way, its current task state will be brought to the foreground,
and the activity they now want to look at placed on top of it.</p>
<p>You can assign your own task affinities in your manifest's
{@link android.R.styleable#AndroidManifestApplication application} tag for
all activities in the .apk, or the
{@link android.R.styleable#AndroidManifestActivity activity} tag of
individual activities. Some examples of how this can be used are:</p>
<ul>
<li>If your .apk contains multiple top-level applications that the user can
launch, then you will probably want to assign different affinities to each
of the activities that the users sees for your .apk. A good convention for
coming up with distinct names is to append your .apk's package name with
a colon separated string. For example, the "com.android.contacts" .apk
may have the affinities "com.android.contacts:Dialer" and
"com.android.contacts:ContactsList".</ul>
<li>If you are replacing a notification, shortcut, or other such "inner"
activity of an application that can be launched from outside of it, you may
need to explicitly set the taskAffinity of your replacement activity to be
the same as the application you are replacing. For example, if you are
replacing the contacts details view (which the user can make and invoke
shortcuts to), you would want to set the taskAffinity to
"com.android.contacts".</li>
</ul>
<h3>Launch Modes and Launch Flags</h3>
<p>The main way you control how activities interact with tasks is through
the activity's
{@link android.R.styleable#AndroidManifestActivity_launchMode launchMode}
attribute and the {@link android.content.Intent#setFlags flags} associated
with an Intent. These two parameters can work together in various ways
to control the outcome of the activity launch, as described in their
associated documentation. Here we will look at some common use cases and
combinations of these parameters.</p>
<p>The most common launch mode you will use (besides the default
<code>standard</code> mode) is <code>singleTop</code>. This does not have
an impact on tasks; it just avoids starting the same activity multiple times
on the top of a stack.
<p>The <code>singleTask</code> launch mode has a major
impact on tasks: it causes the activity to always be started in
a new task (or its existing task to be brought to the foreground). Using
this mode requires a lot of care in how you interact with the rest of the
system, as it impacts every path in to the activity. It should only be used
with activities that are front doors to the application (that is, which
support the MAIN action and LAUNCHER category).</p>
<p>The <code>singleInstance</code> launch mode is even more specialized, and
should only be used in applications that are implemented entirely as one
activity.</p>
<p>A situation you will often run in to is when another entity (such as the
{@link android.app.SearchManager} or {@link android.app.NotificationManager})
starts one of your activities. In this case, the
{@link android.content.Intent#FLAG_ACTIVITY_NEW_TASK
Intent.FLAG_ACTIVITY_NEW_TASK} flag must be used, because the activity is
being started outside of a task (and the application/task may not even
exist). As described previously, the standard behavior in this situation
is to bring to the foreground the current task matching the new activity's
affinity and start the new activity at the top of it. There are, however,
other types of behavior that you can implement.</p>
<p>One common approach is to also use the
{@link android.content.Intent#FLAG_ACTIVITY_CLEAR_TOP
Intent.FLAG_ACTIVITY_CLEAR_TOP} flag in conjunction with NEW_TASK. By doing so,
if your task is already running, then it will be brought to the foreground,
all of the activities on its stack cleared except the root activity, and the
root activity's {@link android.app.Activity#onNewIntent} called with the
Intent being started. Note that the activity often also use the <code>singleTop</code>
or <code>singleTask</code> launch mode when using this approach, so that
the current instance is given the new intent instead of requiring that it
be destroyed and a new instance started.</p>
<p>Another approach you can take is to set the notification activity's
<code>android:taskAffinity</code> to the empty string "" (indicating no affinity)
and setting the
<code>{@link android.R.styleable#AndroidManifestActivity_noHistory
android:noHistory}</code> and
<code>{@link android.R.styleable#AndroidManifestActivity_excludeFromRecents
android:excludeFromRecents}</code> attributes.
This approach is useful if you would like the notification
to take the user to a separate activity describing it, rather than return
to the application's task. By specifying these attributes, the activity will
be finished whether the user leaves it with BACK or HOME and it will not
show up in the recent tasks list; if the <code>noHistory</code> attribute
isn't specified, pressing HOME will result in the activity and its task
remaining in the system, possibly with no way to return to it.</p>
<p>Be sure to read the documentation on the
{@link android.R.styleable#AndroidManifestActivity_launchMode launchMode attribute}
and the {@link android.content.Intent#setFlags Intent flags} for the details
on these options.</p>
<h2 id="Processes">Processes</h2>
<p>In Android, processes are entirely an implementation detail of applications
and not something the user is normally aware of. Their main uses are simply:</p>
<ul>
<li> Improving stability or security by putting untrusted or unstable code
into another process.
<li> Reducing overhead by running the code of multiple .apks in the same
process.
<li> Helping the system manage resources by putting heavy-weight code in
a separate process that can be killed independently of other parts of the
application.
</ul>
<p>As described previously, the
{@link android.R.styleable#AndroidManifestApplication_process process} attribute
is used to control the process that particular application components run in.
Note that this attribute can not be used to violate security of the system: if
two .apks that are not sharing the same user ID try to run in the same process,
this will not be allowed and different distinct processes will be created for
each of them.</p>
<p>See the <a href="{@docRoot}devel/security.html">security</a> document for
more information on these security restrictions.</p>
<h2 id="Threads">Threads</h2>
<p>Every process has one or more threads running in it. In most situations, Android
avoids creating additional threads in a process, keeping an application
single-threaded unless it creates its own threads. An important repercussion
of this is that all calls to {@link android.app.Activity},
{@link android.content.BroadcastReceiver}, and {@link android.app.Service}
instances are made only from the main thread of the process they are running in.</p>
<p>Note that a new thread is <strong>not</strong> created for each
Activity, BroadcastReceiver, Service, or ContentProvider instance:
these application components are instantiated in the desired process (all in the
same process unless otherwise specified), in the main thread of that process.
This means that none of these components (including services) should perform
long or blocking operations (such as networking calls or computation loops)
when called by the system, since this will block
all other components in the process. You can use the standard library
{@link java.lang.Thread} class or Android's {@link android.os.HandlerThread}
convenience class to perform long operations on another thread.</p>
<p>There are a few important exceptions to this threading rule:</p>
<ul>
<li><p>Calls on to an {@link android.os.IBinder} or interface implemented on
an IBinder are dispatched from the thread calling them or a thread pool in the
local process if coming from another process, <em>not</em>
from the main thread of their process. In particular, calls on to the IBinder
of a {@link android.app.Service} will be called this way. (Though
calls to methods on Service itself are done from the main thread.)
This means that <em>implementations of IBinder interfaces must always be
written in a thread-safe way, since they can be called from any number of
arbitrary threads at the same time</em>.</p></li>
<li><p>Calls to the main methods of {@link android.content.ContentProvider}
are dispatched from the calling thread or main thread as with IBinder. The
specific methods are documented in the ContentProvider class.
This means that <em>implementations of these methods must always be
written in a thread-safe way, since they can be called from any number of
arbitrary threads at the same time</em>.</p></li>
<li><p>Calls on {@link android.view.View} and its subclasses are made from the
thread that the view's window is running in. Normally this will be the main
thread of the process, however if you create a thread and show a window from
there then the window's view hierarchy will be called from that thread.</p></li>
</ul>

76
docs/html/guide/basics/building-blocks.jd
View File

@@ -1,76 +0,0 @@
page.title=Building Blocks
@jd:body
<h1>Android Building Blocks</h1>
<p>You can think of an Android application as a collection of components, of
various kinds. These components are for the most part quite loosely coupled,
to the degree where you can accurately describe them as a federation of
components rather than a single cohesive application.</p>
<p>Generally, these components all run in the same system process. It's
possible (and quite common) to create multiple threads within that process,
and it's also possible to create completely separate child processes if you
need to. Such cases are pretty uncommon though, because Android tries very
hard to make processes transparent to your code.</p>
<p>These are the most important parts of the Android APIs:</p>
<dl>
<dt><a href="{@docRoot}devel/bblocks-manifest.html">AndroidManifest.xml</a></dt>
<dd>The AndroidManifest.xml file is the control file that tells the system
what to do with all the top-level components (specifically activities,
services, intent receivers, and content providers described below)
you've created. For instance, this is the
"glue" that actually specifies which Intents your Activities receive.</dd>
<dt>{@link android.app.Activity Activities}</dt>
<dd>An Activity is, fundamentally, an object that has a life cycle. An
Activity is a chunk of code that does some work; if necessary, that work
can include displaying a UI to the user. It doesn't have to, though - some
Activities never display UIs. Typically, you'll designate one of your
application's Activities as the entry point to your application. </dd>
<dt>{@link android.view.View Views}</dt>
<dd>A View is an object that knows how to draw itself to the screen.
Android user interfaces are comprised of trees of Views. If you want to
perform some custom graphical technique (as you might if you're writing a
game, or building some unusual new user interface widget) then you'd
create a View.</dd>
<dt>{@link android.content.Intent Intents}</dt>
<dd>An Intent is a simple message object that represents an "intention" to
do something. For example, if your application wants to display a web
page, it expresses its "Intent" to view the URI by creating an Intent
instance and handing it off to the system. The system locates some other
piece of code (in this case, the Browser) that knows how to handle that
Intent, and runs it. Intents can also be used to broadcast interesting
events (such as a notification) system-wide.</dd>
<dt>{@link android.app.Service Services}</dt>
<dd>A Service is a body of code that runs in the background. It can run in
its own process, or in the context of another application's process,
depending on its needs. Other components "bind" to a Service and invoke
methods on it via remote procedure calls. An example of a Service is a
media player; even when the user quits the media-selection UI, she
probably still intends for her music to keep playing. A Service keeps the
music going even when the UI has completed.</dd>
<dt>{@link android.app.NotificationManager Notifications}</dt>
<dd>A Notification is a small icon that appears in the status bar. Users
can interact with this icon to receive information. The most well-known
notifications are SMS messages, call history, and voicemail, but
applications can create their own. Notifications are the
strongly-preferred mechanism for alerting the user of something that needs
their attention.</dd>
<dt>{@link android.content.ContentProvider ContentProviders}</dt>
<dd>A ContentProvider is a data storehouse that provides access to data on
the device; the classic example is the ContentProvider that's used to
access the user's list of contacts. Your application can access data that
other applications have exposed via a ContentProvider, and you can also
define your own ContentProviders to expose data of your own.</dd>
</dl>

92
docs/html/guide/basics/fixme-gs-core-packages.jd
View File

@@ -1,92 +0,0 @@
page.title=Getting Started
@jd:body
<h1>Getting Started with Android</h1>
<p>To get started with Android, please read the following sections first:</p>
<dl>
<dt><a href="{@docRoot}intro/installing.html">Installing the SDK and
Plugin</a></dt>
<dd>How to install the Android SDK and Eclipse plugin.</dd>
<dt><a href="{@docRoot}intro/develop-and-debug.html">Developing and Debugging</a></dt>
<dd>An introduction to developing and debugging Android applications in Eclipse,
plus information on using other IDEs.</dd>
<dt><a href="{@docRoot}intro/hello-android.html">Hello Android</a></dt>
<dd>Writing your first Android Application, the ever popular Hello World,
Android style.</dd>
<dt><a href="{@docRoot}intro/anatomy.html">Anatomy of an App</a></dt>
<dd>A guide to the structure and architecture of an Android
Application. This guide will help you understand the pieces that make up
an Android app.</dd>
<dt><a href="{@docRoot}intro/tutorial.html">Notepad Tutorial</a></dt>
<dd>This tutorial document will lead you through
constructing a real Android Application: A notepad which can create, edit
and delete notes, and covers many of the basic concepts with practical
examples.</dd>
<dt><a href="{@docRoot}intro/tools.html">Development Tools</a></dt>
<dd>The
command line tools included with the SDK, what they do, and how to use
them.</dd>
<dt><a href="{@docRoot}intro/appmodel.html">Application Model</a></dt>
<dd>A guide to Applications, Tasks, Processes, and Threads.
These are the elements that define the way your application is run by the
system and presented to the user.</dd>
<dt><a href="{@docRoot}intro/lifecycle.html">Application Life Cycle</a></dt>
<dd>The important life-cycle details for
Applications and the Activities running inside of them.</dd>
</dl>
<h2>Other Introductory Material</h2>
<p>After reading the sections above, the following Getting Started information is also very useful:</p>
<h3>Core Packages</h3>
<p> These are the basic packages that make up the Android SDK for writing
applications. The packages are organized as layers, listed here from
lowest-level to highest.</p>
<dl>
<dt>{@link android.util}</dt>
<dd>contains various low-level utility classes, such
as specialized container classes, XML utilities, etc.</dd>
<dt>{@link android.os}</dt>
<dd> provides basic operating system services, message
passing, and inter-process communication.</dd>
<dt>{@link android.graphics}</dt><dd>is the core rendering package.</dd>
<dt>{@link android.text}, {@link android.text.method}, {@link
android.text.style}, and {@link android.text.util} </dt>
<dd>supply a rich set of
text processing tools, supporting rich text, input methods, etc.</dd>
<dt>{@link android.database}</dt>
<dd>contains low-level APIs for working with
databases.</dd>
<dt>{@link android.content}</dt>
<dd>provides various services for accessing data
on the device: applications installed on the device and their associated
resources, and content providers for persistent dynamic data.</dd>
<dt>{@link android.view}</dt>
<dd>is the core user-interface framework.</dd>
<dt>{@link android.widget}</dt>
<dd>supplies standard user interface elements
(lists, buttons, layout managers, etc) built from the view package.</dd>
<dt>{@link android.app}</dt>
<dd>provides the high-level application model,
implemented using Activities.</dd>
</dl>
<h3>Other Notable Packages</h3>
<p> These packages provide additional domain-specific features of the Android
platform. They are not necessary for basic application development.</p>
<dl>
<dt>{@link android.provider}</dt>
<dd>contains definitions for various standard
content providers included with the platform.</dd>
<dt>{@link android.telephony}</dt>
<dd>provides APIs for interacting with the
device's phone stack.</dd>
<dt>{@link android.webkit}</dt>
<dd>includes various APIs for working with
web-based content.</dd>
</dl>

8
docs/html/guide/basics/index.html
View File

@@ -1,8 +0,0 @@
<html>
<head>
<meta http-equiv="refresh" content="0;url=../index.html">
</head>
<body>
<a href="../index.html">click here</a> if you are not redirected.
</body>
</html>

65
docs/html/guide/topics/security/index.jd
View File

@@ -1,65 +0,0 @@
page.title=Security and Permissions
page.landing=true
page.landing.intro=Android's security architecture gives the user full control over what resources are accessible to each app, protecting the system itself and all apps in it. Learn how to use system permissions to request access to the resources your app needs and design your app for optimal security.
page.landing.image=
@jd:body
<div style="width=100%;padding-left:1em;">
<div style="float:left;clear:both;padding-top:20px;">
<p style="text-transform:uppercase;"><b style="color:#666;font-size:14px;">Blog Articles</b></p>
<div class="" style="border-top:2px solid #DDD;margin:1em 0;background-color:#F7F7F7;width:336px">
<div style="float:left;padding:8px;padding-right:16px;">
<img src="/assets/images/resource-article.png">
</div>
<div class="caption">
<p style="margin:0;padding:0;font-weight:bold;"><a href="">Accessibility: Are You Serving All Your Users?</a></p>
<p style="margin:0;padding:0">In the upcoming weeks, some of the older Client Login authentication keys will expire.
If you generated the token you’re currently using to authenticate with the C2DM servers before October 2011, it will stop working.</p>
<p style="margin:0;padding:0;font-weight:bold;"><a href="">Android C2DM — Client Login key expiration</a></p>
<p style="margin:0;padding:0">Accessibility is about making sure that Android users who have limited vision or other physical impairments can use your application just as well</p>
<p style="margin:0;padding:0;font-weight:bold;"><a href="">A Faster Emulator with Better Hardware Support</a></p>
<p style="margin:0;padding:0">The Android emulator is a key tool for Android developers in building and testing their apps.
As the power and diversity of Android devices has grown quickly, it’s been hard for the emulator keep pace. </p>
<a href="">More &raquo;</a>
</div>
</div>
</div>
<div style="float:right;padding-top:20px;">
<p style="text-transform:uppercase;"><b style="color:#666;font-size:14px;">Training</b></p>
<div class="" style="border-top:2px solid #DDD;bordddser-top:2px solid #FF8800;margin:1em 0;background-color:#F7F7F7;width:336px">
<div style="float:left;padding:8px;padding-right:16px;">
<img src="/assets/images/resource-tutorial.png">
</div>
<div class="caption">
<p style="margin:0;padding:0;font-weight:bold;"><a href="">Managing the Activity Lifecycle</a></p>
<p style="margin:0;padding:0">This class explains important lifecycle callback methods that each Activity
instance receives and how you can use them so your activity does what the user expects and does not consume system
resources when your activity doesn't need them.</p>
<p style="margin:0;padding:0;font-weight:bold;"><a href="">Supporting Different Devices</a></p>
<p style="margin:0;padding:0">This class teaches you how to use basic platform features that leverage alternative
resources and other features so your app can provide an optimized user experience on a variety of Android-compatible devices,
using a single application package (APK).</p>
<p style="margin:0;padding:0;font-weight:bold;"><a href="">Sharing Content</a></p>
<p style="margin:0;padding:0">This class covers some common ways you can send and receive content between
applications using Intent APIs and the ActionProvider object.</p>
<a href="">More &raquo;</a>
</div>
</div>
</div>
</div>

767
docs/html/guide/topics/security/security.jd
View File

@@ -1,767 +0,0 @@
page.title=Designing for Security
@jd:body
<div id="qv-wrapper">
<div id="qv">
<h2>In this document</h2>
<ol>
<li><a href="#Dalvik">Using Davlik Code</a></li>
<li><a href="#Native">Using Native Code</a></li>
<li><a href="#Data">Storing Data</a></li>
<li><a href="#IPC">Using IPC</a></li>
<li><a href="#Permissions">Using Permissions</a></li>
<li><a href="#Networking">Using Networking</a></li>
<li><a href="#DynamicCode">Dynamically Loading Code</a></li>
<li><a href="#Input">Performing Input Validation</a></li>
<li><a href="#UserData">Handling User Data</a></li>
<li><a href="#Crypto">Using Cryptography</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/security.html">Android Security
And Permissions</a></li>
</ol>
</div></div>
<p>Android was designed so that most developers will be able to build
applications using the default settings and not be confronted with difficult
decisions about security. Android also has a number of security features built
into the operating system that significantly reduce the frequency and impact of
application security issues.</p>
<p>Some of the security features that help developers build secure applications
include:
<ul>
<li>The Android Application Sandbox that isolates data and code execution on a
per-application basis.</li>
<li>Android application framework with robust implementations of common
security functionality such as cryptography, permissions, and secure IPC.</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>
</ul></p>
<p>Nevertheless, it is important for developers to be familiar with Android
security best practices to make sure they take advantage of these capabilities
and to reduce the likelihood of inadvertently introducing security issues that
can affect their applications.</p>
<p>This document is organized around common APIs and development techniques
that can have security implications for your application and its users. As
these best practices are constantly evolving, we recommend you check back
occasionally throughout your application development process.</p>
<a name="Dalvik"></a>
<h2>Using Dalvik Code</h2>
<p>Writing secure code that runs in virtual machines is a well-studied topic
and many of the issues are not specific to Android. Rather than attempting to
rehash these topics, we’d recommend that you familiarize yourself with the
existing literature. 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 and/or
different from other 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,
since that code can be modified to include malicious behavior.</li>
</ul></p>
<a name="Native"></a>
<h2>Using Native Code</h2>
<p>In general, we encourage developers to use the Android SDK for most
application development, rather than using native code. 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. This document is too short to discuss all of those best
practices, 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 UID 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>
<a name="Data"></a>
<h2>Storing Data</h2>
<h3>Using internal files</h3>
<p>By default, files created on <a
href="{@docRoot}guide/topics/data/data-storage.html#filesInternal">internal
storage</a> are only accessible to the application that created the file. This
protection is implemented by Android and is sufficient for most
applications.</p>
<p>Use of <a
href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_WRITEABLE">
world writable</a> or <a
href="{@docRoot}reference/android/content/Context.html#MODE_WORLD_READABLE">world
readable</a> files for IPC is discouraged because it does not provide
the ability to limit data access to particular applications, nor does it
provide any control on data format. As an alternative, you might consider using
a ContentProvider which provides read and write permissions, and can make
dynamic permission grants on a case-by-case basis.</p>
<p>To provide additional protection for sensitive data, some applications
choose to encrypt local files using a key that is not 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>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. Since
external storage can be removed by the user and also modified by any
application, applications should not store sensitive information using
external storage.</p>
<p>As with data from any untrusted source, applications should perform input
validation when handling data from external storage (see Input Validation
section). We strongly recommend that applications not store executables or
class files on external storage prior to dynamic loading. If an application
does retrieve executable files from external storage they should be signed and
cryptographically verified prior to dynamic loading.</p>
<h3>Using content providers</h3>
<p>ContentProviders provide a structured storage mechanism that can be limited
to your own application, or exported to allow access by other applications. By
default, a <code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code> is
<a href="{@docRoot}guide/topics/manifest/provider-element.html#exported">exported
</a> for use by other applications. If you do not intend to provide other
applications with access to your<code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code>, mark them as <code><a
href="{@docRoot}guide/topics/manifest/provider-element.html#exported">
android:exported=false</a></code> in the application manifest.</p>
<p>When creating a <code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">ContentProvider
</a></code> 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 <code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code> for sharing data between applications built by the
same developer, it is preferable to use
<a href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature
level permissions</a>. Signature permissions do not require user confirmation,
so they provide a better user experience and more controlled access to the
<code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code>.</p>
<p>ContentProviders can also provide more granular access by declaring the <a
href="{@docRoot}guide/topics/manifest/provider-element.html#gprmsn">
grantUriPermissions</a> element and using the <code><a
href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_READ_URI_PERMISSION">FLAG_GRANT_READ_URI_PERMISSION</a></code>
and <code><a
href="{@docRoot}reference/android/content/Intent.html#FLAG_GRANT_WRITE_URI_PERMISSION">FLAG_GRANT_WRITE_URI_PERMISSION</a></code>
flags in the 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 <code>
<a href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code>, use parameterized query methods such as <code>
<a href="{@docRoot}reference/android/content/ContentProvider.html#query(android.net.Uri,%20java.lang.String[],%20java.lang.String,%20java.lang.String[],%20java.lang.String)">query()</a></code>, <code><a
href="{@docRoot}reference/android/content/ContentProvider.html#update(android.net.Uri,%20android.content.ContentValues,%20java.lang.String,%20java.lang.String[])">update()</a></code>, and <code><a
href="{@docRoot}reference/android/content/ContentProvider.html#delete(android.net.Uri,%20java.lang.String,%20java.lang.String[])">delete()</a></code> to avoid
potential <a href="http://en.wikipedia.org/wiki/SQL_injection">SQL
Injection</a> from untrusted data. Note that using parameterized methods is not
sufficient if the <code>selection</code> 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>
<a name="IPC"></a>
<h2>Using Interprocess Communication (IPC)</h2>
<p>Some Android applications attempt to implement IPC using traditional Linux
techniques such as network sockets and shared files. We strongly encourage the
use of Android system functionality for IPC such as Intents, Binders, Services,
and Receivers. 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. <a
href="{@docRoot}reference/android/content/BroadcastReceiver.html">
Broadcast Receivers</a>, <a
href="{@docRoot}reference/android/R.styleable.html#AndroidManifestActivity">
Activities</a>, and <a
href="{@docRoot}reference/android/R.styleable.html#AndroidManifestService">
Services</a> are all declared in the application manifest. If your IPC mechanism is
not intended for use by other applications, set the <a
href="{@docRoot}guide/topics/manifest/service-element.html#exported">{@code android:exported}</a>
property to false. 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}reference/android/R.styleable.html#AndroidManifestPermission">
Permission</a> tag. If IPC is between applications built by the same developer,
it is preferable to use <a
href="{@docRoot}guide/topics/manifest/permission-element.html#plevel">signature
level permissions</a>. Signature permissions do not require user confirmation,
so they provide a better user experience and more controlled access to the IPC
mechanism.</p>
<p>One area that can introduce confusion is the use of intent filters. Note
that Intent filters should not be considered a security feature -- components
can be invoked directly 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>Using intents</h3>
<p>Intents are the preferred mechanism for asynchronous IPC in Android.
Depending on your application requirements, you might use <code><a
href="{@docRoot}reference/android/content/Context.html#sendBroadcast(android.content.Intent)">sendBroadcast()</a></code>,
<code><a
href="{@docRoot}reference/android/content/Context.html#sendOrderedBroadcast(android.content.Intent,%20java.lang.String)">sendOrderedBroadcast()</a></code>,
or direct an 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 where
delivery to a specific receiver is required, the intent must be delivered
directly to the receiver.</p>
<p>Senders of an intent can verify that the recipient has a permission
specifying a non-Null Permission upon sending. 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>
<h3>Using binder and AIDL interfaces</h3>
<p><a href="{@docRoot}reference/android/os/Binder.html">Binders</a> are 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. Binders are not declared within the
application manifest, and therefore you cannot apply declarative permissions
directly to a Binder. Binders generally inherit permissions declared in the
application manifest for the Service or Activity within which they are
implemented. If you are creating an interface that requires authentication
and/or access controls on a specific binder interface, those controls must be
explicitly added as code in the interface.</p>
<p>If providing an interface that does require access controls, use <code><a
href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code>
to verify whether the
caller of the Binder 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 Service, the <code><a
href="{@docRoot}reference/android/content/Context.html#bindService(android.content.Intent,%20android.content.ServiceConnection,%20int)">bindService()</a></code>
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 <code><a
href="{@docRoot}reference/android/os/Binder.html#clearCallingIdentity()">
clearCallingIdentity()</a></code> to satisfy internal security checks.</p>
<h3>Using broadcast receivers</h3>
<p>Broadcast receivers are used to handle asynchronous requests initiated via
an intent.</p>
<p>By default, receivers are exported and can be invoked by any other
application. If your <code><a
href="{@docRoot}reference/android/content/BroadcastReceiver.html">
BroadcastReceivers</a></code> 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 will
prevent applications without appropriate permissions from sending an intent to
the <code><a
href="{@docRoot}reference/android/content/BroadcastReceiver.html">
BroadcastReceivers</a></code>.</p>
<h3>Using Services</h3>
<p>Services are often used to supply functionality for other applications to
use. Each service class must have a corresponding <service> declaration in its
package's AndroidManifest.xml.</p>
<p>By default, Services are exported and can be invoked by any other
application. Services can be protected using the <a
href="{@docRoot}guide/topics/manifest/service-element.html#prmsn">{@code android:permission}</a>
attribute
within the manifest’s <code><a
href="{@docRoot}guide/topics/manifest/service-element.html">
&lt;service&gt;</a></code> tag. By doing so, other applications will 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>A Service can protect individual IPC calls into it with permissions, by
calling <code><a
href="{@docRoot}reference/android/content/Context.html#checkCallingPermission(java.lang.String)">checkCallingPermission()</a></code>
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 Activities</h3>
<p>Activities are most often used for providing the core user-facing
functionality of an application. By default, Activities are exported and
invokable by other applications only if they have an intent filter or binder
declared. In general, we recommend that you specifically declare a Receiver or
Service to handle IPC, since this modular approach reduces the risk of exposing
functionality that is not intended for use by other applications.</p>
<p>If you do expose an Activity for purposes of IPC, the <code><a
href="{@docRoot}guide/topics/manifest/activity-element.html#prmsn">android:permission</a></code>
attribute in the <code><a
href="{@docRoot}guide/topics/manifest/activity-element.html">
&lt;activity&gt;</a></code> declaration in the application manifest can be used to
restrict access to only those applications which have the stated
permissions.</p>
<a name="Permissions"></a>
<h2>Using Permissions</h2>
<h3>Requesting Permissions</h3>
<p>We recommend minimizing the number of permissions requested by an
application. Not having access to sensitive permissions reduces the risk of
inadvertently misusing those permissions, can improve user adoption, and makes
applications less attractive targets for attackers.</p>
<p>If it is possible to design your application in a way that does not require
a permission, that is preferable. For example, rather than requesting access
to device information to create an identifier, create a <a
href="{@docRoot}reference/java/util/UUID.html">GUID</a> for your application.
(This specific example is also discussed in Handling User Data) Or, rather than
using external storage, store data in your application directory.</p>
<p>If a permission is not required, do not request it. This sounds simple, but
there has been quite a bit of research into the frequency of over-requesting
permissions. If you’re interested in the subject you might start with this
research paper published by U.C. Berkeley: <a
href="http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf">
http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf</a></p>
<p>In addition to requesting permissions, your application can use <a
href="{@docRoot}guide/topics/manifest/permission-element.html">permissions</a>
to protect IPC that is security sensitive and will be exposed to other
applications -- such as a <code><a
href="{@docRoot}reference/android/content/ContentProvider.html">
ContentProvider</a></code>. In general, we recommend using access controls
other than user confirmed permissions where possible since 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 cause permission re-delegation. This occurs when an 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>Creating Permissions</h3>
<p>Generally, you should strive to create as few permissions as possible while
satisfying your security requirements. Creating a new permission is relatively
uncommon for most applications, since <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 Signature permission. Signature permissions are transparent
to the user and only allow access by applications signed by the same developer
as application performing the permission check. If you create a Dangerous
permission, then the user needs to decide whether to install the application.
This can be confusing for other developers, as well as for users.</p>
<p>If you create a Dangerous permission, 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>Uses 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>
<p>Each of these poses a significant non-technical challenge for an application
developer, which is why we discourage the use of Dangerous permission.</p>
<a name="Networking"></a>
<h2>Using Networking</h2>
<h3>Using IP Networking</h3>
<p>Networking on Android is not significantly different from Linux
environments. The key consideration is making sure that appropriate protocols
are used for sensitive data, such as <a
href="{@docRoot}reference/javax/net/ssl/HttpsURLConnection.html">HTTPS</a> for
web traffic. We prefer use of HTTPS over HTTP anywhere that HTTPS is
supported on the server, since mobile devices frequently connect on networks
that are not secured, such as public WiFi hotspots.</p>
<p>Authenticated, encrypted socket-level communication can be easily
implemented using the <code><a
href="{@docRoot}reference/javax/net/ssl/SSLSocket.html">SSLSocket</a></code>
class. Given the frequency with which Android devices connect to unsecured
wireless networks using WiFi, the use of secure networking is strongly
encouraged for all applications.</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, use an Android IPC
mechanism where authentication is possible such as a Service and Binder. (Even
worse than using loopback is to bind to INADDR_ANY since then your application
may receive requests from anywhere. We’ve seen that, too.)</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 <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> and
any responses to intents issued against HTTP.</p>
<h3>Using Telephony Networking</h3>
<p>SMS is the telephony protocol most frequently used by Android developers.
Developers should keep in mind that this protocol was primarily designed for
user-to-user communication and is not well-suited for some application
purposes. Due to the limitations of SMS, we strongly recommend the use of <a
href="http://code.google.com/android/c2dm/">C2DM</a> and IP networking for
sending data messages to devices.</p>
<p>Many developers do not realize that SMS is not encrypted or strongly
authenticated on the network or on 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 READ_SMS permission.</p>
<a name="DynamicCode"></a>
<h2>Dynamically Loading Code</h2>
<p>We strongly discourage loading code from outside of the 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
<a href="{@docRoot}reference/dalvik/system/DexClassLoader.html">
<code>DexClassLoader</code></a>. 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, respectively.</p>
<h3>Using WebView</h3>
<p>Since 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 WebView to
the minimum functionality required by your application.</p>
<p>If your application does not directly use JavaScript within a <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, do
not call
<a href="{@docRoot}reference/android/webkit/WebSettings.html#setJavaScriptEnabled(boolean)">
<code>setJavaScriptEnabled()</code></a>. We have seen this method invoked
in sample code that might be repurposed in production application -- so
remove it if necessary. By default, <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code> does
not execute JavaScript so cross-site-scripting is not possible.</p>
<p>Use <code><a
href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> with
particular care because it allows JavaScript to invoke operations that are
normally reserved for Android applications. Only expose <code><a
href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to
sources from which all input is trustworthy. If untrusted input is allowed,
untrusted JavaScript may be able to invoke Android methods. In general, we
recommend only exposing <code><a
href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> to
JavaScript that is contained within your application APK.</p>
<p>Do not trust information downloaded over HTTP, use HTTPS instead. Even if
you are connecting only to a single website that you trust or control, HTTP is
subject to <a
href="http://en.wikipedia.org/wiki/Man-in-the-middle_attack">MiTM</a> attacks
and interception of data. Sensitive capabilities using <code><a
href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code> should
not ever be exposed to unverified script downloaded over HTTP. Note that even
with the use of HTTPS,
<code><a
href="{@docRoot}reference/android/webkit/WebView.html#addJavascriptInterface(java.lang.Object,%20java.lang.String)">addJavaScriptInterface()</a></code>
increases the attack surface of your application to include the server
infrastructure and all CAs trusted by the Android-powered device.</p>
<p>If your application accesses sensitive data with a <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, you
may want to use the <code><a
href="{@docRoot}reference/android/webkit/WebView.html#clearCache(boolean)">
clearCache()</a></code> method to delete any files stored locally. Server side
headers like no-cache can also be used to indicate that an application should
not cache particular content.</p>
<a name="Input"></a>
<h2>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, you should use those features where possible. Also
note that selection of type-safe languages tends to reduce the likelihood of
input validation issues. We strongly recommend building your applications with
the Android SDK.</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 ASLR and DEP that reduce the
exploitability of these errors, but they do not solve the underlying problem.
These can be prevented by careful handling of pointers and managing of
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 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 ContentProviders section.
Limiting permissions to read-only or write-only can also reduce the potential
for harm related to SQL Injection.</p>
<p>If you are using <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, then
you must consider the possibility of XSS. If your application does not
directly use JavaScript within a <code><a
href="{@docRoot}reference/android/webkit/WebView.html">WebView</a></code>, do
not call setJavaScriptEnabled() and XSS is no longer possible. If you must
enable JavaScript then the WebView section provides other security best
practices.</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>
<a name="UserData"></a>
<h2>Handling User Data</h2>
<p>In general, the best approach is to minimize use of APIs that access
sensitive or personal user data. If you have access to 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 permission redelegation,
discussed in the Requesting Permissions section.</p>
<p>If a GUID 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>Application developers should be careful writing to on-device logs.
In Android, logs are a shared resource, and are available
to an application with the
<a href="{@docRoot}reference/android/Manifest.permission.html#READ_LOGS">
<code>READ_LOGS</code></a> 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>
<h3>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 <code>
<a href="{@docRoot}reference/android/accounts/AccountManager.html">
AccountManager</a></code>. If possible, use the <code><a
href="{@docRoot}reference/android/accounts/AccountManager.html">
AccountManager</a></code> class to invoke a cloud-based service and do not store
passwords on the device.</p>
<p>After using <code><a
href="{@docRoot}reference/android/accounts/AccountManager.html">
AccountManager</a></code> to retrieve an Account, check the <code><a
href="{@docRoot}reference/android/accounts/Account.html#CREATOR">CREATOR</a>
</code> 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 <code><a
href="{@docRoot}reference/android/accounts/AccountManager.html">
AccountManager</a></code> using <code><a
href="{@docRoot}reference/android/content/pm/PackageManager.html#checkSignatures(java.lang.String,%20java.lang.String)">checkSignature()</a></code>.
Alternatively, if only one application will use the credential, you might use a
{@link java.security.KeyStore} for
storage.</p>
<a name="Crypto"></a>
<h2>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
require no knowledge of cryptography on your part. If you need a secure
tunnel, consider using
<a href="{@docRoot}reference/javax/net/ssl/HttpsURLConnection.html">
<code>HttpsURLConnection</code></a> or <code><a
href="{@docRoot}reference/javax/net/ssl/SSLSocket.html">SSLSocket</a></code>,
rather than writing your own protocol.</p>
<p>If you do find yourself needing to implement your own protocol, we strongly
recommend that you not implement your own cryptographic algorithms. Use
existing cryptographic algorithms such as those in the implementation of AES or
RSA provided in the <code><a
href="{@docRoot}reference/javax/crypto/Cipher.html">Cipher</a></code> class.</p>
<p>Use a secure random number generator (
<a href="{@docRoot}reference/java/security/SecureRandom.html">
<code>SecureRandom</code></a>) to initialize any cryptographic keys (<a
href="{@docRoot}reference/javax/crypto/KeyGenerator.html">
<code>KeyGenerator</code></a>). 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>Conclusion</h2>
<p>Android provides developers with the ability to design applications with a
broad range of security requirements. These best practices will help you make
sure that your application takes advantage of the security benefits provided by
the platform.</p>
<p>You can receive more information on these topics and discuss security best
practices with other developers in the <a
href="http://groups.google.com/group/android-security-discuss">Android Security
Discuss</a> Google Group</p>

6
docs/html/guide/topics/ui/layout-objects.jd
View File

@@ -1,6 +0,0 @@
page.title=Layouts
parent.title=User Interface
parent.link=index.html
@jd:body
<p>You should have been redirected to <a href="declaring-layout.html">Layouts</a>.</p>

92
docs/html/guide/topics/ui/notifiers/index.jd
View File

@@ -1,92 +0,0 @@
page.title=Notifications
parent.title=User Interface
parent.link=../index.html
@jd:body
<p>Several types of situations may arise that require you to notify the user
about an event that occurs in your application. Some events require the user to respond
and others do not. For example:</p>
<ul>
<li>When an event such as saving a file is complete, a small message
should appear to confirm that the save was successful.</li>
<li>If the application is running in the background and needs the user's attention,
the application should create a notification that allows the user to respond at
his or her convenience.</li>
<li>If the application is
performing work that the user must wait for (such as loading a file),
the application should show a hovering progress wheel or bar.</li>
</ul>
<p>Each of these notification tasks can be achieved using a different technique:</p>
<ul>
<li>A <a href="#Toast">Toast Notification</a>, for brief messages that come
from the background.</li>
<li>A <a href="#StatusBar">Status Notification</a>, for persistent reminders
that come from the background and request the user's response.</li>
<li>A <a href="#Dialog">Dialog Notification</a>, for Activity-related notifications.</li>
</ul>
<p>This document summarizes each of these techniques for notifying the user and includes
links to full documentation.</p>
<h2 id="Toast">Toast Notification</h2>
<img src="{@docRoot}images/toast.png" alt="" style="float:right" />
<p>A toast notification is a message that pops up on the surface of the window.
It only fills the amount of space required for the message and the user's current
activity remains visible and interactive. The notification automatically fades in and
out, and does not accept interaction events. Because a toast can be created from a background
{@link android.app.Service}, it appears even if the application isn't visible.</p>
<p>A toast is best for short text messages, such as "File saved,"
when you're fairly certain the user is paying attention
to the screen. A toast can not accept user interaction events; if you'd like
the user to respond and take action, consider using a
<a href="#StatusBar">Status Notification</a> instead.</p>
<p>For more information, refer to <a href="toasts.html">Toast Notifications</a>.</p>
<h2 id="StatusBar">Status Notification</h2>
<img src="{@docRoot}images/notifications_window.png" alt="" style="float:right; clear:right;" />
<p>A status notification adds an icon to the system's status bar
(with an optional ticker-text message) and an expanded message in the "Notifications" window.
When the user selects the expanded message, Android fires an
{@link android.content.Intent} that is defined by the notification (usually to launch an
{@link android.app.Activity}).
You can also configure the notification to alert the user with a sound, a vibration, and flashing
lights on the device.</p>
<p>This kind of notification is ideal when your application is working in
a background {@link android.app.Service} and needs to
notify the user about an event. If you need to alert the user about an event that occurs
while your Activity is still in focus, consider using a
<a href="#Dialog">Dialog Notification</a> instead.</p>
<p>For more information, refer to
<a href="notifications.html">Status Notifications</a>.</p>
<h2 id="Dialog">Dialog Notification</h2>
<img src="{@docRoot}images/dialog_progress_spinning.png" alt="" style="float:right" />
<p>A dialog is usually a small window that appears in front of the current Activity.
The underlying Activity loses focus and the dialog accepts all user interaction.
Dialogs are normally used
for notifications and short activities that directly relate to the application in progress.</p>
<p>You should use a dialog when you need to show a progress bar or a short
message that requires confirmation from the user (such as an alert with "OK" and "Cancel" buttons).
You can use also use dialogs as integral components
in your application's UI and for other purposes besides notifications.
For a complete discussion on all the available types of dialogs,
including its uses for notifications, refer to
<a href="{@docRoot}guide/topics/ui/dialogs.html">Dialogs</a>.</p>

51
docs/html/sdk/installing/next.jd
View File

@@ -1,51 +0,0 @@
page.title=Next Steps
@jd:body
<p>Now that you've installed the Android SDK, here are are a few ways to learn Android
and start developing: </p>
<h3>Start coding</h3>
<ul>
<li>Follow the training class for <a
href="{@docRoot}training/basics/firstapp/index.html">Building Your First App</a>.
<p>This class is an essential first step for new Android developers.</p>
<p>It gives you step by step instructions for building a simple app. You’ll learn how to
create an Android project and run a debuggable version of the app. You'll also learn some
fundamentals of Android app design, including how to build a simple user interface and handle user
input.</p>
</li>
</ul>
<h3>Learn how to design your app</h3>
<ul>
<li>Learn the best practices for Android design and user experience by reading the Android <a
href="{@docRoot}design/index.html">Design</a> guidelines.</li>
</ul>
<h3>Read up on the API framework</h3>
<ul>
<li>Start reading about fundamental framework topics in the collection of <a
href="{@docRoot}guide/components/index.html">API Guides</a>.</li>
<li>Browse the API specifications in the <a
href="{@docRoot}reference/packages.html">Reference</a>.</li>
</ul>
<h3>Explore the development tools</h3>
<ul>
<li>Learn about developing an app with the Android Developer Tools plugin for Eclipse
and other tools from the <a
href="{@docRoot}tools/workflow/index.html">Workflow</a>.</li>
</ul>
<h3>Explore some code</h3>
<ul>
<li>Browse the sample apps available from the Android SDK Manager. You'll find them in
<code><em>&lt;sdk&gt;</em>/samples/<em>&lt;platform-version&gt;/</em></code>. </li>
</ul>