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

Merge branch 'readonly-p4-master'

Browse Source
This commit is contained in:
Dirk Dougherty
2009-04-22 01:05:08 -07:00
committed by The Android Open Source Project
parent 08f97d90e8 8aef7a7a0a
commit 4f7edaed3a
7 changed files with 20 additions and 661 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/html/community/index.jd
View File

@@ -77,7 +77,7 @@ phrasing your questions, read <a href="http://www.catb.org/%7Eesr/faqs/smart-que
<li><b>Android security discuss</b> - A place for open discussion on secure development, emerging security concerns, and best practices for and by android developers. Please don't disclose vulnerabilities directly on this list, you'd be putting all Android users at risk.
<ul>
<li>Subscribe using Google Groups:&nbsp;<a href="http://groups.google.com/group/android-security-discuss">android-security-discuss</a></li>
<li>Subscribe via email:&nbsp;<a href="mailto:android-security-discuss@googlegroups.com">android-secuirty-discuss@googlegroups.com</a><a href="mailto:android-platform-subscribe@googlegroups.com">
<li>Subscribe via email:&nbsp;<a href="mailto:android-security-discuss@googlegroups.com">android-security-discuss@googlegroups.com</a><a href="mailto:android-platform-subscribe@googlegroups.com">
</a></li>
</ul>
</li>

17
docs/html/guide/appendix/faq/framework.jd
View File

@@ -12,7 +12,7 @@ parent.link=index.html
from one Activity/Service to another?</a></li>
<li><a href="#4">How can I check if an Activity is already
running before starting it?</a></li>
<li><a href="#5">If an Activity starts a remote service,is
<li><a href="#5">If an Activity starts a remote service, is
there any way for the Service to pass a message back to the Activity?</a></li>
<li><a href="#6">How to avoid getting the Application not
responding dialog?</a></li>
@@ -20,7 +20,6 @@ parent.link=index.html
added or removed?</a></li>
</ul>
<!-- ------------------------------------------------------------------ -->
<a name="1" id="1"></a>
@@ -32,7 +31,7 @@ default. If needed, you can declare an <code>android:process</code> attribute
in your manifest file, to explicitly place a component (Activity/Service) in
another process.</p>
<!-- ------------------------------------------------------------------ -->
<a name="2" id="2"></a>
@@ -47,7 +46,7 @@ separate pool of transaction threads in each process to dispatch all
incoming IPC calls. The developer should create separate threads for any
long-running code, to avoid blocking the main UI thread.</p>
<!-- ------------------------------------------------------------------ -->
<a name="3" id="3"></a>
@@ -128,7 +127,7 @@ the <a href="{@docRoot}guide/topics/data/data-storage.html">Data Storage</a>
for further details on how to use these components.</p>
<!-- ------------------------------------------------------------------ -->
<a name="4" id="4"></a>
@@ -140,7 +139,7 @@ or to bring the activity stack to the front if is already running in the
background&mdash; is the to use the NEW_TASK_LAUNCH flag in the startActivity()
call.</p>
<!-- ------------------------------------------------------------------ -->
<a name="5" id="5"></a>
@@ -156,7 +155,7 @@ messages.</p>
<p>The sample code for remote service callbacks is given in <a
href="{@docRoot}guide/samples/ApiDemos/src/com/example/android/apis/app/RemoteService.html">ApiDemos/RemoteService</a></p>
<!-- ------------------------------------------------------------------ -->
<a name="6" id="6"></a>
@@ -166,7 +165,7 @@ href="{@docRoot}guide/samples/ApiDemos/src/com/example/android/apis/app/RemoteSe
document.</p>
<!-- ------------------------------------------------------------------ -->
<a name="7" id="7"></a>
@@ -194,5 +193,5 @@ removed.
</p>
<!-- ------------------------------------------------------------------ -->

48
docs/html/guide/appendix/faq/troubleshooting.jd
View File

@@ -23,7 +23,6 @@ parent.link=index.html
<li><a href="#majorminor">When I go to preferences in Eclipse and select "Android", I get the following error message: Unsupported major.minor version 49.0.</a></li>
<li><a href="#apidemosreinstall">I can't install ApiDemos apps in my IDE because of a signing error</a></li>
<li><a href="#signingcalendar">I can't compile my app because the build tools generated an expired debug certificate</a></li>
<li><a href="#addjunit">I can't run a JUnit test class in Eclipse/ADT</a></li>
</ul>
<a name="installeclipsecomponents" id="installeclipsecomponents"></a><h2>ADT Installation Error: "requires plug-in org.eclipse.wst.sse.ui".</h2>
@@ -245,8 +244,8 @@ documentation.</p>
<ol>
<li>First, delete the debug keystore/key already generated by the Android build tools. Specifically, delete the <code>debug.keystore</code> file. On Linux/Mac OSX, the file is stored in <code>~/.android</code>. On Windows XP, the file is stored in <code>
C:\Documents and Settings\&lt;user&gt;\Local Settings\Application Data\Android</code>. On Windows Vista, the file is stored in <code>
C:\Users\&lt;user&gt;\AppData\Local\Android</code></li>
C:\Documents and Settings\&lt;user&gt;\.android</code>. On Windows Vista, the file is stored in <code>
C:\Users\&lt;user&gt;\.android</code></li>
<li>Next, you can either
<ul>
<li>Temporarily change your development machine's locale (date and time) to one that uses a Gregorian calendar, for example, United States. Once the locale is changed, use the Android build tools to compile and install your app. The build tools will regenerate a new keystore and debug key with valid dates. Once the new debug key is generated, you can reset your development machine to the original locale. </li>
@@ -260,46 +259,3 @@ C:\Users\&lt;user&gt;\AppData\Local\Android</code></li>
<p>For general information about signing Android applications, see
<a href="{@docRoot}guide/publishing/app-signing.html">Signing Your Applications</a>. </p>
<h2 id="addjunit">I can't run a JUnit test class in Eclipse/ADT</h2>
<p>If you are developing on Eclipse/ADT, you can add JUnit test classes to your application. However, you may get an error when trying to run such a class as a JUnit test:</p>
<pre>Error occurred during initialization of VM
java/lang/NoClassDefFoundError: java/lang/ref/FinalReference</pre>
<p>This error occurs because android.jar does not include complete Junit.* class implementations, but includes stub classes only. </p>
<p>To add a JUnit class, you have to set up a JUnit configuration:.
<ol>
<li>In the Package Explorer view, select your project. </li>
<li>Open the launch configuration manager.
<ul>
<li>In Eclipse 3.3 (Europa), select <strong>Run </strong>&gt;
<strong>Open Run Dialog... </strong>or <strong>Run </strong>&gt;
<strong>Open Debug Dialog... </strong>.
</li>
<li>In Eclipse 3.4 (Ganymede), select <strong>Run </strong>&gt;
<strong>Run Configurations... </strong>or <strong>Run </strong>&gt;
<strong>Debug Configurations... </strong>.
</li>
</ul>
</li>
<li>In the configuration manager, right-click the "JUnit" configuration type and select <strong>New</strong></li>
<li>In the new configuration's <strong>Test</strong> tab, specify the project and test class, as well as any options for running the test. </li>
<li>In the new configuration's <strong>Classpath</strong> tab, find "Android Library" under Bootstrap Entries and remove it. </li>
<li>Still in the <strong>Classpath</strong> tab, select Bootstrap Entries and click the Advanced button. </li>
<ol type="a">
<li>Choose Add Library and click OK.</li>
<li>Select JRE System Library and click Next. </li>
<li>Select Workspace Default JRE and click Finish.</li>
</ol>
<li>Select Bootstrap Entries again and click Advanced.</li>
<ol type="a">
<li>Choose Add Library and click OK.</li>
<li>Select JUnit 3 and click Finish. </li>
</ol>
</ol>
<p>When configured in this way, your JUnit test class should now run properly.</p>

428
docs/html/guide/developing/app-signing.jd
View File

@@ -1,428 +0,0 @@
page.title=Signing Your Applications
@jd:body
<p>The Android system requires that all installed applications be digitally
signed with a certificate whose private key is held by the application's
developer. The system uses the certificate as a means of identifying the author of
an application and establishing trust relationships between applications, rather
than for controlling which applications the user can install. The certificate
does not need to be signed by a certificate authority: it is perfectly
allowable, and typical, for Android applications to use self-signed
certificates.</p>
<p>The important points to understand about signing Android applications are:</p>
<ul>
<li>All applications <em>must</em> be signed. The system will not install an application
that is not signed.</li>
<li>You can use self-signed certificates to sign your applications. No certificate authority
is needed.</li>
<li>When you are ready to publish your application, you must sign it with a suitable private
key. You can not publish an application that is signed with the default key generated
by the SDK tools.
</li>
<li>The system tests a signer certificate's expiration date only at install time. If an
application's signer certificate expires after the application is installed, the application
will continue to function normally.</li>
<li>You can use standard tools &mdash; Keytool and Jarsigner &mdash; to generate keys and
sign your application .apk files.</li>
</ul>
<p>The Android system will not install or run an application that is not signed appropriately. This
applies wherever the Android system is run, whether on an actual device or on the emulator.
For this reason, you must set up signing for your application before you will be able to
run or debug it on an emulator or device.</p>
<p>The Android SDK tools assist you in signing your applications when debugging. Both the ADT Plugin
for Eclipse and the Ant build tool offer two signing modes &mdash; debug mode and release mode.
<ul>
<li>In debug mode, the build tools use the Keytool utility, included in the JDK, to create
a keystore and key with a known alias and password. At each compilation, the tools then use
the debug key to sign the application .apk file. Because the password is known, the tools
don't need to prompt you for the keystore/key password each time you compile.</li>
<li>When your application is ready for release, you compile it in release signing mode.
In this mode, the tools compile your .apk <em>without</em> signing it. You must then sign
the .apk manually &mdash; <span style="color:red">with your private key</span> &mdash;
using Jarsigner (or similar tool). If you do not have a suitable private key already,
you can run Keytool manually to generate your own keystore/key and then sign your
application with Jarsigner.</li>
</ul>
<h2>Signing Strategies</h2>
<p>Some aspects of application signing may affect how you approach the development
of your application, especially if you are planning to release multiple
applications. </p>
<p>In general, the recommended strategy for all developers is to sign
all of your applications with the same certificate, throughout the expected
lifespan of your applications. There are several reasons why you should do so: </p>
<ul>
<li>Application upgrade &mdash; As you release upgrades to your
application, you will want to sign the upgrades with the same certificate, if you
want users to upgrade seamlessly to the new version. When the system is
installing an update to an application, if any of the certificates in the
new version match any of the certificates in the old version, then the
system allows the update. If you sign the version without using a matching
certificate, you will also need to assign a different package name to the
application &mdash; in this case, the user installs the new version as a
completely new application.
<li>Application modularity &mdash; The Android system allows applications that
are signed by the same certificate to run in the same process, if the
applications so request, so that the system treats them as a single application.
In this way you can deploy your application in modules, and users can update
each of the modules independently if needed.</li>
<li>Code/data sharing through permissions &mdash; The Android system provides
signature-based permissions enforcement, so that an application can expose
functionality to another application that is signed with a specified
certificate. By signing multiple applications with the same certificate and
using signature-based permissions checks, your applications can share code and
data in a secure manner. </li>
</li>
</ul>
<p>Another important consideration in determining your signing strategy is
how to set the validity period of the key that you will use to sign your
applications.</p>
<ul>
<li>If you plan to support upgrades for a single application, you should ensure
that your key has a validity period that exceeds the expected lifespan of
that application. A validity period of 25 years or more is recommended.
When your key's validity period expires, users will no longer be
able to seamlessly upgrade to new versions of your application.</li>
<li>If you will sign multiple distinct applications with the same key,
you should ensure that your key's validity period exceeds the expected
lifespan of <em>all versions of all of the applications</em>, including
dependent applications that may be added to the suite in the future. </li>
<li>If you plan to publish your application(s) on Android Market, the
key you use to sign the application(s) must have a validity period
ending after 22 October 2033. The Market server enforces this requirement
to ensure that users can seamlessly upgrade Market applications when
new versions are available. </li>
</ul>
<p>As you design your application, keep these points in mind and make sure to
use a <a href="#cert">suitable certificate</a> to sign your applications. </p>
<h2 id="setup">Basic Setup for Signing</h2>
<p>To support the generation of a keystore and debug key, you should first make sure that
Keytool is available to the SDK build
tools. In most cases, you can tell the SDK build tools how to find Keytool by making sure
that your JAVA_HOME environment variable is set and that it references a suitable JDK.
Alternatively, you can add the JDK version of Keytool to your PATH variable.</p>
<p>If you are developing on a version of Linux that originally came with GNU Compiler for
Java, make sure that the system is using the JDK version of Keytool, rather than the gcj
version. If Keytool is already in your PATH, it might be pointing to a symlink at
/usr/bin/keytool. In this case, check the symlink target to make sure that it points
to the Keytool in the JDK.</p>
<p>If you will release your application to the public, you will also need to have
the Jarsigner tool available on your machine. Both Jarsigner and Keytool are included
in the JDK. </p>
<h2>Signing in Debug Mode</h2>
<p>The Android build tools provide a debug signing mode that makes it easier for you
to develop and debug your application, while still meeting the Android system
requirement for signing your .apk when it is installed in the emulator or a device. </p>
<p>If you are developing in Eclipse/ADT and have set up Keytool as described
above, signing in debug mode is enabled by default. When you run or debug your
application, ADT signs the .apk for you and installs it on the emulator. No
specific action on your part is needed, provided ADT has access to Keytool.</p>
<p>If you use Ant to build your .apk files, debug signing mode
is enabled by default, assuming that you are using a build.xml file generated by the
activitycreator tool included in the latest SDK. When you run Ant against build.xml to
compile your app, the build script generates a keystore/key and signs the .apk for you.
No specific action on your part is needed.</p>
<p>Note that you can not release your application to the public if it is signed only with
the debug key. </p>
<h2>Signing for Public Release</h2>
<p>When your application is ready for release to other users, you must:</p>
<ol>
<li>Compile the application in release mode</li>
<li>Obtain a suitable private key, and then</li>
<li>Sign the application with your private key</li>
<li>Secure your private key</li>
</ol>
<p>The sections below provide information about these steps. </p>
<h3>Compiling for Release</h3>
<p>To prepare your application for release, you must first compile it in release mode.
In release mode, the Android build tools compile your application as usual,
but without signing it with the debug key. </p>
<p>If you are developing in Eclipse/ADT, right-click the project in the Package
pane and select <strong>Android Tools</strong> > <strong>Export Application
Package</strong>. You can then specify the file location for the unsigned .apk.
Alternatively, you can follow the "Exporting the unsigned .apk"
link in the Manifest Editor overview page. </p>
<p>If you are using Ant, all you need to do is specify the build target
"release" in the Ant command. For example, if you are running Ant from the
directory containing your build.xml file, the command would look like this:</p>
<pre>$ ant release</pre>
<p>The build script compiles the application .apk without signing it.
<p>Note that you can not release your application unsigned, or signed with the debug key.</p>
<h3 id="cert">Obtaining a Suitable Private Key</h3>
<p>In preparation for signing your application, you must first ensure that
you have a suitable private key with which to sign. A suitable private
key is one that:</p>
<ul>
<li>Is in your possession</li>
<li>Represents the personal, corporate, or organizational entity to be identified
with the application</li>
<li>Has a validity period that exceeds the expected lifespan of the application
or application suite. A validity period of more than 25 years is recommended.
<p>If you plan to publish your application(s) on Android Market, note that a
validity period ending after 22 October 2033 is a requirement. You can not upload an
application if it is signed with a key whose validity expires before that date.
</p></li>
<li>Is not the debug key generated by the Android SDK tools. </li>
</ul>
<p>The key may be self-signed. If you do not have a suitable key, you must
generate one using Keytool. Make sure that you have Keytool available, as described
in <a href="#setup">Basic Setup</a>.</p>
<p>To generate a self-signed key with Keytool, use the <code>keytool</code>
command and pass any of the options listed below (and any others, as
needed). </p>
<p class="warning">Before you run Keytool, make sure to read <a
href="#secure-key">Securing Your Key</a> for a discussion of how to keep your
key secure and why doing so is critically important to you and to users. In
particular, when you are generating your key, you should select strong
passwords for both the keystore and key.</p>
<table>
<tr>
<th>Keytool Option</th>
<th>Description</th>
</tr>
<tr>
<td><code>-genkey</code></td><td>Generate a key pair (public and private
keys)</td>
</tr>
<tr>
<td><code>-v</code></td><td>Enable verbose output.</td>
</tr>
<tr>
<td><code>-keystore&nbsp;&lt;keystore-name&gt;.keystore</code></td><td>A name
for the keystore containing the private key.</td>
</tr>
<tr>
<td><code>-storepass &lt;password&gt;</code></td><td><p>A password for the
keystore.</p><p>As a security precaution, do not include this option
in your command line unless you are working at a secure computer.
If not supplied, Keytool prompts you to enter the password. In this
way, your password is not stored in your shell history.</p></td>
</tr>
<tr>
<td><code>-alias &lt;alias_name&gt;</code></td><td>An alias for the key.</td>
</tr>
<tr>
<td><code>-keyalg &lt;alg&gt;</code></td><td>The encryption algorithm to use
when generating the key.</td>
</tr>
<tr>
<td><code>-dname &lt;name&gt;</code></td><td><p>A Distinguished Name that describes
who created the key. The value is used as the issuer and subject fields in the
self-signed certificate. </p><p>Note that you do not need to specify this option
in the command line. If not supplied, Jarsigner prompts you to enter each
of the Distinguished Name fields (CN, OU, and so on).</p></td>
</tr>
<tr>
<td><code>-validity &lt;valdays&gt;</code></td><td><p>The validity period for the
key, in days. </p><p><strong>Note:</strong> A value of 9500 or greater is recommended.</p></td>
</tr>
<tr>
<td><code>-keypass &lt;password&gt;</code></td><td><p>The password for the key.</p>
<p>As a security precaution, do not include this option
in your command line unless you are working at a secure computer.
If not supplied, Keytool prompts you to enter the password. In this
way, your password is not stored in your shell history.</p></td>
</tr>
</table>
<p>Here's an example of a Keytool command that generates a private key:</p>
<pre>$ keytool -genkey -v -keystore my-release-key.keystore
-alias alias_name -keyalg RSA -validity 9500</pre>
<p>Running the example command above, Keytool prompts you to provide
passwords for the keystore and key, and to provide the Distinguished
Name fields for your key. It then generates the keystore as a file called
<code>my-release-key.keystore</code>. The keystore and key are
protected by the passwords you entered. The keystore contains
a single key, valid for 9500 days. The alias is a name that you &mdash;
will use later, to refer to this keystore when signing your application. </p>
<p>For more information about Keytool, see the documentation at
<a
href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security">
http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a></p>
<h3>Signing Your Application</h3>
<p>When you are ready to actually sign your .apk for release, you can do so
using the Jarsigner tool. Make sure that you have Jarsigner available on your
machine, as described in <a href="#setup">Basic Setup</a>. Also, make sure that
the keystore containing your private key is available.</p>
<p>To sign your application, you run Jarsigner, referencing both the
application's .apk and the keystore containing the private key with which to
sign the .apk. The table below shows the options you could use. <p>
<table>
<tr>
<th>Jarsigner Option</th>
<th>Description</th>
</tr>
<tr>
<td><code>-keystore&nbsp;&lt;keystore-name&gt;.keystore</code></td><td>The name of
the keystore containing your private key.</td>
</tr>
<tr>
<td><code>-verbose</code></td><td>Enable verbose output.</td>
</tr>
<tr>
<td><code>-storepass &lt;password&gt;</code></td><td><p>The password for the
keystore. </p><p>As a security precaution, do not include this option
in your command line unless you are working at a secure computer.
If not supplied, Jarsigner prompts you to enter the password. In this
way, your password is not stored in your shell history.</p></td>
</tr>
<tr>
<td><code>-keypass &lt;password&gt;</code></td><td><p>The password for the private
key. </p><p>As a security precaution, do not include this option
in your command line unless you are working at a secure computer.
If not supplied, Jarsigner prompts you to enter the password. In this
way, your password is not stored in your shell history.</p></td>
</tr>
</table>
<p>Here's how you would use Jarsigner to sign an application package called
<code>my_application.apk</code>, using the example keystore created above.
</p>
<pre>$ jarsigner -verbose -keystore my-release-key.keystore
my_application.apk alias_name</pre>
<p>Running the example command above, Jarsigner prompts you to provide
passwords for the keystore and key. It then modifies the APK
in-place, meaning the .apk is now signed. Note that you can sign an
APK multiple times with different keys.</p>
<p>To verify that your .apk is signed, you can use a command like this:</p>
<pre>$ jarsigner -verify my_signed.apk</pre>
<p>If the .apk is signed properly, Jarsigner prints "jar verified".
If you want more details, you can try one of these commands:</p>
<pre>$ jarsigner -verify -verbose my_application.apk</pre>
<p>or</p>
<pre>$ jarsigner -verify -verbose -certs my_application.apk</pre>
<p>The command above, with the <code>-certs</code> option added, will show you the
"CN=" line that describes who created the key.</p>
<p class="note">Note: if you see "CN=Android Debug", this means the .apk was
signed with the debug key generated by the Android SDK. If you intend to release
your application, you must sign it with your private key instead of the debug
key.</p>
<p>For more information about Jarsigner, see the documentation at
<a href="http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security">
http://java.sun.com/j2se/1.5.0/docs/tooldocs/#security</a></p>
<h3 id="secure-key">Securing Your Private Key</h3>
<p>Maintaining the security of your private key is of critical importance, both
to you and to the user. If you allow someone to use your key, or if you leave
your keystore and passwords in an unsecured location such that a third-party
could find and use them, your authoring identity and the trust of the user
are compromised. </p>
<p>If a third party should manage to take your key without your knowledge or
permission, that person could sign and distribute applications that maliciously
replace your authentic applications or corrupt them. Such a person could also
sign and distribute applications under your identity that attack other
applications or the system itself, or corrupt or steal user data. </p>
<p>Your reputation as a developer entity depends on your securing your private
key properly, at all times, until the key is expired. Here are some tips for
keeping your key secure: </p>
<ul>
<li>Select strong passwords for the keystore and key.</li>
<li>When you generate your key with Keytool, <em>do not</em> supply the
<code>-storepass</code> and <code>-keypass</code> options at the command line.
If you do so, your passwords will be available in your shell history,
which any user on your computer could access.</li>
<li>Similarly, when signing your applications with Jarsigner,
<em>do not</em> supply the <code>-storepass</code> and <code>-keypass</code>
options at the command line. </li>
<li>Do not give or lend anyone your private key, and do not let unauthorized
persons know your keystore and key passwords.</li>
</ul>
<p>In general, if you follow common-sense precautions when generating, using,
and storing your key, it will remain secure. </p>
<h2>Expiry of the Debug Certificate</h2>
<p>The self-signed certificate used to sign your application in debug mode (the default on
Eclipse/ADT and Ant builds) will have an expiration date of 365 days from its creation date.</p>
<p>When the certificate expires, you will get a build error. On Ant builds, the error
looks like this:</p>
<pre>debug:
[echo] Packaging bin/samples-debug.apk, and signing it with a debug key...
[exec] Debug Certificate expired on 8/4/08 3:43 PM</pre>
<p>In Eclipse/ADT, you will see a similar error in the Android console.</p>
<p>To fix this problem, simply delete the <code>debug.keystore</code> file. On Linux/Mac OSX,
the file is stored in <code>~/.android</code>. OOn Windows XP, the file is stored in <code>
C:\Documents and Settings\&lt;user&gt;\Local Settings\Application Data\Android</code>.
On Windows Vista, the file is stored in <code>
C:\Users\&lt;user&gt;\AppData\Local\Android</code>.</p>
<p>The next time you build, the build tools will regenerate a new keystore and debug key.</p>
<p>Note that, if your development machine is using a non-Gregorian locale, the build
tools may erroneously generate an already-expired debug certificate, so that you get an
error when trying to compile your application. For workaround information, see the
troubleshooting topic <a href="{@docRoot}kb/troubleshooting.html#signingcalendar">
I&nbsp;can't&nbsp;compile my app because the build tools generated an expired debug
certificate</a>. </p>

12
docs/html/guide/developing/tools/avd.jd
View File

@@ -21,13 +21,12 @@ page.title=Android Virtual Devices
<li><a href="#createavd">Creating the AVD</a></li>
<li><a href="#hardwareopts">Setting hardware emulation options</a></li>
<li><a href="#location">Default location of the AVD files</a></li>
<li><a href="#createavdopts">Command-line options, create avd</a></li>
</ol>
</li>
<li><a href="#managing">Managing AVDs</a>
<ol>
<li><a href="#moving">Moving an AVD</a></li>
<li><a href="#updating">Deleting an AVD</a></li>
<li><a href="#updating">Updating an AVD</a></li>
<li><a href="#deleting">Deleting an AVD</a></li>
</ol>
</li>
@@ -35,7 +34,8 @@ page.title=Android Virtual Devices
</ol>
<h2>See Also</h2>
<ol>
<li>Android <a href="{@docRoot}guide/developing/tools/emulator.html">Emulator</a></li>
<li><a href="{@docRoot}guide/developing/tools/emulator.html">Android
Emulator</a></li>
</ol>
</div>
</div>
@@ -366,6 +366,10 @@ the <code>-p</code> option to place the AVD directory in another location.
The AVD's .ini file remains in the .android directory on the network
drive, regardless of the location of the AVD directory. </p>
<h2 id="managing">Managing AVDs</h2>
<p>The sections below provide more information about how to manage AVDs once you've created them. </p>
<h3 id="moving">Moving an AVD</h3>
<p>If you want to move or rename an AVD, you can do so using this command:</p>
@@ -455,7 +459,7 @@ files.</td>
</tr>
<tr>
<td><code>-s &lt;name&gt;</code> or <br>
<code>-s &lt;dimensions&gt;</code> </td>
<code>-s &lt;width&gt;-&lt;height&gt;</code> </td>
<td>The skin to use for this AVD, identified by name or dimensions.</td>
<td>The android tool scans for a matching skin by name or dimension in the
<code>skins/</code> directory of the target referenced in the <code>-t

2
docs/html/guide/topics/media/index.jd
View File

@@ -9,7 +9,7 @@ page.title=Audio and Video
<li>Audio playback and record</li>
<li>Video playback</li>
<li>Handles data from raw resources, files, streams</li>
<li>Built-in codecs for a variety of media. See <a href="{@docRoot}guide/appendix/media-formats.html">Android 1.0 Media Formats</a></li>
<li>Built-in codecs for a variety of media. See <a href="{@docRoot}guide/appendix/media-formats.html">Android Supported Media Formats</a></li>
</ul>
<h2>Key classes</h2>

172
docs/html/guide/topics/media/media.jd
View File

@@ -1,172 +0,0 @@
page.title=Media Capabilities
@jd:body
<div class="sidebox">
<h3>Media Quickview</h3>
<h4>Built-in capabilities</h4>
<ul>
<li>Audio playback and record</li>
<li>Video playback</li>
</ul>
<h4>Data sources</h4>
<ul>
<li>Raw resources</li>
<li>Data files</li>
<li>Streams</li>
</ul>
<h4>Media Formats</h4>
<ul>
<li>See appendix <a href="{@docRoot}devguide/appendix/media_formats.html">Android 1.0 Media Formats</a></li>
</ul>
<h4>Key APIs</h4>
<ul>
<li>{@link android.media.MediaPlayer} (playback, all audio and video formats)</li>
<li>{@link android.media.MediaRecorder} (record, all audio formats)</li>
</ul>
</div>
<p>The Android platform offers built-in encoding/decoding for a variety of common media types,
so that you can easily integrate audio, video, and images into your applications. Accessing the platform's media
capabilities is fairly straightforward &mdash you do so using the same intents and
activities mechanism that the rest of Android uses.</p>
<p>Android lets you play audio and video from several types of data sources. You can play audio or video from media files stored in the application's resources (raw resources), from standalone files in the filesystem, or from a data stream arriving over a network connection. To play audio or video from your application, use the {@link android.media.MediaPlayer} class.</p>
<p>The platform also lets you record audio, where supported by the mobile device hardware. Recording of video is not currently supported, but is planned for a future release. To record audio, use the
{@link android.media.MediaRecorder} class. Note that the emulator doesn't have hardware to capture audio, but actual mobile devices are likely to provide these capabilities that you can access through MediaRecorder. </p>
<p>For a list of the media formats for which Android offers built-in support, see the <a href="{@docRoot}devguide/appendix/media_formats.html">Android Media Formats</a> appendix. </p>
<h2>Playing Audio and Video</h2>
<p>Media can be played from anywhere: from a raw resource, from a file from the system,
or from an available network (URL).</p>
<p>You can play back the audio data only to the standard
output device; currently, that is the mobile device speaker or Bluetooth headset. You
cannot play sound files in the conversation audio. </p>
<h3>Playing from a Raw Resource</h3>
<p>Perhaps the most common thing to want to do is play back media (notably sound)
within your own applications. Doing this is easy:</p>
<ol>
<li>Put the sound (or other media resource) file into the <code>res/raw</code>
folder of your project, where the Eclipse plugin (or aapt) will find it and
make it into a resource that can be referenced from your R class</li>
<li>Create an instance of <code>MediaPlayer</code>, referencing that resource using
{@link android.media.MediaPlayer#create MediaPlayer.create}, and then call
{@link android.media.MediaPlayer#start() start()} on the instance:<br><br></li>
</ol>
<pre>
MediaPlayer mp = MediaPlayer.create(context, R.raw.sound_file_1);
mp.start();
</pre>
<p>To stop playback, call {@link android.media.MediaPlayer#stop() stop()}. If
you wish to later replay the media, then you must
{@link android.media.MediaPlayer#reset() reset()} and
{@link android.media.MediaPlayer#prepare() prepare()} the MediaPlayer object
before calling {@link android.media.MediaPlayer#start() start()} again.
(<code>create()</code> calls <code>prepare()</code> the first time.)</p>
<p>To pause playback, call {@link android.media.MediaPlayer#pause() pause()}.
Resume playback from where you paused with
{@link android.media.MediaPlayer#start() start()}.</p>
<h3>Playing from a File or Stream</h3>
<p>You can play back media files from the filesystem or a web URL:</p>
<ol>
<li>Create an instance of the <code>MediaPlayer</code> using <code>new</code></li>
<li>Call {@link android.media.MediaPlayer#setDataSource setDataSource()}
with a String containing the path (local filesystem or URL)
to the file you want to play</li>
<li>First {@link android.media.MediaPlayer#prepare prepare()} then
{@link android.media.MediaPlayer#start() start()} on the instance:<br><br></li>
</ol>
<pre>
MediaPlayer mp = new MediaPlayer();
mp.setDataSource(PATH_TO_FILE);
mp.prepare();
mp.start();
</pre>
<p>{@link android.media.MediaPlayer#stop() stop()} and
{@link android.media.MediaPlayer#pause() pause()} work the same as discussed
above.</p>
<p class="note"><strong>Note:</strong> It is possible that <code>mp</code> could be
null, so good code should <code>null</code> check after the <code>new</code>.
Also, <code>IllegalArgumentException</code> and <code>IOException</code> either
need to be caught or passed on when using <code>setDataSource()</code>, since
the file you are referencing may not exist.</p>
<p class="note"><strong>Note:</strong>
If you're passing a URL to an online media file, the file must be capable of
progressive download.</p>
<h2>Recording Media Resources</h2>
<p>Recording media is a little more involved than playing it back, as you would
probably expect, but it is still fairly simple. There is just a little more set
up to do</p>
<ol>
<li>Create a new instance of {@link android.media.MediaRecorder
android.media.MediaRecorder} using <code>new</code></li>
<li>Create a new instance of {@link android.content.ContentValues
android.content.ContentValues} and put in some standard properties like
<code>TITLE</code>, <code>TIMESTAMP</code>, and the all important
<code>MIME_TYPE</code></li>
<li>Create a file path for the data to go to (you can use {@link
android.content.ContentResolver android.content.ContentResolver} to
create an entry in the Content database and get it to assign a path
automatically which you can then use)</li>
<li>Set the audio source using {@link android.media.MediaRecorder#setAudioSource
MediaRecorder.setAudioSource()}. You will probably want to use
<code>MediaRecorder.AudioSource.MIC</code></li>
<li>Set output file format using {@link
android.media.MediaRecorder#setOutputFormat MediaRecorder.setOutputFormat()}
</li>
<li>Set the audio encoder using
{@link android.media.MediaRecorder#setAudioEncoder MediaRecorder.setAudioEncoder()}
</li>
<li>Finally, {@link android.media.MediaRecorder#prepare prepare()} and
{@link android.media.MediaRecorder#start start()} the recording.
{@link android.media.MediaRecorder#stop stop()} and
{@link android.media.MediaRecorder#release release()} when you are done</li>
</ol>
<p>Here is a code example that will hopefully help fill in the gaps:</p>
<p><strong>Start Recording</strong></p>
<pre>
recorder = new MediaRecorder();
ContentValues values = new ContentValues(3);
values.put(MediaStore.MediaColumns.TITLE, SOME_NAME_HERE);
values.put(MediaStore.MediaColumns.TIMESTAMP, System.currentTimeMillis());
values.put(MediaStore.MediaColumns.MIME_TYPE, recorder.getMimeContentType());
ContentResolver contentResolver = new ContentResolver();
Uri base = MediaStore.Audio.INTERNAL_CONTENT_URI;
Uri newUri = contentResolver.insert(base, values);
if (newUri == null) {
// need to handle exception here - we were not able to create a new
// content entry
}
String path = contentResolver.getDataFilePath(newUri);
// could use setPreviewDisplay() to display a preview to suitable View here
recorder.setAudioSource(MediaRecorder.AudioSource.MIC);
recorder.setOutputFormat(MediaRecorder.OutputFormat.THREE_GPP);
recorder.setAudioEncoder(MediaRecorder.AudioEncoder.AMR_NB);
recorder.setOutputFile(path);
recorder.prepare();
recorder.start();
</pre>
<p><strong>Stop Recording</strong></p>
<pre>
recorder.stop();
recorder.release();
</pre>