diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/html/guide/practices/design/performance.jd | 223 | ||||
| -rwxr-xr-x | docs/html/guide/topics/resources/localization.jd | 12 | ||||
| -rw-r--r-- | docs/html/guide/topics/security/security.jd | 76 | ||||
| -rw-r--r-- | docs/html/images/axis_device.png | bin | 0 -> 17625 bytes | |||
| -rw-r--r-- | docs/html/images/axis_globe.png | bin | 0 -> 8306 bytes | |||
| -rw-r--r-- | docs/html/sdk/adt_download.jd | 4 | ||||
| -rw-r--r-- | docs/html/sdk/android-1.5.jd | 4 | ||||
| -rw-r--r-- | docs/html/sdk/android-1.6.jd | 4 | ||||
| -rw-r--r-- | docs/html/sdk/android-2.0.1.jd | 4 | ||||
| -rw-r--r-- | docs/html/sdk/android-2.0.jd | 4 | ||||
| -rw-r--r-- | docs/html/sdk/android-2.1.jd | 3 | ||||
| -rw-r--r-- | docs/html/sdk/android-2.2.jd | 2 | ||||
| -rw-r--r-- | docs/html/sdk/eclipse-adt.jd | 4 | ||||
| -rw-r--r-- | docs/knowntags.txt | 38 |
14 files changed, 139 insertions, 239 deletions
diff --git a/docs/html/guide/practices/design/performance.jd b/docs/html/guide/practices/design/performance.jd index 3e7c671..f5588ac 100644 --- a/docs/html/guide/practices/design/performance.jd +++ b/docs/html/guide/practices/design/performance.jd @@ -48,188 +48,39 @@ outside the scope of this document.</p> <h2 id="optimize_judiciously">Optimize Judiciously</h2> -<p>As you get started thinking about how to design your application, and as -you write it, consider -the cautionary points about optimization that Josh Bloch makes in his book -<em>Effective Java</em>. Here's "Item 47: Optimize Judiciously", excerpted from -the latest edition of the book with permission. Although Josh didn't have -Android application development in mind when writing this section — for -example, the <code style="color:black">java.awt.Component</code> class -referenced is not available in Android, and Android uses the -Dalvik VM, rather than a standard JVM — his points are still valid. </p> - -<blockquote> - -<p>There are three aphorisms concerning optimization that everyone should know. -They are perhaps beginning to suffer from overexposure, but in case you aren't -yet familiar with them, here they are:</p> - -<div style="padding-left:3em;padding-right:4em;"> - -<p style="margin-bottom:.5em;">More computing sins are committed in the name of -efficiency (without necessarily achieving it) than for any other single -reason—including blind stupidity.</p> -<p>—William A. Wulf <span style="font-size:80%;"><sup>1</sup></span></p> - -<p style="margin-bottom:.5em;">We should forget about small efficiencies, say -about 97% of the time: premature optimization is the root of all evil. </p> -<p>—Donald E. Knuth <span style="font-size:80%;"><sup>2</sup></span></p> - - -<p style="margin-bottom:.5em;">We follow two rules in the matter of optimization:</p> -<ul style="margin-bottom:0"> -<li>Rule 1. Don't do it.</li> -<li>Rule 2 (for experts only). Don't do it yet — that is, not until you have a -perfectly clear and unoptimized solution. </li> -</ul> -<p>—M. A. Jackson <span style="font-size:80%;"><sup>3</sup></span></p> -</div> - -<p>All of these aphorisms predate the Java programming language by two decades. -They tell a deep truth about optimization: it is easy to do more harm than good, -especially if you optimize prematurely. In the process, you may produce software -that is neither fast nor correct and cannot easily be fixed.</p> - -<p>Don't sacrifice sound architectural principles for performance. -<strong>Strive to write good programs rather than fast ones.</strong> If a good -program is not fast enough, its architecture will allow it to be optimized. Good -programs embody the principle of <em>information hiding</em>: where possible, -they localize design decisions within individual modules, so individual -decisions can be changed without affecting the remainder of the system (Item -13).</p> - -<p>This does <em>not</em> mean that you can ignore performance concerns until -your program is complete. Implementation problems can be fixed by later -optimization, but pervasive architectural flaws that limit performance can be -impossible to fix without rewriting the system. Changing a fundamental facet of -your design after the fact can result in an ill-structured system that is -difficult to maintain and evolve. Therefore you must think about performance -during the design process.</p> - -<p><strong>Strive to avoid design decisions that limit performance.</strong> The -components of a design that are most difficult to change after the fact are -those specifying interactions between modules and with the outside world. Chief -among these design components are APIs, wire-level protocols, and persistent -data formats. Not only are these design components difficult or impossible to -change after the fact, but all of them can place significant limitations on the -performance that a system can ever achieve.</p> - -<p><strong>Consider the performance consequences of your API design -decisions.</strong> Making a public type mutable may require a lot of needless -defensive copying (Item 39). Similarly, using inheritance in a public class -where composition would have been appropriate ties the class forever to its -superclass, which can place artificial limits on the performance of the subclass -(Item 16). As a final example, using an implementation type rather than an -interface in an API ties you to a specific implementation, even though faster -implementations may be written in the future (Item 52).</p> - -<p>The effects of API design on performance are very real. Consider the <code -style="color:black">getSize</code> method in the <code -style="color:black">java.awt.Component</code> class. The decision that this -performance-critical method was to return a <code -style="color:black">Dimension</code> instance, coupled with the decision that -<code style="color:black">Dimension</code> instances are mutable, forces any -implementation of this method to allocate a new <code -style="color:black">Dimension</code> instance on every invocation. Even though -allocating small objects is inexpensive on a modern VM, allocating millions of -objects needlessly can do real harm to performance.</p> - -<p>In this case, several alternatives existed. Ideally, <code -style="color:black">Dimension</code> should have been immutable (Item 15); -alternatively, the <code style="color:black">getSize</code> method could have -been replaced by two methods returning the individual primitive components of a -<code style="color:black">Dimension</code> object. In fact, two such methods -were added to the Component API in the 1.2 release for performance reasons. -Preexisting client code, however, still uses the <code -style="color:black">getSize</code> method and still suffers the performance -consequences of the original API design decisions.</p> - -<p>Luckily, it is generally the case that good API design is consistent with -good performance. <strong>It is a very bad idea to warp an API to achieve good -performance.</strong> The performance issue that caused you to warp the API may -go away in a future release of the platform or other underlying software, but -the warped API and the support headaches that come with it will be with you for -life.</p> - -<p>Once you've carefully designed your program and produced a clear, concise, -and well-structured implementation, <em>then</em> it may be time to consider -optimization, assuming you're not already satisfied with the performance of the -program.</p> - -<p>Recall that Jackson's two rules of optimization were "Don't do it," and "(for -experts only). Don't do it yet." He could have added one more: <strong>measure -performance before and after each attempted optimization.</strong> You may be -surprised by what you find. Often, attempted optimizations have no measurable -effect on performance; sometimes, they make it worse. The main reason is that -it's difficult to guess where your program is spending its time. The part of the -program that you think is slow may not be at fault, in which case you'd be -wasting your time trying to optimize it. Common wisdom says that programs spend -80 percent of their time in 20 percent of their code.</p> - -<p>Profiling tools can help you decide where to focus your optimization efforts. -Such tools give you runtime information, such as roughly how much time each -method is consuming and how many times it is invoked. In addition to focusing -your tuning efforts, this can alert you to the need for algorithmic changes. If -a quadratic (or worse) algorithm lurks inside your program, no amount of tuning -will fix the problem. You must replace the algorithm with one that is more -efficient. The more code in the system, the more important it is to use a -profiler. It's like looking for a needle in a haystack: the bigger the haystack, -the more useful it is to have a metal detector. The JDK comes with a simple -profiler and modern IDEs provide more sophisticated profiling tools.</p> - -<p>The need to measure the effects of attempted optimization is even greater on -the Java platform than on more traditional platforms, because the Java -programming language does not have a strong <em>performance model</em>. The -relative costs of the various primitive operations are not well defined. The -"semantic gap" between what the programmer writes and what the CPU executes is -far greater than in traditional statically compiled languages, which makes it -very difficult to reliably predict the performance consequences of any -optimization. There are plenty of performance myths floating around that turn -out to be half-truths or outright lies.</p> - -<p>Not only is Java's performance model ill-defined, but it varies from JVM -implementation to JVM implementation, from release to release, and from -processor to processor. If you will be running your program on multiple JVM -implementations or multiple hardware platforms, it is important that you measure -the effects of your optimization on each. Occasionally you may be forced to make -trade-offs between performance on different JVM implementations or hardware -platforms.</p> - -<p>To summarize, do not strive to write fast programs — strive to write -good ones; speed will follow. Do think about performance issues while you're -designing systems and especially while you're designing APIs, wire-level -protocols, and persistent data formats. When you've finished building the -system, measure its performance. If it's fast enough, you're done. If not, -locate the source of the problems with the aid of a profiler, and go to work -optimizing the relevant parts of the system. The first step is to examine your -choice of algorithms: no amount of low-level optimization can make up for a poor -choice of algorithm. Repeat this process as necessary, measuring the performance -after every change, until you're satisfied.</p> - -<p>—Excerpted from Josh Bloch's <em>Effective Java</em>, Second Ed. -(Addison-Wesley, 2008).</em></p> - -<p style="font-size:80%;margin-bottom:0;"><sup>1</sup> Wulf, W. A Case Against -the GOTO. <em>Proceedings of the 25th ACM National -Conference</em> 2 (1972): 791–797.</p> -<p style="font-size:80%;margin-bottom:0;"><sup>2</sup> Knuth, Donald. Structured -Programming with go to Statements. <em>Computing -Surveys 6</em> (1974): 261–301.</p> -<p style="font-size:80%"><sup>3</sup> Jackson, M. A. <em>Principles of Program -Design</em>, Academic Press, London, 1975. -ISBN: 0123790506.</p> - -</blockquote> - -<p>One of the trickiest problems you'll face when micro-optimizing Android -apps is that the "if you will be running your program on ... multiple hardware -platforms" clause above is always true. And it's not even generally the case -that you can say "device X is a factor F faster/slower than device Y". -This is especially true if one of the devices is the emulator, or one of the -devices has a JIT. If you want to know how your app performs on a given device, -you need to test it on that device. Drawing conclusions from the emulator is -particularly dangerous, as is attempting to compare JIT versus non-JIT -performance: the performance <em>profiles</em> can differ wildly.</p> +<p>This document is about Android-specific micro-optimization, so it assumes +that you've already used profiling to work out exactly what code needs to be +optimized, and that you already have a way to measure the effect (good or bad) +of any changes you make. You only have so much engineering time to invest, so +it's important to know you're spending it wisely. + +<p>(See <a href="#closing_notes">Closing Notes</a> for more on profiling and +writing effective benchmarks.) + +<p>This document also assumes that you made the best decisions about data +structures and algorithms, and that you've also considered the future +performance consequences of your API decisions. Using the right data +structures and algorithms will make more difference than any of the advice +here, and considering the performance consequences of your API decisions will +make it easier to switch to better implementations later (this is more +important for library code than for application code). + +<p>(If you need that kind of advice, see Josh Bloch's <em>Effective Java</em>, +item 47.)</p> + +<p>One of the trickiest problems you'll face when micro-optimizing an Android +app is that your app is pretty much guaranteed to be running on multiple +hardware platforms. Different versions of the VM running on different +processors running at different speeds. It's not even generally the case +that you can simply say "device X is a factor F faster/slower than device Y", +and scale your results from one device to others. In particular, measurement +on the emulator tells you very little about performance on any device. There +are also huge differences between devices with and without a JIT: the "best" +code for a device with a JIT is not always the best code for a device +without.</p> + +<p>If you want to know how your app performs on a given device, you need to +test on that device.</p> <a name="object_creation"></a> <h2>Avoid Creating Objects</h2> @@ -572,3 +423,11 @@ of its way to do the hard work for you, and even detect some cases where you're not measuring what you think you're measuring (because, say, the VM has managed to optimize all your code away). We highly recommend you use Caliper to run your own microbenchmarks.</p> + +<p>You may also find +<a href="{@docRoot}guide/developing/tools/traceview.html">Traceview</a> useful +for profiling, but it's important to realize that it currently disables the JIT, +which may cause it to misattribute time to code that the JIT may be able to win +back. It's especially important after making changes suggested by Traceview +data to ensure that the resulting code actually runs faster when run without +Traceview. diff --git a/docs/html/guide/topics/resources/localization.jd b/docs/html/guide/topics/resources/localization.jd index 3d630c9..36e12f6 100755 --- a/docs/html/guide/topics/resources/localization.jd +++ b/docs/html/guide/topics/resources/localization.jd @@ -433,12 +433,12 @@ Menu > Settings > Locale & text > Select locale). </p> href="{@docRoot}guide/developing/tools/emulator.html">Android Emulator</a>.</p>
<h4>Creating and using a custom locale</h4>
-<p>A "custom" locale is a language/region combination that the
-Android system image does not explicitly support. (For a list of supported
-locales, see the <a href="{@docRoot}sdk/android-{@sdkCurrentVersion}.html">Android
-Version Notes</a>.) You can test how your application will run in a custom
-locale by creating a custom locale in the emulator. There are two ways to do
-this:</p>
+<p>A "custom" locale is a language/region combination that the Android
+system image does not explicitly support. (For a list of supported locales in
+Android platforms see the Version Notes in the <a
+href="{@docRoot}sdk/index.html">SDK</a> tab). You can test
+how your application will run in a custom locale by creating a custom locale in
+the emulator. There are two ways to do this:</p>
<ul>
<li>Use the Custom Locale application, which is accessible from the
diff --git a/docs/html/guide/topics/security/security.jd b/docs/html/guide/topics/security/security.jd index dbc9866..de0c6e5 100644 --- a/docs/html/guide/topics/security/security.jd +++ b/docs/html/guide/topics/security/security.jd @@ -21,14 +21,15 @@ page.title=Security and Permissions </div> </div> -<p>Android is a multi-process system, in which each application (and parts of the -system) runs in its own process. Most security between applications and -the system is enforced at the process level through standard Linux facilities, -such as user and group IDs that are assigned to applications. -Additional finer-grained security features are provided -through a "permission" mechanism that enforces restrictions on the specific -operations that a particular process can perform, and per-URI permissions -for granting ad-hoc access to specific pieces of data.</p> +<p>Android is a privilege-separated operating system, in which each +application runs with a distinct system identity (Linux user ID and group +ID). Parts of the system are also separated into distinct identities. +Linux thereby isolates applications from each other and from the system.</p> + +<p>Additional finer-grained security features are provided through a +"permission" mechanism that enforces restrictions on the specific operations +that a particular process can perform, and per-URI permissions for granting +ad-hoc access to specific pieces of data.</p> <a name="arch"></a> <h2>Security Architecture</h2> @@ -38,39 +39,46 @@ application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing -network access, keeping the device awake, etc.<p> - -<p>An application's process runs in a security sandbox. The sandbox is designed -to prevent applications from disrupting each other, except by explicitly -declaring the <em>permissions</em> they need for additional capabilities not -provided by the basic sandbox. The system handles requests for permissions -in various ways, typically by automatically allowing or disallowing based on -certificates or by prompting the user. The permissions required by an -application are declared statically in that application, so they can be known -up-front at install time and will not change after that.</p> +network access, keeping the device awake, etc.</p> + +<p>Because the kernel sandboxes applications from each other, applications +must explicitly share resources and data. They do this by declaring the +<em>permissions</em> they need for additional capabilities not provided by +the basic sandbox. Applications statically declare the permissions they +require, and the Android system prompts the user for consent at the time the +application is installed. Android has no mechanism for granting permissions +dynamically (at run-time) because it complicates the user experience to the +detriment of security.</p> + +<p>The kernel is solely responsible for sandboxing applications from each +other. In particular the Dalvik VM is not a security boundary, and any app +can run native code (see <a href="/sdk/ndk/index.html">the Android NDK</a>). +All types of applications — Java, native, and hybrid — are +sandboxed in the same way and have the same degree of security from each +other.</p> <a name="signing"></a> <h2>Application Signing</h2> -<p>All Android applications (.apk files) must be signed with a certificate whose -private key is held by their developer. This certificate identifies the author -of the application. The certificate does <em>not</em> need to be signed by -a certificate authority: it is perfectly allowable, and typical, for Android -applications to use self-signed certificates. The certificate is used only -to establish trust relationships between applications, not for wholesale -control over whether an application can be installed. The most significant -ways that signatures impact security is by determining who can access -signature-based permissions and who can share user IDs.</p> - +<p>All Android applications (.apk files) must be signed with a certificate +whose private key is held by their developer. This certificate identifies +the author of the application. The certificate does <em>not</em> need to be +signed by a certificate authority: it is perfectly allowable, and typical, +for Android applications to use self-signed certificates. The purpose of +certificates in Android is to distinguish application authors. This allows +the system to grant or deny applications access to <a +href="/guide/topics/manifest/permission-element.html#plevel">signature-level +permissions</a> and to grant or deny an application's <a +href="/guide/topics/manifest/manifest-element.html#uid">request to be given +the same Linux identity</a> as another application.</p> <a name="userid"></a> <h2>User IDs and File Access</h2> -<p>Each Android package (.apk) file installed on the device is given its -own unique Linux user ID, creating a sandbox for it and preventing it from touching -other applications (or other applications from touching it). This user ID is -assigned to it when the application is installed on the device, and -remains constant for the duration of its life on that device.</p> +<p>At install time, Android gives each package a distinct Linux user ID. The +identity remains constant for the duration of the package's life on that +device. On a different device, the same package may have a different UID; +what matters is that each package has a distinct UID on a given device.</p> <p>Because security enforcement happens at the process level, the code of any two packages can not normally @@ -150,7 +158,7 @@ activities of other applications.</li> <li>Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.</li> <li>When accessing and operating on a content provider.</li> -<li>Binding or starting a service.</li> +<li>Binding to or starting a service.</li> </ul> diff --git a/docs/html/images/axis_device.png b/docs/html/images/axis_device.png Binary files differnew file mode 100644 index 0000000..f1f666a --- /dev/null +++ b/docs/html/images/axis_device.png diff --git a/docs/html/images/axis_globe.png b/docs/html/images/axis_globe.png Binary files differnew file mode 100644 index 0000000..dccb58b --- /dev/null +++ b/docs/html/images/axis_globe.png diff --git a/docs/html/sdk/adt_download.jd b/docs/html/sdk/adt_download.jd index 8220d91..3da576a 100644 --- a/docs/html/sdk/adt_download.jd +++ b/docs/html/sdk/adt_download.jd @@ -24,8 +24,8 @@ ADT Installation</a>.</p> <tr> <td>0.9.9</td> <td><a href="http://dl-ssl.google.com/android/ADT-0.9.9.zip">ADT-0.9.9.zip</a></td> - <td><nobr>{@adtZipBytes} bytes</nobr></td> - <td>{@adtZipChecksum}</td> + <td><nobr>8301681 bytes</nobr></td> + <td>7deff0c9b25940a74cea7a0815a3bc36</td> <td>Requires SDK Tools, Revision 7 <em><nobr>September 2010</nobr></em></td> </tr> <tr> diff --git a/docs/html/sdk/android-1.5.jd b/docs/html/sdk/android-1.5.jd index 0c16b60..9ed798c 100644 --- a/docs/html/sdk/android-1.5.jd +++ b/docs/html/sdk/android-1.5.jd @@ -2,8 +2,6 @@ page.title=Android 1.5 Platform sdk.platform.version=1.5 sdk.platform.apiLevel=3 sdk.platform.majorMinor=major -sdk.platform.releaseDate=April 2009 -sdk.platform.deployableDate=May 2009 @jd:body @@ -43,7 +41,7 @@ Differences Report »</a> </li> <em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p> <p>Android {@sdkPlatformVersion} is a {@sdkPlatformMajorMinor} platform release -deployable to Android-powered handsets starting in {@sdkPlatformDeployableDate}. +deployable to Android-powered handsets starting in May 2009. The release includes new features for users and developers, as well as changes in the Android framework API. </p> diff --git a/docs/html/sdk/android-1.6.jd b/docs/html/sdk/android-1.6.jd index c4e08ff..a01a5f6 100644 --- a/docs/html/sdk/android-1.6.jd +++ b/docs/html/sdk/android-1.6.jd @@ -2,8 +2,6 @@ page.title=Android 1.6 Platform sdk.platform.version=1.6 sdk.platform.apiLevel=4 sdk.platform.majorMinor=minor -sdk.platform.releaseDate=December 2009 -sdk.platform.deployableDate=October 2009 @jd:body @@ -43,7 +41,7 @@ Differences Report »</a> </li> <em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p> <p>Android {@sdkPlatformVersion} is a {@sdkPlatformMajorMinor} platform release -deployable to Android-powered handsets since {@sdkPlatformDeployableDate}. +deployable to Android-powered handsets since October 2009. The platform includes new features for users and developers, as well as changes in the Android framework API. </p> diff --git a/docs/html/sdk/android-2.0.1.jd b/docs/html/sdk/android-2.0.1.jd index cacb6bf..0c8afb6 100644 --- a/docs/html/sdk/android-2.0.1.jd +++ b/docs/html/sdk/android-2.0.1.jd @@ -2,8 +2,6 @@ page.title=Android 2.0.1, Release 1 sdk.platform.version=2.0.1 sdk.platform.apiLevel=6 sdk.platform.majorMinor=minor -sdk.platform.releaseDate=December 2009 -sdk.platform.deployableDate=December 2009 @jd:body @@ -44,7 +42,7 @@ differences report »</a> </li> <em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p> <p>Android {@sdkPlatformVersion} is a {@sdkPlatformMajorMinor} platform release -deployable to Android-powered handsets starting in {@sdkPlatformDeployableDate}. +deployable to Android-powered handsets starting in December 2009. This release includes minor API changes, bug fixes and framework behavioral changes. For information on changes and fixes, see the <a href="#api">Framework API</a> section.</p> diff --git a/docs/html/sdk/android-2.0.jd b/docs/html/sdk/android-2.0.jd index a430f34..2c31923 100644 --- a/docs/html/sdk/android-2.0.jd +++ b/docs/html/sdk/android-2.0.jd @@ -2,8 +2,6 @@ page.title=Android 2.0, Release 1 sdk.platform.version=2.0 sdk.platform.apiLevel=5 sdk.platform.majorMinor=major -sdk.platform.releaseDate=October 2009 -sdk.platform.deployableDate=November 2009 @jd:body @@ -38,7 +36,7 @@ sdk.platform.deployableDate=November 2009 <em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p> <p>Android {@sdkPlatformVersion} is a {@sdkPlatformMajorMinor} platform release -deployable to Android-powered handsets starting in {@sdkPlatformDeployableDate}. +deployable to Android-powered handsets starting in November 2009. The release includes new features for users and developers, as well as changes in the Android framework API. </p> diff --git a/docs/html/sdk/android-2.1.jd b/docs/html/sdk/android-2.1.jd index cd48a72..6eba6f0 100644 --- a/docs/html/sdk/android-2.1.jd +++ b/docs/html/sdk/android-2.1.jd @@ -2,7 +2,6 @@ page.title=Android 2.1 Platform sdk.platform.version=2.1 sdk.platform.apiLevel=7 sdk.platform.majorMinor=minor -sdk.platform.deployableDate=January 2010 @jd:body @@ -42,7 +41,7 @@ Differences Report »</a> </li> <em>API Level:</em> <strong>{@sdkPlatformApiLevel}</strong></p> <p>Android {@sdkPlatformVersion} is a {@sdkPlatformMajorMinor} platform release -deployable to Android-powered handsets starting in {@sdkPlatformDeployableDate}. +deployable to Android-powered handsets starting in January 2010. This release includes new API changes and bug fixes. For information on changes, see the <a href="#api">Framework API</a> section.</p> diff --git a/docs/html/sdk/android-2.2.jd b/docs/html/sdk/android-2.2.jd index baae92e..495fd80 100644 --- a/docs/html/sdk/android-2.2.jd +++ b/docs/html/sdk/android-2.2.jd @@ -466,4 +466,4 @@ emulator skins are:</p> <p>For more information about how to develop an application that displays and functions properly on all Android-powered devices, see <a href="{@docRoot}guide/practices/screens_support.html">Supporting Multiple -Screens</a>.</p>
\ No newline at end of file +Screens</a>.</p> diff --git a/docs/html/sdk/eclipse-adt.jd b/docs/html/sdk/eclipse-adt.jd index 00db2ec..9f3c8b0 100644 --- a/docs/html/sdk/eclipse-adt.jd +++ b/docs/html/sdk/eclipse-adt.jd @@ -1,5 +1,9 @@ page.title=ADT Plugin for Eclipse sdk.preview=0 +adt.zip.version=0.9.9 +adt.zip.download=ADT-0.9.9.zip +adt.zip.bytes=8301681 +adt.zip.checksum=7deff0c9b25940a74cea7a0815a3bc36 @jd:body diff --git a/docs/knowntags.txt b/docs/knowntags.txt new file mode 100644 index 0000000..5bebabb --- /dev/null +++ b/docs/knowntags.txt @@ -0,0 +1,38 @@ +# Copyright (C) 2010 The Android Open Source Project +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. + +# +# The grandfathered list. We should get rid of these if possible. +# +@ToBeFixed +@stable +@com.intel.drl.spec_ref +@ar.org.fitc.spec_ref + +# Something about CTS? +@cts + +# Auto-generated info about the SDK +@sdkCurrent +@sdkCurrentVersion +@sdkCurrentRelId +@sdkPlatformVersion +@sdkPlatformApiLevel +@sdkPlatformMajorMinor +@sdkPlatformReleaseDate +@sdkPlatformDeployableDate +@adtZipVersion +@adtZipDownload +@adtZipBytes +@adtZipChecksum |
