From 22cc2764cc74e52888b043e0c6371594305bb5e9 Mon Sep 17 00:00:00 2001 From: Scott Main Date: Wed, 7 Nov 2012 16:35:16 -0800 Subject: [PATCH] implement new organization for Training classes This also moves a few of the documents from API Guides > Best Practices into the new courses for best practices. This is also dependent on CL Ieac8a97a8d6fda41a3682241901150cfe16afc4d which generates the list of classes/lessons on each course landing page. Change-Id: I8132f72f78d844c3b035c7aa269ad3b88a25d02a --- docs/html/guide/guide_toc.cs | 19 - .../guide/practices/app-design/responsiveness.jd | 140 --- docs/html/guide/practices/performance.jd | 410 --------- docs/html/guide/practices/responsiveness.jd | 140 --- docs/html/guide/practices/security.jd | 767 ---------------- docs/html/images/anr.png | Bin 13005 -> 16412 bytes docs/html/training/best-performance.jd | 8 + docs/html/training/best-security.jd | 9 + docs/html/training/best-ux.jd | 12 + docs/html/training/building-connectivity.jd | 10 + docs/html/training/building-graphics.jd | 11 + docs/html/training/building-multimedia.jd | 9 + docs/html/training/building-userinfo.jd | 9 + docs/html/training/distribute.jd | 9 + docs/html/training/index.jd | 16 +- docs/html/training/perf-anr.jd | 196 +++++ .../practices/jni.jd => training/perf-jni.jd} | 4 +- .../performance.jd => training/perf-tips.jd} | 379 ++++---- docs/html/training/security-tips.jd | 759 ++++++++++++++++ docs/html/training/training_toc.cs | 960 +++++++++++++-------- 20 files changed, 1834 insertions(+), 2033 deletions(-) delete mode 100644 docs/html/guide/practices/app-design/responsiveness.jd delete mode 100644 docs/html/guide/practices/performance.jd delete mode 100644 docs/html/guide/practices/responsiveness.jd delete mode 100644 docs/html/guide/practices/security.jd create mode 100644 docs/html/training/best-performance.jd create mode 100644 docs/html/training/best-security.jd create mode 100644 docs/html/training/best-ux.jd create mode 100644 docs/html/training/building-connectivity.jd create mode 100644 docs/html/training/building-graphics.jd create mode 100644 docs/html/training/building-multimedia.jd create mode 100644 docs/html/training/building-userinfo.jd create mode 100644 docs/html/training/distribute.jd create mode 100644 docs/html/training/perf-anr.jd rename docs/html/{guide/practices/jni.jd => training/perf-jni.jd} (99%) rename docs/html/{guide/practices/app-design/performance.jd => training/perf-tips.jd} (56%) create mode 100644 docs/html/training/security-tips.jd diff --git a/docs/html/guide/guide_toc.cs b/docs/html/guide/guide_toc.cs index 46c4398c0699..d875f47fc939 100644 --- a/docs/html/guide/guide_toc.cs +++ b/docs/html/guide/guide_toc.cs @@ -529,25 +529,6 @@
  • Supporting Tablets and Handsets
    • -
  • -
    - Designing for Performance -
    - -
    • -
  • - Designing for Responsiveness -
    • -
  • - Designing for Seamlessness -
    • -
  • - Designing for Security -
    • diff --git a/docs/html/guide/practices/app-design/responsiveness.jd b/docs/html/guide/practices/app-design/responsiveness.jd deleted file mode 100644 index a00e3aa65114..000000000000 --- a/docs/html/guide/practices/app-design/responsiveness.jd +++ /dev/null @@ -1,140 +0,0 @@ -page.title=Designing for Responsiveness -@jd:body - -
    - -
    - -
    -Screenshot of ANR dialog box -

    Figure 1. An ANR dialog displayed to the user.

    -
    - -

    It's possible to write code that wins every performance test in the world, -but still sends users in a fiery rage when they try to use the application. -These are the applications that aren't responsive enough — the -ones that feel sluggish, hang or freeze for significant periods, or take too -long to process input.

    - -

    In Android, the system guards against applications that are insufficiently -responsive for a period of time by displaying a dialog to the user, called the -Application Not Responding (ANR) dialog, shown at right in Figure 1. The user -can choose to let the application continue, but the user won't appreciate having -to act on this dialog every time he or she uses your application. It's critical -to design responsiveness into your application, so that the system never has -cause to display an ANR dialog to the user.

    - -

    Generally, the system displays an ANR if an application cannot respond to -user input. For example, if an application blocks on some I/O operation -(frequently a network access), then the main application thread won't be able to -process incoming user input events. After a time, the system concludes that the -application is frozen, and displays the ANR to give the user the option to kill -it.

    - -

    Similarly, if your application spends too much time building an elaborate in-memory -structure, or perhaps computing the next move in a game, the system will -conclude that your application has hung. It's always important to make -sure these computations are efficient using the techniques above, but even the -most efficient code still takes time to run.

    - -

    In both of these cases, the recommended approach is to create a child thread and do -most of your work there. This keeps the main thread (which drives the user -interface event loop) running and prevents the system from concluding that your code -has frozen. Since such threading usually is accomplished at the class -level, you can think of responsiveness as a class problem. (Compare -this with basic performance, which was described above as a method-level -concern.)

    - -

    This document describes how the Android system determines whether an -application is not responding and provides guidelines for ensuring that your -application stays responsive.

    - -

    What Triggers ANR?

    - -

    In Android, application responsiveness is monitored by the Activity Manager -and Window Manager system services. Android will display the ANR dialog -for a particular application when it detects one of the following -conditions:

    - - -

    How to Avoid ANR

    - -

    Given the above definition for ANR, let's examine why this can occur in -Android applications and how best to structure your application to avoid ANR.

    - -

    Android applications normally run entirely on a single (i.e. main) thread. -This means that anything your application is doing in the main thread that -takes a long time to complete can trigger the ANR dialog because your -application is not giving itself a chance to handle the input event or Intent -broadcast.

    - -

    Therefore any method that runs in the main thread should do as little work -as possible. In particular, Activities should do as little as possible to set -up in key life-cycle methods such as onCreate() and -onResume(). Potentially long running operations such as network -or database operations, or computationally expensive calculations such as -resizing bitmaps should be done in a child thread (or in the case of databases -operations, via an asynchronous request). However, this does not mean that -your main thread should block while waiting for the child thread to -complete — nor should you call Thread.wait() or -Thread.sleep(). Instead of blocking while waiting for a child -thread to complete, your main thread should provide a {@link -android.os.Handler Handler} for child threads to post back to upon completion. -Designing your application in this way will allow your main thread to remain -responsive to input and thus avoid ANR dialogs caused by the 5 second input -event timeout. These same practices should be followed for any other threads -that display UI, as they are also subject to the same timeouts.

    - -

    You can use {@link android.os.StrictMode} to help find potentially -long running operations such as network or database operations that -you might accidentally be doing your main thread.

    - -

    The specific constraint on IntentReceiver execution time emphasizes what -they were meant to do: small, discrete amounts of work in the background such -as saving a setting or registering a Notification. So as with other methods -called in the main thread, applications should avoid potentially long-running -operations or calculations in BroadcastReceivers. But instead of doing intensive -tasks via child threads (as the life of a BroadcastReceiver is short), your -application should start a {@link android.app.Service Service} if a -potentially long running action needs to be taken in response to an Intent -broadcast. As a side note, you should also avoid starting an Activity from an -Intent Receiver, as it will spawn a new screen that will steal focus from -whatever application the user is currently has running. If your application -has something to show the user in response to an Intent broadcast, it should -do so using the {@link android.app.NotificationManager Notification -Manager}.

    - -

    Reinforcing Responsiveness

    - -

    Generally, 100 to 200ms is the threshold beyond which users will perceive -lag (or lack of "snappiness," if you will) in an application. As such, here -are some additional tips beyond what you should do to avoid ANR that will help -make your application seem responsive to users.

    - - diff --git a/docs/html/guide/practices/performance.jd b/docs/html/guide/practices/performance.jd deleted file mode 100644 index 078999becc39..000000000000 --- a/docs/html/guide/practices/performance.jd +++ /dev/null @@ -1,410 +0,0 @@ -page.title=Designing for Performance -@jd:body - -
    - -
    - -

    An Android application will run on a mobile device with limited computing -power and storage, and constrained battery life. Because of -this, it should be efficient. Battery life is one reason you might -want to optimize your app even if it already seems to run "fast enough". -Battery life is important to users, and Android's battery usage breakdown -means users will know if your app is responsible draining their battery.

    - -

    Note that although this document primarily covers micro-optimizations, -these will almost never make or break your software. Choosing the right -algorithms and data structures should always be your priority, but is -outside the scope of this document.

    - - -

    Introduction

    - -

    There are two basic rules for writing efficient code:

    - - -

    Optimize Judiciously

    - -

    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. - -

    (See Closing Notes for more on profiling and -writing effective benchmarks.) - -

    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). - -

    (If you need that kind of advice, see Josh Bloch's Effective Java, -item 47.)

    - -

    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.

    - -

    If you want to know how your app performs on a given device, you need to -test on that device.

    - - -

    Avoid Creating Unnecessary Objects

    - -

    Object creation is never free. A generational GC with per-thread allocation -pools for temporary objects can make allocation cheaper, but allocating memory -is always more expensive than not allocating memory.

    - -

    If you allocate objects in a user interface loop, you will force a periodic -garbage collection, creating little "hiccups" in the user experience. The -concurrent collector introduced in Gingerbread helps, but unnecessary work -should always be avoided.

    - -

    Thus, you should avoid creating object instances you don't need to. Some -examples of things that can help:

    - - - -

    A somewhat more radical idea is to slice up multidimensional arrays into -parallel single one-dimension arrays:

    - - - -

    Generally speaking, avoid creating short-term temporary objects if you -can. Fewer objects created mean less-frequent garbage collection, which has -a direct impact on user experience.

    - - - -

    Performance Myths

    - -

    Previous versions of this document made various misleading claims. We -address some of them here.

    - -

    On devices without a JIT, it is true that invoking methods via a -variable with an exact type rather than an interface is slightly more -efficient. (So, for example, it was cheaper to invoke methods on a -HashMap map than a Map map, even though in both -cases the map was a HashMap.) It was not the case that this -was 2x slower; the actual difference was more like 6% slower. Furthermore, -the JIT makes the two effectively indistinguishable.

    - -

    On devices without a JIT, caching field accesses is about 20% faster than -repeatedly accesssing the field. With a JIT, field access costs about the same -as local access, so this isn't a worthwhile optimization unless you feel it -makes your code easier to read. (This is true of final, static, and static -final fields too.) - - -

    Prefer Static Over Virtual

    - -

    If you don't need to access an object's fields, make your method static. -Invocations will be about 15%-20% faster. -It's also good practice, because you can tell from the method -signature that calling the method can't alter the object's state.

    - - -

    Avoid Internal Getters/Setters

    - -

    In native languages like C++ it's common practice to use getters (e.g. -i = getCount()) instead of accessing the field directly (i -= mCount). This is an excellent habit for C++, because the compiler can -usually inline the access, and if you need to restrict or debug field access -you can add the code at any time.

    - -

    On Android, this is a bad idea. Virtual method calls are expensive, -much more so than instance field lookups. It's reasonable to follow -common object-oriented programming practices and have getters and setters -in the public interface, but within a class you should always access -fields directly.

    - -

    Without a JIT, direct field access is about 3x faster than invoking a -trivial getter. With the JIT (where direct field access is as cheap as -accessing a local), direct field access is about 7x faster than invoking a -trivial getter. This is true in Froyo, but will improve in the future when -the JIT inlines getter methods.

    - -

    Note that if you're using ProGuard, you can have the best -of both worlds because ProGuard can inline accessors for you.

    - - -

    Use Static Final For Constants

    - -

    Consider the following declaration at the top of a class:

    - -
    static int intVal = 42;
-static String strVal = "Hello, world!";
    - -

    The compiler generates a class initializer method, called -<clinit>, that is executed when the class is first used. -The method stores the value 42 into intVal, and extracts a -reference from the classfile string constant table for strVal. -When these values are referenced later on, they are accessed with field -lookups.

    - -

    We can improve matters with the "final" keyword:

    - -
    static final int intVal = 42;
-static final String strVal = "Hello, world!";
    - -

    The class no longer requires a <clinit> method, -because the constants go into static field initializers in the dex file. -Code that refers to intVal will use -the integer value 42 directly, and accesses to strVal will -use a relatively inexpensive "string constant" instruction instead of a -field lookup. (Note that this optimization only applies to primitive types and -String constants, not arbitrary reference types. Still, it's good -practice to declare constants static final whenever possible.)

    - - -

    Use Enhanced For Loop Syntax

    - -

    The enhanced for loop (also sometimes known as "for-each" loop) can be used -for collections that implement the Iterable interface and for arrays. -With collections, an iterator is allocated to make interface calls -to hasNext() and next(). With an ArrayList, a hand-written counted loop is -about 3x faster (with or without JIT), but for other collections the enhanced -for loop syntax will be exactly equivalent to explicit iterator usage.

    - -

    There are several alternatives for iterating through an array:

    - -
        static class Foo {
-        int mSplat;
-    }
-    Foo[] mArray = ...
-
-    public void zero() {
-        int sum = 0;
-        for (int i = 0; i < mArray.length; ++i) {
-            sum += mArray[i].mSplat;
-        }
-    }
-
-    public void one() {
-        int sum = 0;
-        Foo[] localArray = mArray;
-        int len = localArray.length;
-
-        for (int i = 0; i < len; ++i) {
-            sum += localArray[i].mSplat;
-        }
-    }
-
-    public void two() {
-        int sum = 0;
-        for (Foo a : mArray) {
-            sum += a.mSplat;
-        }
-    }
-
    - -

    zero() is slowest, because the JIT can't yet optimize away -the cost of getting the array length once for every iteration through the -loop.

    - -

    one() is faster. It pulls everything out into local -variables, avoiding the lookups. Only the array length offers a performance -benefit.

    - -

    two() is fastest for devices without a JIT, and -indistinguishable from one() for devices with a JIT. -It uses the enhanced for loop syntax introduced in version 1.5 of the Java -programming language.

    - -

    To summarize: use the enhanced for loop by default, but consider a -hand-written counted loop for performance-critical ArrayList iteration.

    - -

    (See also Effective Java item 46.)

    - - -

    Consider Package Instead of Private Access with Private Inner Classes

    - -

    Consider the following class definition:

    - -
    public class Foo {
-    private class Inner {
-        void stuff() {
-            Foo.this.doStuff(Foo.this.mValue);
-        }
-    }
-
-    private int mValue;
-
-    public void run() {
-        Inner in = new Inner();
-        mValue = 27;
-        in.stuff();
-    }
-
-    private void doStuff(int value) {
-        System.out.println("Value is " + value);
-    }
-}
    - -

    The key things to note here are that we define a private inner class -(Foo$Inner) that directly accesses a private method and a private -instance field in the outer class. This is legal, and the code prints "Value is -27" as expected.

    - -

    The problem is that the VM considers direct access to Foo's -private members from Foo$Inner to be illegal because -Foo and Foo$Inner are different classes, even though -the Java language allows an inner class to access an outer class' private -members. To bridge the gap, the compiler generates a couple of synthetic -methods:

    - -
    /*package*/ static int Foo.access$100(Foo foo) {
-    return foo.mValue;
-}
-/*package*/ static void Foo.access$200(Foo foo, int value) {
-    foo.doStuff(value);
-}
    - -

    The inner class code calls these static methods whenever it needs to -access the mValue field or invoke the doStuff method -in the outer class. What this means is that the code above really boils down to -a case where you're accessing member fields through accessor methods. -Earlier we talked about how accessors are slower than direct field -accesses, so this is an example of a certain language idiom resulting in an -"invisible" performance hit.

    - -

    If you're using code like this in a performance hotspot, you can avoid the -overhead by declaring fields and methods accessed by inner classes to have -package access, rather than private access. Unfortunately this means the fields -can be accessed directly by other classes in the same package, so you shouldn't -use this in public API.

    - - -

    Use Floating-Point Judiciously

    - -

    As a rule of thumb, floating-point is about 2x slower than integer on -Android devices. This is true on a FPU-less, JIT-less G1 and a Nexus One with -an FPU and the JIT. (Of course, absolute speed difference between those two -devices is about 10x for arithmetic operations.)

    - -

    In speed terms, there's no difference between float and -double on the more modern hardware. Space-wise, double -is 2x larger. As with desktop machines, assuming space isn't an issue, you -should prefer double to float.

    - -

    Also, even for integers, some chips have hardware multiply but lack -hardware divide. In such cases, integer division and modulus operations are -performed in software — something to think about if you're designing a -hash table or doing lots of math.

    - - -

    Know And Use The Libraries

    - -

    In addition to all the usual reasons to prefer library code over rolling -your own, bear in mind that the system is at liberty to replace calls -to library methods with hand-coded assembler, which may be better than the -best code the JIT can produce for the equivalent Java. The typical example -here is String.indexOf and friends, which Dalvik replaces with -an inlined intrinsic. Similarly, the System.arraycopy method -is about 9x faster than a hand-coded loop on a Nexus One with the JIT.

    - -

    (See also Effective Java item 47.)

    - - -

    Use Native Methods Judiciously

    - -

    Native code isn't necessarily more efficient than Java. For one thing, -there's a cost associated with the Java-native transition, and the JIT can't -optimize across these boundaries. If you're allocating native resources (memory -on the native heap, file descriptors, or whatever), it can be significantly -more difficult to arrange timely collection of these resources. You also -need to compile your code for each architecture you wish to run on (rather -than rely on it having a JIT). You may even have to compile multiple versions -for what you consider the same architecture: native code compiled for the ARM -processor in the G1 can't take full advantage of the ARM in the Nexus One, and -code compiled for the ARM in the Nexus One won't run on the ARM in the G1.

    - -

    Native code is primarily useful when you have an existing native codebase -that you want to port to Android, not for "speeding up" parts of a Java app.

    - -

    If you do need to use native code, you should read our -JNI Tips.

    - -

    (See also Effective Java item 54.)

    - - -

    Closing Notes

    - -

    One last thing: always measure. Before you start optimizing, make sure you -have a problem. Make sure you can accurately measure your existing performance, -or you won't be able to measure the benefit of the alternatives you try.

    - -

    Every claim made in this document is backed up by a benchmark. The source -to these benchmarks can be found in the code.google.com "dalvik" project.

    - -

    The benchmarks are built with the -Caliper microbenchmarking -framework for Java. Microbenchmarks are hard to get right, so Caliper goes out -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.

    - -

    You may also find -Traceview 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/practices/responsiveness.jd b/docs/html/guide/practices/responsiveness.jd deleted file mode 100644 index a00e3aa65114..000000000000 --- a/docs/html/guide/practices/responsiveness.jd +++ /dev/null @@ -1,140 +0,0 @@ -page.title=Designing for Responsiveness -@jd:body - -

    - -
    - -
    -Screenshot of ANR dialog box -

    Figure 1. An ANR dialog displayed to the user.

    -
    - -

    It's possible to write code that wins every performance test in the world, -but still sends users in a fiery rage when they try to use the application. -These are the applications that aren't responsive enough — the -ones that feel sluggish, hang or freeze for significant periods, or take too -long to process input.

    - -

    In Android, the system guards against applications that are insufficiently -responsive for a period of time by displaying a dialog to the user, called the -Application Not Responding (ANR) dialog, shown at right in Figure 1. The user -can choose to let the application continue, but the user won't appreciate having -to act on this dialog every time he or she uses your application. It's critical -to design responsiveness into your application, so that the system never has -cause to display an ANR dialog to the user.

    - -

    Generally, the system displays an ANR if an application cannot respond to -user input. For example, if an application blocks on some I/O operation -(frequently a network access), then the main application thread won't be able to -process incoming user input events. After a time, the system concludes that the -application is frozen, and displays the ANR to give the user the option to kill -it.

    - -

    Similarly, if your application spends too much time building an elaborate in-memory -structure, or perhaps computing the next move in a game, the system will -conclude that your application has hung. It's always important to make -sure these computations are efficient using the techniques above, but even the -most efficient code still takes time to run.

    - -

    In both of these cases, the recommended approach is to create a child thread and do -most of your work there. This keeps the main thread (which drives the user -interface event loop) running and prevents the system from concluding that your code -has frozen. Since such threading usually is accomplished at the class -level, you can think of responsiveness as a class problem. (Compare -this with basic performance, which was described above as a method-level -concern.)

    - -

    This document describes how the Android system determines whether an -application is not responding and provides guidelines for ensuring that your -application stays responsive.

    - -

    What Triggers ANR?

    - -

    In Android, application responsiveness is monitored by the Activity Manager -and Window Manager system services. Android will display the ANR dialog -for a particular application when it detects one of the following -conditions:

    - - -

    How to Avoid ANR

    - -

    Given the above definition for ANR, let's examine why this can occur in -Android applications and how best to structure your application to avoid ANR.

    - -

    Android applications normally run entirely on a single (i.e. main) thread. -This means that anything your application is doing in the main thread that -takes a long time to complete can trigger the ANR dialog because your -application is not giving itself a chance to handle the input event or Intent -broadcast.

    - -

    Therefore any method that runs in the main thread should do as little work -as possible. In particular, Activities should do as little as possible to set -up in key life-cycle methods such as onCreate() and -onResume(). Potentially long running operations such as network -or database operations, or computationally expensive calculations such as -resizing bitmaps should be done in a child thread (or in the case of databases -operations, via an asynchronous request). However, this does not mean that -your main thread should block while waiting for the child thread to -complete — nor should you call Thread.wait() or -Thread.sleep(). Instead of blocking while waiting for a child -thread to complete, your main thread should provide a {@link -android.os.Handler Handler} for child threads to post back to upon completion. -Designing your application in this way will allow your main thread to remain -responsive to input and thus avoid ANR dialogs caused by the 5 second input -event timeout. These same practices should be followed for any other threads -that display UI, as they are also subject to the same timeouts.

    - -

    You can use {@link android.os.StrictMode} to help find potentially -long running operations such as network or database operations that -you might accidentally be doing your main thread.

    - -

    The specific constraint on IntentReceiver execution time emphasizes what -they were meant to do: small, discrete amounts of work in the background such -as saving a setting or registering a Notification. So as with other methods -called in the main thread, applications should avoid potentially long-running -operations or calculations in BroadcastReceivers. But instead of doing intensive -tasks via child threads (as the life of a BroadcastReceiver is short), your -application should start a {@link android.app.Service Service} if a -potentially long running action needs to be taken in response to an Intent -broadcast. As a side note, you should also avoid starting an Activity from an -Intent Receiver, as it will spawn a new screen that will steal focus from -whatever application the user is currently has running. If your application -has something to show the user in response to an Intent broadcast, it should -do so using the {@link android.app.NotificationManager Notification -Manager}.

    - -

    Reinforcing Responsiveness

    - -

    Generally, 100 to 200ms is the threshold beyond which users will perceive -lag (or lack of "snappiness," if you will) in an application. As such, here -are some additional tips beyond what you should do to avoid ANR that will help -make your application seem responsive to users.

    - - diff --git a/docs/html/guide/practices/security.jd b/docs/html/guide/practices/security.jd deleted file mode 100644 index ce59a9dd494f..000000000000 --- a/docs/html/guide/practices/security.jd +++ /dev/null @@ -1,767 +0,0 @@ -page.title=Designing for Security -@jd:body - -
    -
    -

    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.

    - -

    Some of the security features that help developers build secure applications -include: -

    - -

    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.

    - -

    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.

    - - -

    Using Dalvik Code

    -

    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: -

    - -

    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: -

    - - -

    Using Native Code

    - -

    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.

    - -

    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 -http://www.dwheeler.com/secure-programs.

    - -

    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 Android Security -Overview and you should be familiar with application permissions even if -you are using native code.

    - - -

    Storing Data

    - -

    Using internal files

    - -

    By default, files created on internal -storage are only accessible to the application that created the file. This -protection is implemented by Android and is sufficient for most -applications.

    - -

    Use of -world writable or world -readable 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.

    - -

    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 file system -encryption.

    - -

    Using external storage

    - -

    Files created on external -storage, 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.

    - -

    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.

    - -

    Using content providers

    - -

    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 - -ContentProvider is -exported - for use by other applications. If you do not intend to provide other -applications with access to your - -ContentProvider, mark them as -android:exported=false in the application manifest.

    - -

    When creating a -ContentProvider - that will be exported for use by other applications, you can specify -a single -permission - 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.

    - -

    If you are using a - -ContentProvider for sharing data between applications built by the -same developer, it is preferable to use -signature -level permissions. Signature permissions do not require user confirmation, -so they provide a better user experience and more controlled access to the - - -ContentProvider.

    - -

    ContentProviders can also provide more granular access by declaring the -grantUriPermissions element and using the FLAG_GRANT_READ_URI_PERMISSION -and FLAG_GRANT_WRITE_URI_PERMISSION -flags in the Intent object -that activates the component. The scope of these permissions can be further -limited by the -grant-uri-permission element.

    - -

    When accessing a - -ContentProvider, use parameterized query methods such as -query(), update(), and delete() to avoid -potential SQL -Injection from untrusted data. Note that using parameterized methods is not -sufficient if the selection is built by concatenating user data -prior to submitting it to the method.

    - -

    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 WHERE 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.

    - - -

    Using Interprocess Communication (IPC)

    - -

    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.

    - -

    Many of the security elements are shared across IPC mechanisms. -Broadcast Receivers, -Activities, and -Services are all declared in the application manifest. If your IPC mechanism is -not intended for use by other applications, set the {@code android:exported} -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.

    - -

    If your IPC is intended to be accessible to other applications, you can -apply a security policy by using the -Permission tag. If IPC is between applications built by the same developer, -it is preferable to use signature -level permissions. Signature permissions do not require user confirmation, -so they provide a better user experience and more controlled access to the IPC -mechanism.

    - -

    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.

    - -

    Using intents

    - -

    Intents are the preferred mechanism for asynchronous IPC in Android. -Depending on your application requirements, you might use sendBroadcast(), -sendOrderedBroadcast(), -or direct an intent to a specific application component.

    - -

    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.

    - -

    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.

    - -

    Using binder and AIDL interfaces

    - -

    Binders 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.

    - -

    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.

    - -

    If providing an interface that does require access controls, use checkCallingPermission() -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 bindService() - invocation may fail if you do not have permission to access the given Service. - If calling an interface provided locally by your own application, it may be -useful to use the -clearCallingIdentity() to satisfy internal security checks.

    - -

    Using broadcast receivers

    - -

    Broadcast receivers are used to handle asynchronous requests initiated via -an intent.

    - -

    By default, receivers are exported and can be invoked by any other -application. If your -BroadcastReceivers is intended for use by other applications, you -may want to apply security permissions to receivers using the -<receiver> element within the application manifest. This will -prevent applications without appropriate permissions from sending an intent to -the -BroadcastReceivers.

    - -

    Using Services

    - -

    Services are often used to supply functionality for other applications to -use. Each service class must have a corresponding declaration in its -package's AndroidManifest.xml.

    - -

    By default, Services are exported and can be invoked by any other -application. Services can be protected using the {@code android:permission} -attribute -within the manifest’s -<service> tag. By doing so, other applications will need to declare -a corresponding <uses-permission> - element in their own manifest to be -able to start, stop, or bind to the service.

    - -

    A Service can protect individual IPC calls into it with permissions, by -calling checkCallingPermission() -before executing -the implementation of that call. We generally recommend using the -declarative permissions in the manifest, since those are less prone to -oversight.

    - -

    Using Activities

    - -

    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.

    - -

    If you do expose an Activity for purposes of IPC, the android:permission -attribute in the -<activity> declaration in the application manifest can be used to -restrict access to only those applications which have the stated -permissions.

    - - -

    Using Permissions

    - -

    Requesting Permissions

    - -

    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.

    - -

    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 GUID 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.

    - -

    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: -http://www.eecs.berkeley.edu/Pubs/TechRpts/2011/EECS-2011-48.pdf

    - -

    In addition to requesting permissions, your application can use permissions -to protect IPC that is security sensitive and will be exposed to other -applications -- such as a -ContentProvider. 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 signature -protection level on permissions for IPC communication between applications -provided by a single developer.

    - -

    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: http://www.cs.be -rkeley.edu/~afelt/felt_usenixsec2011.pdf

    - -

    Creating Permissions

    - -

    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 system-defined -permissions cover many situations. Where appropriate, -perform access checks using existing permissions.

    - -

    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.

    - -

    If you create a Dangerous permission, there are a number of complexities -that you need to consider. -

    - -

    Each of these poses a significant non-technical challenge for an application -developer, which is why we discourage the use of Dangerous permission.

    - - -

    Using Networking

    - -

    Using IP Networking

    - -

    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 HTTPS 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.

    - -

    Authenticated, encrypted socket-level communication can be easily -implemented using the SSLSocket -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.

    - -

    We have seen some applications use localhost 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.)

    - -

    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 WebView and -any responses to intents issued against HTTP.

    - -

    Using Telephony Networking

    - -

    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 C2DM and IP networking for -sending data messages to devices.

    - -

    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.

    - - -

    Dynamically Loading Code

    - -

    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.

    - -

    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.

    - -

    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 - -DexClassLoader. We have seen many instances of applications -attempting to load code from insecure locations, such as downloaded from the -network over unencrypted protocols or from world writable locations such as -external storage. These locations could allow someone on the network to modify -the content in transit, or another application on a users device to modify the -content, respectively.

    - - -

    Using WebView

    - -

    Since WebView consumes web content that can include HTML and JavaScript, -improper use can introduce common web security issues such as cross-site-scripting (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.

    - -

    If your application does not directly use JavaScript within a WebView, do -not call - -setJavaScriptEnabled(). We have seen this method invoked -in sample code that might be repurposed in production application -- so -remove it if necessary. By default, WebView does -not execute JavaScript so cross-site-scripting is not possible.

    - -

    Use addJavaScriptInterface() with -particular care because it allows JavaScript to invoke operations that are -normally reserved for Android applications. Only expose addJavaScriptInterface() 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 addJavaScriptInterface() to -JavaScript that is contained within your application APK.

    - -

    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 MiTM attacks -and interception of data. Sensitive capabilities using addJavaScriptInterface() should -not ever be exposed to unverified script downloaded over HTTP. Note that even -with the use of HTTPS, -addJavaScriptInterface() -increases the attack surface of your application to include the server -infrastructure and all CAs trusted by the Android-powered device.

    - -

    If your application accesses sensitive data with a WebView, you -may want to use the -clearCache() 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.

    - - -

    Performing Input Validation

    - -

    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.

    - -

    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 buffer overflows, use after -free, and off-by-one errors. -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.

    - -

    Dynamic, string based languages such as JavaScript and SQL are also subject -to input validation problems due to escape characters and script injection.

    - -

    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.

    - -

    If you are using WebView, then -you must consider the possibility of XSS. If your application does not -directly use JavaScript within a WebView, do -not call setJavaScriptEnabled() and XSS is no longer possible. If you must -enable JavaScript then the WebView section provides other security best -practices.

    - -

    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.

    - - -

    Handling User Data

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    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.

    - -

    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 Android Developer Blog.

    - -

    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 - -READ_LOGS permission. Even though the phone log data -is temporary and erased on reboot, inappropriate logging of user information -could inadvertently leak user data to other applications.

    - - -

    Handling Credentials

    - -

    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.

    - -

    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.

    - -

    Services that will be accessible to multiple applications should be accessed -using - -AccountManager. If possible, use the -AccountManager class to invoke a cloud-based service and do not store -passwords on the device.

    - -

    After using -AccountManager to retrieve an Account, check the CREATOR - before passing in any credentials, so that you do not inadvertently pass -credentials to the wrong application.

    - -

    If credentials are to be used only by applications that you create, then you -can verify the application which accesses the -AccountManager using checkSignature(). -Alternatively, if only one application will use the credential, you might use a -{@link java.security.KeyStore} for -storage.

    - - -

    Using Cryptography

    - -

    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.

    - -

    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 - -HttpsURLConnection or SSLSocket, -rather than writing your own protocol.

    - -

    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 Cipher class.

    - -

    Use a secure random number generator ( - -SecureRandom) to initialize any cryptographic keys ( -KeyGenerator). Use of a key that is not generated with a secure random -number generator significantly weakens the strength of the algorithm, and may -allow offline attacks.

    - -

    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.

    - -

    Conclusion

    - -

    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.

    - -

    You can receive more information on these topics and discuss security best -practices with other developers in the Android Security -Discuss Google Group

    diff --git a/docs/html/images/anr.png b/docs/html/images/anr.png index f6e16ef2156fc2f7091506c1785d01ef74ef8f82..46520ef7727e8f6a88ad56f75cb2afc749d9395c 100644 GIT binary patch literal 16412 zcmX9_2RxVS+qY%U>=lt@lTBprk&tY%XW1j0WRqQ1Mv|Gm%H|-HQDn>4{ zV3y={X_02$#vs+P;ctDHaUAKjEi9m>&Yz6)_Ap?d#QL4+>c6@p!!NZ*hJ%9{0`E}f z-No8@@mod<2VaQ6-%@&c@&81-pC*3UJr>U4?)6xX?rrug`V!Yh?o%LpfkV+9t*3U5UQA^6TTtl0~bg8lTyfh~oL(dekV49gX7T#<$_o z_o_Jk63yJi-sNZ9&QvnN)TlJvdB$Z%718*~x5wk5_amo(0G{uE?pdK_$Oj9~3}pNq zs2aTr5>J%FRhVyZmMfo&qN#|)LJ!)ld*L^ID9%4Tsj;N`0>|2m)FA!3Hl#9m-)1K+LeCdnEAAa=HJIgf9 zGH`d)b}r()jrr9*orc|vqqnA`1){ahly}FdLMFQCUhU#C%d3ot(8UQ+^0t4QlWwq( z!&KwtVbmBI7l>d=IB<$}rwET$qBl;yAsE@(I6l3vgnr0eo3^ru+u?gI{wA3Di-X-k zkrH#b>Q@Xr-1Fyh7%XaiU&_5L{S;~HX|a~n8${>`>jPT}lIpi5vBzjvnC+#~D89Lg z+VZzyyyD4wc*RDtKI$5iXWXKcU4<_90e<{Oh%{yl&t}hbIq~2^jjfIci_f*KpTg~j z8!R~P5qqDs&idw#vkh?vsuTLH=1(7ZVCmml+W1AX%Up}yx3Mn7hNeJ_VZcctC@kD* z{aJn}ZhQ)d+*YP`+~Sp7*z+OSWMPvd#NI%sbnn(1!9fP)3bebJ;jf!X=Mkl-bs{qeSV>0gl4Ri9iMO zVK#ir1HENdD7SsAvFRP1?ssa-Q7vE7m2}gcXK5Ck^6KyNP!TBHhDveT3?qF* zgJUw5p>!LI?TrK-a^!CL)b_qlayB+)zjQdvkQ^;zr6X6%7qomH%{9!{}gvVDSJ zpM7nIbA2-=6(2r&)(}?dIL#O}QFJ$2){uf`ry*x*u4Z@Axi}qR`jB<~33_BFYU%i2 zArj;5xg?y2Q{$vkb~X;LIK}p2R3)9eJs1*$Mr;LF-*Y+L+2Fc8xBp|J#TBKUkB?7_ zot#oqwNOWl9Cc#GYo;s=Z$o3Zf?%O z8WO`SLP8S+>#HJ!QBhG)1Gf%wI(aLnH`7Jjn5_rXQHy^l-{(fRl_1fE#l`-gDJhNp%u1e9?a*P!*)N4@){edF)=Y4uCLBX z7#TIEr%Bv0l|Fe1(a>ya?)gSY`0ahtyGM?T$?)>ToScH9!@joZotn#dSgL!K- zpO0BWSp*WpmRA?2RN|hT?qc+32kW8OjQ+&y>+8H(L(a`L6_2K|LQ#MH`sKaddOT99 z&qEcfu;wlnLnlh=(ss&L{rR(bm4R860k7jvUWxO6pVwwv#f{gpcOSHUOZ>U%31?m0 zYThnF>p2ul?hg~+YCspT`4-k~;kM*P7diS~k>$aI>-;6EE5c~sw$N^i_7B?cE1&;S zxy{A~Pn1PKfJ|9gnHZy8J#=61Z|CRO^343z?Uvn^1;VzK*Y&GD;=L&hC!{&nuBJ4n7HYy|Zv6q}^h?iSQN}A%Z=H&xg&Hrx*Ob<5^{2g z-f3XREtv^r!CJ9jz1L#@;3->v%kx368!r|9$hy08$b=Pt@UtgW_*l>eOs!s4apFaH zhlsvd`MTgLU8sYK5~IN4C`21jr&1Uq#~eK4964%R5ST3Wn4O#$1NF(1CsceE7$yOS zk8NuWC60f;IQf%ix^uD=|K9I-%Xyg1I>X`oHYpAi!{&>FzeaJUjf^ z;KuULQ(Po2RIl`KN^#kw{6(Bx30_E0dU|@$2D3q0?dl5Ujj-5d?cfi)%$R?TOuwf7 zSPvVu4I8(|>~(X02pjeDuYVDxm7LM$oe_DaUtWIr__1TQ)h|!4^zPcauUv4Dw^fpr zm6h4gN^{sWKkHo>HFBiXgC9hgGbQ(H85_qYC6VG&@uKLIkoWiZ_kH_T)DgEN;z}2J zap6xV`W&NJ<6Q`>*2BE71j4_AK7Hb(lk_ELWo3o3P8j$@C1^`bLra^OloSHr@<08P z=G>eyWF4wf*kO9LM`>kaW7!)=?~GDzbM3M9o7(y_b!}}eJZ>dT&EEO;(8SEl*Rqj> zc{MfUu!E|qs``e8g~&i>>(RW5T<9OM`> zUvp(bd0pqF1qB7ohO;F>lRtm{e56>D@l9IV(ny}H?tV(YmC1SXjf|5M@3-P!gc8H= zy|!mRl$FWr=}{neRb9=G+?B4SH5FE8B$47=TY%egAIV$M7g+Day?Ph}FJz{t^h^r0 zss<|k5~to*TULhL(Up5=OHUdVMtEaX8p;>$0i8%9C_kTBS5J=__V$;{BU%QZWfI{> z9sBgK91(={uhUFlQnMxF=#}17P2=wV__%auT;EiNJ1ulcMCmrE;Qjl^qO&N(z=&9z zs=WsdXm`eI?iLFRx}@(x(2%w4!-r@uPZqGD*B2BOEp}6yb_JoLyZ#-!%V}71!!+RV zX131?H4N^Sz5njHD^`@1!H@X6X`iQYJ_*6ZqnO`W=xkUo%1U_mE;baKsL6QMRU}uJ zqsn@S=HGNZ(f;bNVvbb6&SEqVatAPVz1Q+0D}4{`TMoXfuFZXUFdKLsKquu-#W}#t z#YGS=c|@gGZWN^{b&8=FM<-)vch|zwlF#qRaYrJ)E#Q0+7PXfpUgBXb2K2{{j)%WJ zCXHb)gy@uX{g-l2+r%U;lEL?efc2pClPA>BN~Ij9YH&0qb}{g=&{u}CA`4a17RO2+ z^$iZnd3fAUs{LoA*Y3{(SZF@@%1Y(j?S~ zThY>zC6(Lw^`wa(!FJ0&A*^PV=cXZ@h${-zHPmL`fB$vt4?l<}k~%@*9Pr&7o(sID z7kfu2FE4LUX@=SpON$-Z89ZL9|Gue-26hRu75n?!9V%KQglE0c@jK0S7rPCrt#H1* z6%9>fQDnY#3ze>SA=__D#>t86jmk5*7Nt#de)*ZGj#OJoxrXJH6^ou2>U1F|nj+1d zIAq2_8C3pqBtLFg&Gy^rz~eC+`=D*m;?3vWc4{3%#fRqGI=g`aGm||<<&$A8uFY_^ zytXz8n`U-Q+0**P_2L`_1qCe3V4v*Beyfh%rQXEE#NeaQ`Tb(p{J%GM4H}=b9{5U<Px)-V(ZRH^FDFiBgC#W$yu82Fw88yvsunMqO}#_%_;=`^fi%mD zliiaI)9cqbWNc<9I}1u08bxR}@L{^39qHoI65q4`$YGzj(qR|sL-Vd2QTSJqq-_u2i@pCe*8G^D#GitXLYbSO?iDecO858QIT|+ zo-B7-r=!r)q-h{BRA5e3*$gv4eRuWr=m-EDdL8xCQHbM{aSj)ZLT&9}^(>(UAdvtC zU?X$EU`|R(;tjm=cVGXG$&rE!{W?BgC$A{1pPT)hOU_9JaE|_0?sSc_-FeF%MkANc4@#3Psqs0CZ4c5T~eA z1)O{8>gwj^<)Ic97HV;%m_4D;H}*)Gyju3TS`>-DP7gwwJjcCzdE@p~e#g$x^eM(l;K|40%$U8w%QEGqyEQ)a$!}~~|z+?KFUvC2!(+&_P#gr`>Hcnni z367neo%6?!M%=y70^Fc2#?T5A!eH#8b!iF4qvW1P7W?H(DXNHeCw8`j~_pV9SME2_-ifvVa9A%4?Wc0p2Ob3;qH8y7CSd?<^JvOHjDuW zB+wy>)UzUx4)*aQF3*<>ex!1yzQD!ml)PDdS}t`1;6S%EvTH4z1CM5UL2e zDQvzGoW{WGm$0zXrQ?fj=Ubh~+$_#{Ndp&@6L=*mb+*PLW@>caweG$MjcjeKgp8k` z-*%B74w9j!z*k&TBe)}>=|;gUcw+_d=EE&bX4^uYyPJ$5zY2>G{k$^ zfQDX0MaihC;R9C2kdZbrqDx9n);2ZW7V0C7!l2|fl79A#6*@V3nI3{2;IYFKwpi?n zg2goWY)xR08m{m@7{)cM-k~8(b}MV^{PJ=_>(3dPva_C=K;uH&gSxupXilt!vRdse zXW3zhP1iYfuI2>B!LBrK55e@_D68l7_^bO`)yFsApQP6fcAV5_k|a-J9%yT_va;x} zU%y^st~D%!v#!lF3tRD1r^1*&IB>_O=EoS8Jf{2p{X4Q#TsjE z<078_r~pj3ogLV%9s1s8WzB17NN;-O_3vje3}A}R2!hZd>rTKEkJo ziFxEZ`|HPsEs6A5@mK6J<99OMy&ILOSuV~)jW@XgurYRUQ0@2g0WRnT063{0yp({e zM4+w@lhW}<;X<@F21e^)N zh5){Z04L;{VY;<9zF1Aj$cXaTm@r@JiG||?E4Zb0qrP*B8Urx$t;TpmyV)e73&D z#)cKbG+))r(3vM2SqYPX)2M-1c*dPd!+H>i~$4 z6SuT8_DFL9cxsPLP5@S{LMVfzui5y=$Lx3SA~R?7_iwc-Q50Znw)Xb8KXWkp^h?Ke zRdq|p;iH;(SYtsN0+BdbWo4XMzimmFe!T?fpFVvG1CR%VX7^%$7=dmd%FB!H@;tR* zuDy*W^;^OkIuglbmJ#K9rW?>JfYk%1vvqU~Q+U7ok=s|?ea%$_rrKz|izyKCB{-_H z8*jk*Q8)lXm>VUfXPFM=?XYlWf;3exRy8hwuEEYkV1JDvm&RL>U}!A|f5-6v>IdtU zhW~O@INqA!vmaxJMMO3be4h6;*8w}(>p$ROk00NJ$i^x;q#BBR{9hu7@6`7j_r z5@x@ap597PFmUU86)mJt$_N*ROG)E4cD+2DWVw5{fAbgYVwVynRfbz zFDNLO|5;_}ypjb}7_LBFcm|{RN7VM0YX*wwa0bGE6J@l}FkS!s)F(oBJ;@^t6p~09z34(6ozA-@nxGb#QEJ%*I@xy~; zm^IKMpk#7^9cOU zD=WF1+TZ)TJl1h00AQgVBsnOLeF7xFMxJrTDlpC- zt;SelN=|98?H4e@6cv3fBgmy+_HAyv@0{2vBqq`!U1}kb-4yl=^oBejc2q)+R36iy z^w}>qEz)8bvAqD@=&KcfV}_6wVN%`sU(N7`GM!j`mqxuAzXz;8YbUpY;(`(cLIg9c z45R-JYMs+`gd$@Ac?i>p8!pD+`BU@|CU`8f>R**^CwWrxYNs8DQ<*QSb3Ninao=l5 z+CXzB*o}wYCi|N@A}?>h>l<6S!=Bor3^UmXZNguBA)uWNf9h|okdcs=JDESB05$YL zY;rEq%j3SP#Ppvtzsck0n0NXwji!}%=)QAL+Pt7!oxsZ1_Gx=?nzkfjDAf5mAp6UU znSdzX=k!G1)3PP@Xj@G*Yf}I|iZPTQulO)P=d96OLv6X9mz?dHxPLRW;>x|1B53-g z;pon<0xUv0CCgAjdRWMPm!QYKHo}oPs%0QrkwRkkYGh}P2-PR7pK}+6EBmUUxf6C0`>n+!eG#484 z+%}^av|Hr6+fQ4Ug zj{Jq7hoBipyDg7}^Ta^bswhuLe;Fy4(~iC!ADyVrdzrQB%|a<(l@?o-B$gy4`jn6% z8tRfmhT7s1`3o6P-Q%KLjc%JUKfcp#`sAmpLN34R=vq+Z|amM zP=H@ab>MBkk@E^ST?vPBGR}4#$DwMiv5(BB9rLCFUby5)IadvXHa&$8Gmi+_-Jgf# zRnpC7=r0Wa+wU?oOlDO0l*YLyXW|-iCsTU1Ql%!9t&0R42SddxiH1Z84q~m(wgeUT zt&=_wMoT14@{`@wx}g-QdA6zEP@`8!Hg2AHXK%_`QXY5NX}|bvU}#iFOXYW&99*kO zD9-&u<)0X8BDHA~g6sy52lw4S*8k>TJS{p}Xk20Ud_2vv%YCK6-TaMq(*HktkG7gF zxz`0j<{g-4-kut&5=y~~D1CBuhGotr1edH5ZFEa4{=2Pz9@&*ju^h9CzK|Sv9#*

    no=IMLA5J>GOup3JLQwV$^mI@nxt% zhsQz`f1vI63aXs$4qNfx0zOmGvWM%P-3yIsy*VK^a_m0_F?V(l>|k0WWAUD(XN}vP zhe@}k?l2C&rc9iuIdQ#_Het_`m(Xn?X)jCP0kd{Gkwk0Ha72bbH8#eec7ljrwytQ@;<^_ zM|b(cs$8?Nv0=_jWmZ3pOacUo{`!m!oG9~V%3@PN>@zE5@P`H2Acz< z7$6*o0@$#U=>U{`K}Zk8CGakg%S(ir^7pSjN4ip#pib7bew1$U51cYR)#Un(Lto$6 zZj0b{Ggq=f!?INCnMrUNI@$qoU9oJk25g+tmFf8D}mMl zQwLsrl$8g?A6s9BEci6{F!H2pvLAy8hu`ZKqsC?lOP-vb-Umu{d`W4k<=OG}Fjz*` zeF?V)|BjbtIL|ck0md|ghn5bQGh10r%?hk1^dJ(9V7{!OL1V9(?!nCa(U2a9>9?`~ z<*R=%OE@0B8x-K15Pyy z3+B)8Sgc2KWn#K5%u#qb2lxSDHXcqq%>deie66gcWCl>NN8(^aHs;5=73g-K&Dzn5 zDk~EjLB>PAUICTc3@-1Hsp&9MjDw((e1+R#6BW&P(&jJv8AzEzi7tO^Z0sPcUIwW9 zybyvgr;30JHh+?u2;eNBubQ*djn1-unmS6ZgBQP(og8kPF!#ktN~-At`3a+S26Z=`-tWPtQ15W>XU>UV67JS^awSul5?7`QS+H~aApZY{}wsNIk>Fv%Xs# zPa}8(^jzpY$o18^%*BBiz5sp&LV(=n0*)740?%nzzP*cvE{YiCpb|lM{dn2s?^b4t zfAM6k6dVNDK?+}9UP8mbB4SV*_-f+wCk1hoEi5c5-If##Pq(A)WPb&}Cl-3$!bZiH zo~|ge#5Zp+nr8^X{)JtJI*`WG`@K+g7li*sM8XC>2quyl^pnl{Im8YqnxzM+7GW$v zvhzHu=e(B)5Sx19sY^E~@Vh@Pgu5D`W^jqbC`o32r>#9 zD6eS)yFj0B0dL}IJs@=ydK!I?Qz2{p$9JKc60D`nwUWXdGul~F)WvPD_TSMBijQ=3 z62SMM7x#p*#R87OpFe*P4FEb!o-W7T55RjXJvQ`U6eENH<`&{>*E!GNf++>d%+TH4 zE%Ne01mr)Y7@&7igHls;j3Za@(G(~YD2C5pyx_APVIrrbL})Y8`g{-8P+=;~y*wv? zhh3^)p#Zv%UYTLIzG=YCfU^Ubdby7oz$5sUEvbt7>&5D~QF%Fvruw}my57<1V$Okw zY{|F4F$JXy7+$zaVSbSsn0qi{?t02&#DH1?OLZ%40H|c8{WwPpm_rcJsA(zy(F?pU zGyaU7rT7QTLP8V((B}O23E=8SA;Eyak2{*#UCEkKQGpjrjG*}SfYPRIWE6vnj>QD3 zhQ5gpD^SGHz^nZnge1ajSZnnkLjC@7(fAhTH3g4J3~+AC_3wp%kP5O+DgV*MP?&r$ ztJtunD<_&u{r%TnNJ75C^B?%hhY}DIb}y`MP`;T8#538eanjh`mAhAnYp`OUx|U0G;_y5gnfSQ-f;1=CB%Qf}jB#Klj6j8^XU` z(V=UFay_k^hsrLjZ5@6m9tr9&%sOQDfei%xfD%Vz(kA(+ic_^Wb4dh|*b&Pju$P9esYuLa*ik&vkR=FsII4%VmW2Uw*^i8$qYrFK=P&D(9X5R!qyQ~>e?2Al8U zUx;;JzaM>N(&~%U0{9P+zZ{E_bI1+ms-NLea2X=b9pYC$d-e>TK06POqKOFuq!;Y% z?Z3Lw`5te@g1lkKD+yjK$e#oR1V~h1dwI%*t~U={3-~oepoHd1NH2!bXcPw`htf($bQFC;#uVfbI$yx(gJ_Tgm;r0K42br*1;yx)p#m zypI5G$m>*BS0fq=zzXD2pn73-k$?`U(1>a#LyUnmEU4f1qs?h;9UZh1-Pd3d{;#3& zF+$^h6&qV}o zI#Fv;YUgL-zt=>1-4GWy42KNq!~`^92u`{_oBUGgvu_Pj5h6)0bc7o~l8BH&;+4<- ziVR!w!nDg5(8*k*_hD=x0Tf>7V#~|R^WfhX^4m`Y>7P!PG&NQV`{V3GqST2!Ugu z;X&a+(hU*eK;8>=C~w57|NR`#gI)k19dwUrX$ry7Z-Dtgp~J<+b=|C;T!a?jt_X=N zaI8a^%wV!Zn&N*(E7&y)Fe7>p9TqxvK2&~Az!5dlq42(e!18aVnG(>eL7gKt6c{lX zS!kMxFAn0IfsX}a7w{GQiHtwc@6Et)AJYv0^>YVC)&lfe1R^8x1MpxhK?q+PeUCjZ zfo!CqEa9cRNQMx-((Z6PN?s5Q1%-qbVV~ze%p&F^P)?w?GlfR-_wQdYBM`xUY+_m|;e(`rIPbm1p)T({mUxs{-Lkr$i1W(Fl+z za&mIS3`Wuu6XnLyFt07UEVTfdasKT@a)|&0cle`Yj4hrNz;|UkzYNBb5xk34-sD z@}99%zFt4{U0z*Xf`XBU;c=4!B50sV3o>+r=~*}J+*zOufnLNn1ew=!dzK)=JRvzb z6hO=(RPek{wuQ)p>k9$U?Vv><=SLzpKw`*WEczhIIP`&rjq>KN`w~)6aKLpCa)6ll z5d^dmh?t4YOc*FaR504X>RkTw#~gYa)qQ(%LpI_gY7xSFV|P%AO-_{h4$|T2?6k%EzXZN0ZI``?4W?kdj*d|wnSH_ zo`(gZ`p@1eYLM$e0{GRG48;IhI|rsii*c*K&%1_B$g&BOyd#% z2@oVO%z~q45Rbt-Y4Y6sOA*MDs05=G5XdOh667ur4IJ@^AS>2x*1*m`zU~ewk6>JV zG?alq&;Q0g7kdXnFoNR#UyH+mbpakovqK4y#n8W05y3!W)!5z#+d)SL=?zR=Sksp2 z9)zvyawKMC;DFM3cIHd-JO{o8SMW!%X6UmgQ^Vy;PW&0LXvl@!2nl*rtf5`;7BXK@ zudr7(#U~v!Au^WZ^7$7WDlsJ`9PGrg$;l;d~ayn%9{O!5+nHIfSl8D#D~@8Wiy0m zLR*KC{xEc{?*%;}Hn1EI2h#npnw<3ea^~bEzbN`=rjK7oPPYRDR{9&Fe zdfAgy5AnHWAIAJ42yD;J_TF!qIlS&7TRx-jbwk`SzwCP}^V99~T99#5MgDu&3`OwX&xPp)QYqf)aEKhxzO`vyOy!ThM1=2K?@LuUJ z1d1=W^jP2SJ?{O$HC|RXi-}f}Y1RG`>Ju@XAw^MAH}5kiEvgy1P+Jqg)mY4vEcC_? zYidD~(qFab)*EuByuq~8tMd0d4~d74-z}wbxJt?oOV>xx2=+I6zsUXmQD_ znQ(tEluOJU_E$CiMoaiTlm6}-8~G4LY3s?a_p0X8`kHldE95x}ZZ8+i<&jSwrM6YS zw-aQJa=&ZG#r34OjFcB66h{wzmvy~^B!HdG8<9~jQs`x)np~nNqjoV*PVIAr%WIXz=eoICxV&_(sC zZ(m|5SZOQWEP5%bWoOS&r=8`^zVht1Z&)bmONsj?DX+GJC86o&$4k(cBPe66?;Slk-!(-0hh>>QvT5hW8<>4^1=*VPuM`7&s z?eBkVn0>HX>&Vv#*d-04nWLADUC&kZxO7e^)Oguim0ZcV%P()*e+kFmt1I>)=aK+w z8{NIAmml_K9_5NN9+WZv2+OCO6oy9M4r4SGZT%FNQ3HzvV9P>^6rhkZUc?(|x68oX zeLebGE62*L+=`Plt+`GIx|lD6`-!*?aVu1KlW1Gz-E$Ci4!W+`UlL0Ue(-}HloJqh zh+sw_WC;Khv;|g)E|K)QKZyjv+MfggY1jNIDh_dL*ONxgZTuQ_%O~>t}uOynef3 z|1Ycv20d^I1h@lBfn<6-c%4Z2Of~`^Qswdg)p-^0?Om8a02$os6Ii`n0BP{T1ERGk zzySfZW2Qc{6a5A01|&0vAgQv~)I*yNc$H!!Q;tqX_}lkJ*mRd$S%W>>KlqO7Wj+Gl zQ&&d;f?x3J_uxh)MhsTL(J zs7VoGod^!woUT9TETrLb+P-1AoG~2s>lEb3%kWH-VMEpMR7GfMXbU%mvM=@c*$V~q_*EYmnMmlQv9S^H zR8>?|D&dNd1%lTsfLkIlI=BNU(<;}6hX{HDI)xjK26zk7)sO&%KOriG_WJ6qS#p|z z6N^lJY4xtHQH7g&I_nKIh^FABsDuN3)FCphsUN1~A^*gg?lDcH8b%M1IRwhkSOy^_3g7Ia88K zHALO0si~nGkgqlY!gB>^15f}wiWYcF1PM&-0BL$OsP^`{ZRobCbj51qA*b%v=Jt_J zt8o>P>0e{N9bhmJWdQ942k`Oh*SJVo6&3w2=M5?)a9e~$=std&2cdFguK_fqia@ep z0PrBm0Adj6XR=ka!|#L*r)EccUUA~e5F-*7!aU$zlfJ&b{{_L{ydg&3fvI(1B4BvXCoxbZsUrE5oDurmB zywKnQ9Rss3Ljsy|BD^&q60dVb=%VjFM7Bn=7ASp8lHDHmD zF8tK9PO@>Uliuz|H@hg2yJ~YG;4v7Ro@}nU6YuT_uq{jM0|YuiNi53OVz=c~aCGEs zjW3nfM&3_ZU>-IWtd-O~m!O%>)hR)_c=97^jF5TW1*}TRYDmAptU4s-+H}Anp3d~x zP{rBJN)}G1tz+e(^5e}6ZScor^nJt{u<&GAOp_>*%9gTCDBthj$Kn zba}#l+H49aEU>TsbNLjS!FZ7~8Ln7{8?m}w*!}NWe$?%~5aC2aW|W6d>a)=}sgy#A zup030U@Z;Y=T3rG2%Rx8no|wm6MK^hw!I|N?YJ8lEXnmJ98D?ec9N2l%T|s1Ohk1y zI@?=&P1paja90KxZu%@Nh4YtmNkvNx&zA}fmW6Vse*@0ssI6=B;T%R?QV!Q)kGRV2G2rvOF;sC*Y-uad z^OM^<8_=Oxla$Y<>h}}fWv1@mpuS$r2<&}&+eJ$}se-oV&8ldy@hOrX-7F?O+Iu*e=0D2KbsNvtyPV(^OCo!r86UWaS zc6s)m!iz!>GEKItJ-9HfTuG~VP5M&3K-yaQX_k`U-J!rRyn$-K^?AQe`z2cfBp&xp zplFxn4cO)3grJ}ZI&~H{{p^%94UrrmWA}Ky;RU7~yicXxfI&7-^DT*0CQE5y%Qf{` zyBnQ)^(UPYc-zO;(kR*@G5No8g2O>_uM+K=8&z6-wQ+SP@71GsB``Kh-g&RI;;<2^ zJsnmy)owLWFHp)*m<_rMgX%lmUcHS%pi9T{bKXL3n-|ME^rnHEd)QN?c}sRh&*>C} z?JNjRIv-8htNU4hJ;2(-I$*B7&!c5woapJHouX0v-@e$e|1JbW(BE+=XT0APbPMZOuyAWGDsy*d1ObFVmxLbSH`BZxpRlE z<+1t>)=q@Zk+5!dg_6aj!^7u~>I1rb57u<>;3AlVxD+Izu(P)j9f{x< z>=Y_vd=#TrlW_@@aQUM&h32|{L}zLkD{Q2)eA=@yH6^ig$7;$x8W#Yy} z9q*y!^$Pmn_=jmj-n@2|d3iTClnsi-jA71QaQfE`ysC|c1 zCich7wOC5W-3Fy)ZwsoGYrgbU?lUu=c6;Hr7TG)$&oa!9Qyt3b(E#Pc%0w|%uSb?7!NPgNRsIKJJ+N~Nsoojn!#CFxUHfQf@wv6lTdR_A_E&u=5Y7`6b7nh*Zt2stxkZjFVu#)weQV%Ji zyD9-7?vF2e?RO9m6yfV@1^-LrPnSFBvV8!Juul|mVa1%Dj*r6ecloE z>Re!Msv|DW>LO05J)@nAe#wl#C7gxv`3DEq1XrA1-{V3mjA!t!wG%;i3ohjqDK0w& zX97JpPnuHMq=jL0MYu12V{N(`ueFZq@NPI>r+eWwI>GDeZ*PiJ*Wf*U6lHl0x$=i* GA^!)mMvo2v literal 13005 zcmch8WmuH!+Nd%z2n^k=AfbSCm$Zn4AT6EJ-Qh^LfG~7-BMcxp(%s$N-3)ccwf0{7 zTW5b~f9L!;Ki;|S>wTX)pX<5vnP5eEX$&+{v`3E~VaU9dPB%j@V;@O00^JO11RZ#)%fkHh^n=j+b``x) z5hQSUVQ+7*ui>=ewDNEwKtQ}p&y;nJgxDy4dE1{pWvqm;b;j0%cZw1OV(&Zp-ijx8 zaS{6*U%jq$U-ZkJKJmo|gTphDO_R3m5~p3Pom1YXL>7rQiQD7RVEt9m#!w?JD5~(u zevxu=nMTTi0NkpjY3j6;bs(&xK*apbF=-^}f??S)FA=Q?;COV@Z7Xlo^~EvmQLUx= zYtN~tCxYG5P5w@#hD){H9GOmt%e(r|02o^e-pPUC?AzZ_dD6H9 zSOnf|lTuE2r3Q01FKA+kpsEoKU$wM|od!=X?ghS_>)|iCu4^)W_v_cPs%z>p8D4<< zQxwwhLXpB={0$3^(9epk7}9sxA{;4!ErUQ=|5+CPeTdaodFrGik~_|J$tB?d^VlJZ z%Voi=EJo-{yJqW37mHb|@8Fu7=hBC~%lpEsb78y~Y`Wn(Bp-Xm%RPiaBKZ)Ry!TUP zHua~4qpTY)-!}ESYPgP4U8DE1>SX8l!!<3k;@T!=k}**sQCwrV$+EPTh~7wA9PhTzP{`;n@A_YyI-lt5LrN0)!aiUtC|@=jDvJvGB>VDRUaUoVe+3;6rOj z+43N63f5;6pn6(XNH=R&76IOOBSYzni5*z+m5iA&=w@~8W3bg4Skw)Z?>@_b@fM&h z9*ygi|7=(aq?$T4Cw)TEmgPQiDpqEYII8nmtK-D&FybMG)mDmMZ}PyLr~soH9(qaW zA4o(v$J?LtP0t^Ux4qT4L9_vtRvfVDdXmvP=r9vmwFeCWYw;s96mL19NLjc{0oTtYp2ie&o5 z`6IIPa)r-TsWsz9Z#={NdF z9`ydQX(0t+TC=AHX=JgO1iT;aXCl*IoC~raULs+Nw60*6OkBGeM#slEiAh!exgg5N?Myi2W>s1+h`x_|Fhec@{ph`4 z>LSTl?H&idE2@UOcMxyNn`?QQ-OM$Ru$DRRxe115-)0(HEg8uVg`xs{xXMgnjaNj* zTlZ-AO({hf+_cEh+Ybhh0WQjCW2Q?b-mgQhQgZn4{7}L;9PH8qGd&bpec7p2!@yij z&2S~@-A|nG>MLlu9TSCvFrL<+7BQok=^3bn`NMX^{fvt}^l9qD%p7$CxxPqDSHNX9 zDlI3+_?`dT3yHuReN-dCo7}RPS`Q|9k=)shSL$ft(y1a+T&8386K-@+2~LXgs-X>~ zEHYL%8yZO$G2p^pE2&yN1!<9;;Av6Knm+Hdm&M&)u^uJ+=?OABCd_(9_J<{~cK zO_U^dQ;utCnOFPkgq(zZxuy~x5UnO*A1jinL(H8^_875VsU+^636vDHcB>1`UglX0 zaBIK)$BRlWWM^XDj+*Cyyyu+Qej+|DIvs^B8%Eq(`$zQ#fi$wt9lU|yc|aB}*(iJY zU|laW6uqqj6HZh?lj%N#)d@pwVqP&?DbB>CQz0`%kPU zV>seq%Q)Bdvy&or73~<0d+z_0(u4SMOGuni^ACpMvv@3QDJF&iE%O=aZ=b6fc60Uo zz*)_?Y_^y?#Oj@OqyYq36HXGN25Ni`pNHJSz>*$W&6(J5Dh)Ijb@!TZS0v$$&o(<| z6uKiL!1Kachqm@>f~`Ey=CpPbE6ikxv`bpLzV=tOPWFTMn{5L*A5dD+_>M@j&F3PT#pz0HXJpNLns9{m^M{FLSTE8(5( zH}|tomy8ZSSDsg`3!P(g_f&ofX@pp9L?>~)W%-u zk4sSR!qkbqw{OloLYKAhRaG8i@ua;`ODfdP-RHJl5UHF?Ov3uOb5@%V+p`5R5%q4sX z{iG$k!`WK%g6W;Tiw;iz$0^)1Vj;jsuhG*Ai~Tw1z4>NE*5~RoHMtV#+=MPy3ac!c z7sxjw++nztBZRbd<5bh|XTbaC-VOzyy9H0(Mu}?=Ic!BbU|tn+gm+e2NxlQ-HQvn; zf<>6UV~u=NveFxI`^3CaD1-V-YtSZCD>!Cdf+06-?*zPS+i zha25qH!P8giAlnXRBqD$+=zOwg!bZ$3*Mk3F%e$N8Za7Sdzel{dkIa&C1n#*V&toNInS!eNG^|@L$4WrE9EZjno zC5j1biYxebfXJkzC326Jpt#cXomY-CUObR~Twt^C& z+Qe;~vN_Ucj{iEH`0AZ+vpEg_MZ%LDG)l!G|7q^tvXZlG!_TYIJll4H)OBGYx35t# zc9E!rQM@G(>S#E=L+L%~pL_+ai(p5i=4!02-NJ28(nRh~GdNerZmMFAS#p>iSar_y z@D8&rTp7!(qg-C_UTNqJhlIt9KUkTZ`9L=MO2{$Ejr>x0A+D3Aoo*~V0?Dh345SfP z;-pf7FXZSj_f#~Jyk60a8+@`Z^kI@St+Ft@D&D?nn>mmU$u#;lJ_+8)ENUuEn zMd+IJXOEY+X~Gfv;ZzY@5E0r2KM!Gsq41C`vGoZ43%SbD$~sjK|$O z@~F*lQK6U{P=xoUQb9ZM(6H>hrFLzeva4Bv+&V1aS6wEo*Xq>y2P)YhY(a_In-U;P z-e~CKkuFR{Eof==c-%aYeqHCpOQ@`QLG9svc+RtkThg^(!BmwjYboQV%p!wdbqr;i zCMJE6e8IZi2c9y4pf|-#0Q6;I;BIl%xiZoIdfd0=i#N?e!MrQfdMK(ndoOnz6q(Pz zb0AWch1CEmZp%4O6V6vbR7YCC%aER68Zld8Vys{opZJ+l|?t2>-{#ZbpYcfY0;~M zTC?G+9V*39Ho?Q32>M?(BfjyCKW1J&+w-ZJNLJH&7+K~ev=I^g;u6Od_{Rre1 zikSDYaBN~peTR`%_;3&2PJ*>Y2L+FQ;-2RIdA_Yw)H&hBrBjUuQ}sgBVuWw{ zAt}3=AL)u$I~JrSH_cB=h>Vw58!X>je7@T_b-*GM@?kBgHtSK>tUdF`7VfA(q~!Gh zvcJ9+=Dgce%!X(2UnyRb=&!Xs@NYzWI*OmN5ZbsB#Q#JIfUqnIod#^IR-G(I20Hn8 z-V|n0&9F@q%IZijbq%iENy?SikBFKZ&ou z_0)+6f&&A<8G|hzT3*-p{l1drnGBomgRJHp+z(8K1DzPqWE|z@0uIi!)~LfC;S=Cv z@d>IfB1Rmk$S>s^?+y%v>z;F0%ZN7n7d5=1yzI|g;gVZaIJx6LBX4$&qP??b9+BSO z%Kzp1RpgT;Ka6j2pn2lAp=G_UJk)xxtLF?5kwIHW2VZ?|1?$ z0Ff7pnm8JvGphusSxI~5)0V~xuV=_L2j^AVjV1Yofz@u=%B6vH10%$)(^P;^tY!LC z+p?)Rxog2WalTPj!!cXXEiXAh_SR~VP}1`nsW4&D`bnbRW{yxrT6jy+S!<1dtVp;q zWyA-n01%URcN+KIC!vcWOm5_DKE~H8 z25>3~7E0w1<&C$2|0EdFpa+`frg~TATklArE}Z^)b*ePF{NcQ2A6&ZVXSmeqEI8+< zI(0>-K_MdR>D4$|I=WLAQIUp0C43@sSxgAkoPQ1xHjf|w>;qz|Go2_sH>_me@ut{H z;;7k6;Ci0W7Oi0%lT(r!;gn>8+ZzEk7HpWtT8)2VOz0kb(;B3ri$aK8y_vzU*Lez^TB4m`Q)Sjk?pvqyPEpqa zeW`MG0pm&6)-~kG2F`80)CHP}F-=8r+noNnGf8=r?0eORpzm zeYAVo=L?y#i0xB|m;Yv}yT<|l9MQy+^fp--AiW@DU&UtM)ORDZ{TVK3a(#iD9Ou5M zzJN9oEZn=kiXB{Y;I*{nA-^XVEaATP47VF5K^+Bp{{pux8H{L*bT~M6UKZW|hzVqz zt{vHbajb${-%(lZTZDtJHop?4#R|H4-QZhZd%+#i9Pa2vzx25D671zGbe>~9gi6-D zCUskWm@EyHh4*0H%6cIeFlR#=f43&3)G{ozIf*yWlSDP(T3TiQ_F+n_ zSkR$K(x@4{G^VB=DVox;J8y+Ww^vOfQf$@TY33nY-7QfcUbAD=J2({eKE+)F&B8&@ z^(cPY7p>2?^F3qvwL5>*+hob&3jCn9X-Rh0DBfO>ppOgXbLuGGP<6wX*uj;dzeDJ6 zCI6{yG&op-nk4@1i@yLwoRvV}zWrOk{b%I;C)$6H|4+34OZ>mF{muVx_&^hc!2jg? z2k>9z{zHJj5%{li|3T?@qVRvj|4ZG!fd7d9AN6k28h|k&QAg2nM!n5OmHX4Uf0OOs zm7@f_#P8u{w*p@HqhL|S2uV%u%;cO`2Z$i{iZAT*$qSNrci9)JiZK>rI@A>-iOEH+ z&=1g>`}~E)owQp!`(M5&k-?OTj0|e4A6mz2Jt;~F%*$q}$RFJMls0~?7Gg1I%21TX zZt9FL#E2+3H_ux&TY4x6qWQCnf;B~drW+Kt8e48_%IsSSTNGY6tMW6Mp{?&cd6mmQ z=ROg#ZL0ySMzbuF?)-wUpI+(t@_P{>1L+vXJEF8v(qQmBBUCnh{e8y!&Nx-ynxT-= z*kPUYh!Tw-_&tsiT&1=u1*#q1Kqc_Y@7s*FJw2=>@nS!RLCMuLerWGAK7IvnqLH{p zfDm95I7XH8_g7I+GQY1RFjuh)hL2{91lk)g)W!nT#A&tK1l)-1ArjBxS7^p@#I<*s zUhu)~b_jZG)}?fRo}4PNKRX%7^LDmkT!)~XjWJ9t;W02yd*;KwfAZa7@pae>1e+vq zMo#JRUeA5xO)&>r&Iky^EH|#xb=|y4Os1gczUQ`kG@r3gH!v_De=qpUs|a@FyALKb zbSdctzDr;OA`)kD*-CtMlS*$sQXl)9Qy&pospe159z_Z05aTr>ofF-{H1_MI{nM<$LH{q(Pekp@3pe@&8`Lsw?tvcP;3?m5xs=fYm~-25z2bPDYhh z$hZ)E{{>+LHU%2uENY7Qv-0jpA0esIqq0&bcXQ17`uP6w@J%6AO| zJ1_xxfm<6*>h%>vNb7j)Cn(%Vdnsa9aECpxgmGhZF^Caf5@QBRP*tnJOGW- zj|}*`qRcMmUmb0>#vc^KQPU}fT3z(PQT>X)9}MIaS+E43-R7d7Lp`JX^GrfN5XEBWA zL+$$Wg#@zP$!(gu5e2XdXMRdb2VFFOG*2NAXv1%rABSYy;{A_$#=4!#8!1(f$$PIs~q~kj#zDc6cSptp;w6I$||uw=$JFnu>{9{Sq#WK=ipjO#Ku=-^(V^h}Y#XsLTptks>|n?umm z!}e&@Z*BiEF8Sy*g})eZV-oe{_t`UHR)4YQ0A&UvJ$3{HG^tQRfM^Klw-@{kAw1+C z{_r>O4craG?Sxogt<4A=n}FzZ6EzgNK0OpaN#HiYvxhshFIlTkPTftGe``y zVx94}bU4wPH0QCjXKbqNAE_QMe=JZkQ|%m;X9srv27Zap&f1BH1izoZ%s>+VhaFzx zqah;3b3n`=tNt|M_t|b3iVfDl;GoBDBWg!-1bLHy1lvqmQOA8rBKZTIuBN51g^spd zxMOJH_y)7Fo)whF%gXj4(5q$!)0@Bc%6{3KRbJu1|Eb&+xA(6Wu7Rk1&ED`b>CRF zbv#leqJAob`E#kbh9Zu(qTY?u78{2+kdjC1u0(i*?|L=cvvuC9GPDaaS{J|9I9>0k z#E}7mFd+QKlAZPAAB|95*)j$I)q^{e>X5s8dwPGyaYmx~0N+E8@Geh40Q$FYUDyT%e(8V|w*fNWIFpZuZugf)Pb;{n7T~V4Dx#3wO>g zO6{Q@&!_KA9!7nHjlFtY%Q?Q;d|#dP89cYrQLF!klv;J(aK4=737U@fluwPpiuVbP zPp4ix8Mjv5CJ@FUag7Frxr+shTV>BbTylJ5897j^zal`qb>2{VmSLmlMl#^nINg>I}=w7!e9TsCCn;WX<)8>^F2< zEJM`VR$4y7BaGNl5`u~Ss-z- zcQY(^1IV6R3lu^)X!NBpBBFGGA+X1{NFnu4)-2L-) zVMPe8OTAW+>pHnK!Dq1~#JAZrriZ$o>y*ALiq>*!QEodZbtF|@nzwN_e31~dIRzkGptfN6 zuI$dIAOTE$0cZ^yV~bvYJtkCKHeug8cnm4eh|GqWb7To9sOo1RWx-3j^O#vI4x|Z) zUp+64U)a-ZQ?5k|%X>?ySHg~#%=DO6g*b4P$i|*`2clB`DyE?x*W^9ea3?Blvjrt= zp1M8Vwu8x^<7ovwH9#R6tUr@80!cZotwOR;E6L58f=y@Tj%k>2I;N2MCgvnQq6r5( z5fj!8a2RwVtL4G`+dWW`<>d`%1!~y{cujFb(LON)Ckn(C6VjJor#O{!xnDF__9hIu zGmn7Ji7Uaq4CMp;LH*aX>~T%WNc5)dy(~20hGMfT7$v@D$AsLM*wli&?;)jJmIphZ(`HK6=EUYohlQ)XAD5{>1LXQpDxC*8k zN-184P}~=CyfK(wX>;2jEjev-jrO|c?KC91KFSx=cL{E7 zpM6zERk+U@rG{_v)-mdV+a_o221ctB=emGImM#B9O&a#mxe=}!Y&~MxXf`j8Ob6I( zqB|~mKfZHoWsgFfgZ7n8q;4`xH{y4^V=<1t5UbvZTeSHd?f&NFkIrQ+RgOZ)(^VGB zNbfen9YS};4oeWXCXf`m9?#rk-5i%7scoo*d!N3}f@NLxD@P&?jmYLn0aK%qJYsCW zaOa9NCKbXs_IVTDa$MqO8VA?SW(%uvU>6zy)CHb$<_k*s?cA(vdI zO)4*kAeJ`8TJs(CC0EjERE2s{gElBEmCW7#tQSWrc14_K$LBpdCawQQX#9!%Hj%EW zRLHk+TVhkc%* zNn7U;*ZxW|oVa#KG$HOs3M&&yMnh#N`_EVF3T0hXl7F#X5nWbp`0Wk*i5o%b8XX6cej|2gVx9v+pUs;6uE{|c;v5wV3xSpFm=UP$ME7fIQTR?e==D>x6=e~mWzS+$X-fz)pmQ#n_tKrnT-m|96 zkyq3XtJ~2dT2v%A``Yciu@mi_T)|h^@-!ia=ksq|l`RFE7ZB?hB|UgQ*{F?9w+xdD zbw4_Jm|Xw2QbIr$)7bdzuUUXsppI3vx`4QBEY8xU2mkTbj2JDA(QBF~d#NOmCHbnQn9df{D8i38cK_7nHTz|eaQ39A2M+_9&0u;*P3S2zZdVL-4X(y4h{@x_{K<+fG`S90o-~+nAUzWc+Zf zY{8Djv4Fydz^7;f*u{LDL|fp z7P43TM@F=KgGihHnJpQ5gy%Qy3L+|Qqu^^ueK*=Cl1X!X_9LSgx%EM7#5m!g>GfIpX83+@=}?W9rHF&~ z*V>~k2#uiFn$SE;a^*9CLIfCHD0Thnwd^?yB-(p~O0)E#h6!Tqk9pQ{W~|mzqqXAi zm;B_M%j8Z49W6ynhJ_Cy$WyfB)nleb7mbs7_}H1@{gC}_^Li~4qhmTxE=zrM)4Ty% za?G>3N0a)Qw>OjYJC8_QPe6a59E-^y%by3vtv@jL8f#<#8ri(2W6$>ER*zW{(k-4n zJ7%Z6MW|NcEI`En-d>w3_Ty5vNEP{mjcuTcWU zTlLYqWZQLL>$xkUbirawmk`O=pGZ0Zf1u#0Ew#uL-#*d*l)s3YQV%~mZVmTg{092O z2TTn@O*spUTYczHX?N0&Bj6t*8->j0H_i7T0$4scr=ZSgX;*(q%*TT5!QL33xAQ?O z;!iQ)Kgh;wwDiC39C4i+im-zp4$3P>GTwaym#KnJy&$xAy|Evb5P}cw{AEs_LYtbF zC*xnFo4>?k3r5_@h|t9EfTP5Kso6*#sEfuGk=E_E2sAyG*+1D}c`Qsd?X5&iHZ79L zf_1UZMdxV9zxn(mKF9MzYy+s*((Per`ms8#xtO8Zmt@E-AwDAYMs6|zdqv&e)-WMI z$RQkf449F{T%M{~q~k4dH7AoPMGWL&hvkoj+~EE&P_I(;bzNq}sm+ds);|iHTtqeW z-_|t*exJdAh`4%uA#+jXzY#e|yF1+bDvgZ!@kt>d_G_Ui@=tD#T?><)-5!!D z$4x{R3(?Lh*<`-s<%$d;&&T|TRtO|mbJ-~_n=UN-%z88nxN}xL)rfIYgo-zF6jQyf zNxL=i>VNO0%>`(s1RS=S+Xz~_%2G0>o1?r!R`Ep><0`o8gC}Od6M+C(-z(>u`|<_X zF+Jpu`)_j6%@sxS>9mUw$}4$k^8u0`$8rXtI6Xxm2Tp`?KIJGj@ak9n{iRa0Pr{ej zTOb>0(7;PB7;M+veiMqV`eq!n1VRj`Y%xN57}t2hAzhk-BCk5?x0sZK`(xj%52K*f^8rq zL}1bQBNkLD>M9#8X-zz9pigC<-r+%9?#x9R6!V&Y13a)fw-~6nG>Js>R3@pd93j~Q z?KQVfiuY3S3L{DmQrLC#_MstX8dsz@-^fv5B-KUJV$yTurfv`j`JmKk@ZKfYUi)zL z8#vGQS}hS(-vYb4Nt0OW=@gbHC+{_B>*#ay*B~bT44orVBe*3xs zVQFWE(H59!bDrsi&m0j|;vy(Ef$J;9+)9S^7o^1>Y_^3sH-~OLpDNe_tloQA^$E&z zWzeV*Bo2KTm7m9qt3yz*`=a*2-MIrt`+2RJ>lEnAua4!J=z;=AWN&d`=@AoWn97(L zZ+O*Acu@j{vej9lLXz2&ps>2hiu{^2QGgxuj&N?ihT6}Uh&_29`YS$SB5^Qr=1b39 zC@A?y6RXG}rvFC&GS>SruWZTi0I*cjN4<}VHS@Sx=%VBpJ zcGg`Bx*dxUkR_(-n{`q@J|$wraYp}roG09nDG3CsbpH892sm+7{H5@JBcxx$pji0) zU&N!p{dOjps^SC^yJEYve;sMPJkg{4fsFI$7FcnaMt)fVhwV|s;~Z)w7>p^?d=lX) zYMt|P4|{Sbi{lw%NB6{cX}b|C6Y|Rto3HAtXQgd(GxV3Z?z;3<7-E-a^(dS4rN;ac zn5zUYelOQ3C@Uxh>{=w~qdE=$O*4Glq@T)%fRuW2fNJFe1H@OkLr;=$_$-L^(B z@5{S7?obEr&|Nc(T;+$On?S_1I@J(wR`?Ocu0_Wme)?hM#-)BAvVVPjO^UE$zQjk2 zS6vS)0=pK~JG+G>>ip+5D2P`0T8{H7a&=z+>2+A%xCmRK#1#|0)Pi^nHbSj+471>JqJ(TY>x_m?AdLvGJd?)sbF z*;Gn55aLhoh)cHP!7oQrihg_e3OM{)u`#IYR+SV`KSOG&_lpy#dMQsO>}@NfKGTME zbA`Ggz^-q6wf~LR_-tL^ItYBWZi6*HuN zT1|BQoZDpV2{q_0x;gT?(mp|rw9pxJS-;7D^IDsZO*uk6`h)JoO*`GI%{^LCG?{m!md5-#@M}_}}|38dD zEAfN=F2Mh{Iq08*These classes and articles help you build an app that's smooth, responsive, +and uses as little battery as possible.

    \ No newline at end of file diff --git a/docs/html/training/best-security.jd b/docs/html/training/best-security.jd new file mode 100644 index 000000000000..ddd0cf62f05b --- /dev/null +++ b/docs/html/training/best-security.jd @@ -0,0 +1,9 @@ +page.title=Best Practices for Security & Privacy +page.trainingcourse=true + +@jd:body + + + +

    These classes and articles provide information about how to +keep your app's data secure.

    \ No newline at end of file diff --git a/docs/html/training/best-ux.jd b/docs/html/training/best-ux.jd new file mode 100644 index 000000000000..5f109f6e459b --- /dev/null +++ b/docs/html/training/best-ux.jd @@ -0,0 +1,12 @@ +page.title=Best Practices for User Experience & UI +page.trainingcourse=true + +@jd:body + + + +

    These classes focus on the best Android user experience for your app. +In some cases, the success of your app on Android is heavily +affected by whether your app conforms to the user's expectations for +UI and navigation on an Android device. Follow these recommendations to ensure that +your app looks and behaves in a way that satisfies Android users.

    \ No newline at end of file diff --git a/docs/html/training/building-connectivity.jd b/docs/html/training/building-connectivity.jd new file mode 100644 index 000000000000..8b145ad3ac09 --- /dev/null +++ b/docs/html/training/building-connectivity.jd @@ -0,0 +1,10 @@ +page.title=Building Apps with Connectivity & the Cloud +page.trainingcourse=true + +@jd:body + + + +

    These classes teach you how to connect your app to the world beyond the user's device. +You'll learn how to connect to other devices in the area, connect to the Internet, backup and +sync your app's data, and more.

    \ No newline at end of file diff --git a/docs/html/training/building-graphics.jd b/docs/html/training/building-graphics.jd new file mode 100644 index 000000000000..ee79a5b1fad4 --- /dev/null +++ b/docs/html/training/building-graphics.jd @@ -0,0 +1,11 @@ +page.title=Building Apps with Graphics & Animation +page.trainingcourse=true + +@jd:body + + + +

    These classes teach you how to accomplish tasks with graphics +that can give your app an edge on the competition. +If you want to go beyond the basic user interface to create a beautiful visual experience, +these classes will help you get there.

    \ No newline at end of file diff --git a/docs/html/training/building-multimedia.jd b/docs/html/training/building-multimedia.jd new file mode 100644 index 000000000000..95e7811aadf5 --- /dev/null +++ b/docs/html/training/building-multimedia.jd @@ -0,0 +1,9 @@ +page.title=Building Apps with Multimedia +page.trainingcourse=true + +@jd:body + + + +

    These classes teach you how to +create rich multimedia apps that behave the way users expect.

    \ No newline at end of file diff --git a/docs/html/training/building-userinfo.jd b/docs/html/training/building-userinfo.jd new file mode 100644 index 000000000000..f9d77f762824 --- /dev/null +++ b/docs/html/training/building-userinfo.jd @@ -0,0 +1,9 @@ +page.title=Building Apps with User Info & Location +page.trainingcourse=true + +@jd:body + + +

    These classes teach you how to add user personalization to your app. Some of the ways +you can do this is by identifying users, providing +information that's relevant to them, and providing information about the world around them.

    \ No newline at end of file diff --git a/docs/html/training/distribute.jd b/docs/html/training/distribute.jd new file mode 100644 index 000000000000..4b21020ad65d --- /dev/null +++ b/docs/html/training/distribute.jd @@ -0,0 +1,9 @@ +page.title=Using Google Play to Distribute & Monetize +page.trainingcourse=true + +@jd:body + + + +

    These classes focus on the business aspects of your app strategy, including techniques +for distributing your app on Google Play and techniques for building revenue.

    \ No newline at end of file diff --git a/docs/html/training/index.jd b/docs/html/training/index.jd index 3c67af9dba2c..85fa19d354b9 100644 --- a/docs/html/training/index.jd +++ b/docs/html/training/index.jd @@ -1,14 +1,14 @@ -page.title=Android Training +page.title=Getting Started +page.trainingcourse=true page.metaDescription=Android Training provides a collection of classes that aim to help you build great apps for Android. Each class explains the steps required to solve a problem or implement a feature using code snippets and sample code for you to use in your apps. @jd:body -

    Welcome to Android Training. Here you'll find a collection of classes that aim to help you -build great apps for Android, using best practices in a variety of framework topics.

    -

    Each class explains the steps required to solve a problem or implement a feature using code -snippets and sample code for you to use in your apps.

    +

    Welcome to Training. Each class provides a series of lessons that +describe how to accomplish a specific task with code samples you can re-use in your app. +Classes are organized into several groups you can see at the top-level of the left navigation.

    -

    This first section is focused on teaching you the bare essentials. If you're a new developer -on Android, you should walk through each of these classes, beginning with -Building Your First App.

    +

    This first group, Getting Started, teaches you the bare +essentials for Android app development. +If you're a new Android app developer, you should complete each of these classes in order:

    \ No newline at end of file diff --git a/docs/html/training/perf-anr.jd b/docs/html/training/perf-anr.jd new file mode 100644 index 000000000000..864fb3403536 --- /dev/null +++ b/docs/html/training/perf-anr.jd @@ -0,0 +1,196 @@ +page.title=Keeping Your App Responsive +@jd:body + +
    + +
    + +
    + +

    Figure 1. An ANR dialog displayed to the user.

    +
    + +

    It's possible to write code that wins every performance test in the world, +but still feels sluggish, hang or freeze for significant periods, or take too +long to process input. The worst thing that can happen to your app's responsiveness +is an "Application Not Responding" (ANR) dialog.

    + +

    In Android, the system guards against applications that are insufficiently +responsive for a period of time by displaying a dialog that says your app has +stopped responding, such as the dialog +in Figure 1. At this point, your app has been unresponsive for a considerable +period of time so the system offers the user an option to quit the app. It's critical +to design responsiveness into your application so the system never displays +an ANR dialog to the user.

    + +

    This document describes how the Android system determines whether an +application is not responding and provides guidelines for ensuring that your +application stays responsive.

    + + +

    What Triggers ANR?

    + +

    Generally, the system displays an ANR if an application cannot respond to +user input. For example, if an application blocks on some I/O operation +(frequently a network access) on the UI thread so the system can't +process incoming user input events. Or perhaps the app +spends too much time building an elaborate in-memory +structure or computing the next move in a game on the UI thread. It's always important to make +sure these computations are efficient, but even the +most efficient code still takes time to run.

    + +

    In any situation in which your app performs a potentially lengthy operation, +you should not perform the work on the UI thread, but instead create a +worker thread and do most of the work there. This keeps the UI thread (which drives the user +interface event loop) running and prevents the system from concluding that your code +has frozen. Because such threading usually is accomplished at the class +level, you can think of responsiveness as a class problem. (Compare +this with basic code performance, which is a method-level +concern.)

    + +

    In Android, application responsiveness is monitored by the Activity Manager +and Window Manager system services. Android will display the ANR dialog +for a particular application when it detects one of the following +conditions:

    +
      +
    • No response to an input event (such as key press or screen touch events) + within 5 seconds.
      • +
    • A {@link android.content.BroadcastReceiver BroadcastReceiver} + hasn't finished executing within 10 seconds.
      • +
    + + + +

    How to Avoid ANRs

    + +

    Android applications normally run entirely on a single thread by default +the "UI thread" or "main thread"). +This means anything your application is doing in the UI thread that +takes a long time to complete can trigger the ANR dialog because your +application is not giving itself a chance to handle the input event or intent +broadcasts.

    + +

    Therefore, any method that runs in the UI thread should do as little work +as possible on that thread. In particular, activities should do as little as possible to set +up in key life-cycle methods such as {@link android.app.Activity#onCreate onCreate()} +and {@link android.app.Activity#onResume onResume()}. +Potentially long running operations such as network +or database operations, or computationally expensive calculations such as +resizing bitmaps should be done in a worker thread (or in the case of databases +operations, via an asynchronous request).

    + +

    The most effecive way to create a worker thread for longer +operations is with the {@link android.os.AsyncTask} +class. Simply extend {@link android.os.AsyncTask} and implement the +{@link android.os.AsyncTask#doInBackground doInBackground()} method to perform the work. +To post progress changes to the user, you can call + {@link android.os.AsyncTask#publishProgress publishProgress()}, which invokes the + {@link android.os.AsyncTask#onProgressUpdate onProgressUpdate()} callback method. From your + implementation of {@link android.os.AsyncTask#onProgressUpdate onProgressUpdate()} (which + runs on the UI thread), you can notify the user. For example:

    + +
    +private class DownloadFilesTask extends AsyncTask<URL, Integer, Long> {
+    // Do the long-running work in here
+    protected Long doInBackground(URL... urls) {
+        int count = urls.length;
+        long totalSize = 0;
+        for (int i = 0; i < count; i++) {
+            totalSize += Downloader.downloadFile(urls[i]);
+            publishProgress((int) ((i / (float) count) * 100));
+            // Escape early if cancel() is called
+            if (isCancelled()) break;
+        }
+        return totalSize;
+    }
+
+    // This is called each time you call publishProgress()
+    protected void onProgressUpdate(Integer... progress) {
+        setProgressPercent(progress[0]);
+    }
+
+    // This is called when doInBackground() is finished
+    protected void onPostExecute(Long result) {
+        showNotification("Downloaded " + result + " bytes");
+    }
+}
+
    + +

    To execute this worker thread, simply create an instance and + call {@link android.os.AsyncTask#execute execute()}:

    + +
    +new DownloadFilesTask().execute(url1, url2, url3);
+
    + + +

    Although it's more complicated than {@link android.os.AsyncTask}, you might want to instead +create your own {@link java.lang.Thread} or {@link android.os.HandlerThread} class. If you do, +you should set the thread priority to "background" priority by calling {@link +android.os.Process#setThreadPriority Process.setThreadPriority()} and passing {@link +android.os.Process#THREAD_PRIORITY_BACKGROUND}. If you don't set the thread to a lower priority +this way, then the thread could still slow down your app because it operates at the same priority +as the UI thread by default.

    + +

    If you implement {@link java.lang.Thread} or {@link android.os.HandlerThread}, +be sure that your UI thread does not block while waiting for the worker thread to +complete—do not call {@link java.lang.Thread#wait Thread.wait()} or +{@link java.lang.Thread#sleep Thread.sleep()}. Instead of blocking while waiting for a worker +thread to complete, your main thread should provide a {@link +android.os.Handler} for the other threads to post back to upon completion. +Designing your application in this way will allow your app's UI thread to remain +responsive to input and thus avoid ANR dialogs caused by the 5 second input +event timeout.

    + +

    The specific constraint on {@link android.content.BroadcastReceiver} execution time +emphasizes what broadcast receivers are meant to do: +small, discrete amounts of work in the background such +as saving a setting or registering a {@link android.app.Notification}. So as with other methods +called in the UI thread, applications should avoid potentially long-running +operations or calculations in a broadcast receiver. But instead of doing intensive +tasks via worker threads, your +application should start an {@link android.app.IntentService} if a +potentially long running action needs to be taken in response to an intent +broadcast.

    + +

    Tip: +You can use {@link android.os.StrictMode} to help find potentially +long running operations such as network or database operations that +you might accidentally be doing your main thread.

    + + + +

    Reinforce Responsiveness

    + +

    Generally, 100 to 200ms is the threshold beyond which users will perceive +slowness in an application. As such, here +are some additional tips beyond what you should do to avoid ANR and +make your application seem responsive to users:

    + +
      +
    • If your application is doing work in the background in response to + user input, show that progress is being made (such as with a {@link + android.widget.ProgressBar} in your UI).
      • + +
    • For games specifically, do calculations for moves in a worker + thread.
      • + +
    • If your application has a time-consuming initial setup phase, consider + showing a splash screen or rendering the main view as quickly as possible, indicate that + loading is in progress and fill the information asynchronously. In either case, you should + indicate somehow that progress is being made, lest the user perceive that + the application is frozen.
      • + +
    • Use performance tools such as Systrace + and Traceview to determine bottlenecks + in your app's responsiveness.
      • +
    diff --git a/docs/html/guide/practices/jni.jd b/docs/html/training/perf-jni.jd similarity index 99% rename from docs/html/guide/practices/jni.jd rename to docs/html/training/perf-jni.jd index ddfa0e3991f5..26b06b4f1a64 100644 --- a/docs/html/guide/practices/jni.jd +++ b/docs/html/training/perf-jni.jd @@ -1,8 +1,8 @@ page.title=JNI Tips @jd:body -
    -
    +
    +

    In this document

      diff --git a/docs/html/guide/practices/app-design/performance.jd b/docs/html/training/perf-tips.jd similarity index 56% rename from docs/html/guide/practices/app-design/performance.jd rename to docs/html/training/perf-tips.jd index 078999becc39..33b4b870bf6e 100644 --- a/docs/html/guide/practices/app-design/performance.jd +++ b/docs/html/training/perf-tips.jd @@ -1,21 +1,20 @@ -page.title=Designing for Performance +page.title=Performance Tips @jd:body -
      -
      + -

      An Android application will run on a mobile device with limited computing -power and storage, and constrained battery life. Because of -this, it should be efficient. Battery life is one reason you might -want to optimize your app even if it already seems to run "fast enough". -Battery life is important to users, and Android's battery usage breakdown -means users will know if your app is responsible draining their battery.

      - -

      Note that although this document primarily covers micro-optimizations, -these will almost never make or break your software. Choosing the right -algorithms and data structures should always be your priority, but is -outside the scope of this document.

      - - -

      Introduction

      +

      This document primarily covers micro-optimizations that can improve overall app performance +when combined, but it's unlikely that these changes will result in dramatic +performance effects. Choosing the right algorithms and data structures should always be your +priority, but is outside the scope of this document. You should use the tips in this document +as general coding practices that you can incorporate into your habits for general code +efficiency.

      There are two basic rules for writing efficient code:

        @@ -45,52 +36,31 @@ outside the scope of this document.

      • Don't allocate memory if you can avoid it.
      -

      Optimize Judiciously

      - -

      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. - -

      (See Closing Notes for more on profiling and -writing effective benchmarks.) - -

      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). - -

      (If you need that kind of advice, see Josh Bloch's Effective Java, -item 47.)

      -

      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 +app is that your app is certain to be running on multiple types of +hardware. 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" +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.

      -

      If you want to know how your app performs on a given device, you need to -test on that device.

      +

      To ensure your app performs well across a wide variety of devices, ensure +your code is efficient at all levels and agressively optimize your performance.

      - -

      Avoid Creating Unnecessary Objects

      -

      Object creation is never free. A generational GC with per-thread allocation +

      Avoid Creating Unnecessary Objects

      + +

      Object creation is never free. A generational garbage collector with per-thread allocation pools for temporary objects can make allocation cheaper, but allocating memory is always more expensive than not allocating memory.

      -

      If you allocate objects in a user interface loop, you will force a periodic +

      As you allocate more objects in your app, you will force a periodic garbage collection, creating little "hiccups" in the user experience. The -concurrent collector introduced in Gingerbread helps, but unnecessary work +concurrent garbage collector introduced in Android 2.3 helps, but unnecessary work should always be avoided.

      Thus, you should avoid creating object instances you don't need to. Some @@ -98,12 +68,12 @@ examples of things that can help:

      • If you have a method returning a string, and you know that its result - will always be appended to a StringBuffer anyway, change your signature + will always be appended to a {@link java.lang.StringBuffer} anyway, change your signature and implementation so that the function does the append directly, instead of creating a short-lived temporary object.
      • When extracting strings from a set of input data, try to return a substring of the original data, instead of creating a copy. - You will create a new String object, but it will share the char[] + You will create a new {@link java.lang.String} object, but it will share the {@code char[]} with the data. (The trade-off being that if you're only using a small part of the original input, you'll be keeping it all around in memory anyway if you go this route.)
        • @@ -113,16 +83,18 @@ examples of things that can help:

        parallel single one-dimension arrays:

          -
        • An array of ints is a much better than an array of Integers, +
        • An array of {@code int}s is a much better than an array of {@link java.lang.Integer} + objects, but this also generalizes to the fact that two parallel arrays of ints - are also a lot more efficient than an array of (int,int) + are also a lot more efficient than an array of {@code (int,int)} objects. The same goes for any combination of primitive types.
          • -
        • If you need to implement a container that stores tuples of (Foo,Bar) - objects, try to remember that two parallel Foo[] and Bar[] arrays are - generally much better than a single array of custom (Foo,Bar) objects. + +
        • If you need to implement a container that stores tuples of {@code (Foo,Bar)} + objects, try to remember that two parallel {@code Foo[]} and {@code Bar[]} arrays are + generally much better than a single array of custom {@code (Foo,Bar)} objects. (The exception to this, of course, is when you're designing an API for - other code to access; in those cases, it's usually better to trade - good API design for a small hit in speed. But in your own internal + other code to access. In those cases, it's usually better to make a small + compromise to the speed in order to achieve a good API design. But in your own internal code, you should try and be as efficient as possible.)
        @@ -130,66 +102,28 @@ parallel single one-dimension arrays:

        can. Fewer objects created mean less-frequent garbage collection, which has a direct impact on user experience.

        - - -

        Performance Myths

        - -

        Previous versions of this document made various misleading claims. We -address some of them here.

        -

        On devices without a JIT, it is true that invoking methods via a -variable with an exact type rather than an interface is slightly more -efficient. (So, for example, it was cheaper to invoke methods on a -HashMap map than a Map map, even though in both -cases the map was a HashMap.) It was not the case that this -was 2x slower; the actual difference was more like 6% slower. Furthermore, -the JIT makes the two effectively indistinguishable.

        -

        On devices without a JIT, caching field accesses is about 20% faster than -repeatedly accesssing the field. With a JIT, field access costs about the same -as local access, so this isn't a worthwhile optimization unless you feel it -makes your code easier to read. (This is true of final, static, and static -final fields too.) - -

        Prefer Static Over Virtual

        +

        Prefer Static Over Virtual

        If you don't need to access an object's fields, make your method static. Invocations will be about 15%-20% faster. It's also good practice, because you can tell from the method signature that calling the method can't alter the object's state.

        - -

        Avoid Internal Getters/Setters

        -

        In native languages like C++ it's common practice to use getters (e.g. -i = getCount()) instead of accessing the field directly (i -= mCount). This is an excellent habit for C++, because the compiler can -usually inline the access, and if you need to restrict or debug field access -you can add the code at any time.

        -

        On Android, this is a bad idea. Virtual method calls are expensive, -much more so than instance field lookups. It's reasonable to follow -common object-oriented programming practices and have getters and setters -in the public interface, but within a class you should always access -fields directly.

        - -

        Without a JIT, direct field access is about 3x faster than invoking a -trivial getter. With the JIT (where direct field access is as cheap as -accessing a local), direct field access is about 7x faster than invoking a -trivial getter. This is true in Froyo, but will improve in the future when -the JIT inlines getter methods.

        -

        Note that if you're using ProGuard, you can have the best -of both worlds because ProGuard can inline accessors for you.

        - -

        Use Static Final For Constants

        +

        Use Static Final For Constants

        Consider the following declaration at the top of a class:

        -
        static int intVal = 42;
-static String strVal = "Hello, world!";
        +
        +static int intVal = 42;
+static String strVal = "Hello, world!";
+

        The compiler generates a class initializer method, called <clinit>, that is executed when the class is first used. @@ -200,84 +134,125 @@ lookups.

        We can improve matters with the "final" keyword:

        -
        static final int intVal = 42;
-static final String strVal = "Hello, world!";
        +
        +static final int intVal = 42;
+static final String strVal = "Hello, world!";
+

        The class no longer requires a <clinit> method, because the constants go into static field initializers in the dex file. Code that refers to intVal will use the integer value 42 directly, and accesses to strVal will use a relatively inexpensive "string constant" instruction instead of a -field lookup. (Note that this optimization only applies to primitive types and -String constants, not arbitrary reference types. Still, it's good -practice to declare constants static final whenever possible.)

        +field lookup.

        + +

        Note: This optimization applies only to primitive types and +{@link java.lang.String} constants, not arbitrary reference types. Still, it's good +practice to declare constants static final whenever possible.

        + + + + + +

        Avoid Internal Getters/Setters

        + +

        In native languages like C++ it's common practice to use getters +(i = getCount()) instead of accessing the field directly (i += mCount). This is an excellent habit for C++ and is often practiced in other +object oriented languages like C# and Java, because the compiler can +usually inline the access, and if you need to restrict or debug field access +you can add the code at any time.

        + +

        However, this is a bad idea on Android. Virtual method calls are expensive, +much more so than instance field lookups. It's reasonable to follow +common object-oriented programming practices and have getters and setters +in the public interface, but within a class you should always access +fields directly.

        + +

        Without a JIT, +direct field access is about 3x faster than invoking a +trivial getter. With the JIT (where direct field access is as cheap as +accessing a local), direct field access is about 7x faster than invoking a +trivial getter.

        + +

        Note that if you're using ProGuard, +you can have the best of both worlds because ProGuard can inline accessors for you.

        + - -

        Use Enhanced For Loop Syntax

        -

        The enhanced for loop (also sometimes known as "for-each" loop) can be used -for collections that implement the Iterable interface and for arrays. + + +

        Use Enhanced For Loop Syntax

        + +

        The enhanced for loop (also sometimes known as "for-each" loop) can be used +for collections that implement the {@link java.lang.Iterable} interface and for arrays. With collections, an iterator is allocated to make interface calls -to hasNext() and next(). With an ArrayList, a hand-written counted loop is +to {@code hasNext()} and {@code next()}. With an {@link java.util.ArrayList}, +a hand-written counted loop is about 3x faster (with or without JIT), but for other collections the enhanced for loop syntax will be exactly equivalent to explicit iterator usage.

        There are several alternatives for iterating through an array:

        -
            static class Foo {
-        int mSplat;
-    }
-    Foo[] mArray = ...
+
        +static class Foo {
+    int mSplat;
+}
 
-    public void zero() {
-        int sum = 0;
-        for (int i = 0; i < mArray.length; ++i) {
-            sum += mArray[i].mSplat;
-        }
+Foo[] mArray = ...
+
+public void zero() {
+    int sum = 0;
+    for (int i = 0; i < mArray.length; ++i) {
+        sum += mArray[i].mSplat;
     }
+}
 
-    public void one() {
-        int sum = 0;
-        Foo[] localArray = mArray;
-        int len = localArray.length;
+public void one() {
+    int sum = 0;
+    Foo[] localArray = mArray;
+    int len = localArray.length;
 
-        for (int i = 0; i < len; ++i) {
-            sum += localArray[i].mSplat;
-        }
+    for (int i = 0; i < len; ++i) {
+        sum += localArray[i].mSplat;
     }
+}
 
-    public void two() {
-        int sum = 0;
-        for (Foo a : mArray) {
-            sum += a.mSplat;
-        }
+public void two() {
+    int sum = 0;
+    for (Foo a : mArray) {
+        sum += a.mSplat;
     }
+}
 
        
 
-
        zero() is slowest, because the JIT can't yet optimize away
+
        zero() is slowest, because the JIT can't yet optimize away
 the cost of getting the array length once for every iteration through the
 loop.
        
 
-
        one() is faster. It pulls everything out into local
+
        one() is faster. It pulls everything out into local
 variables, avoiding the lookups. Only the array length offers a performance
 benefit.
        
 
-
        two() is fastest for devices without a JIT, and
+
        two() is fastest for devices without a JIT, and
 indistinguishable from one() for devices with a JIT.
 It uses the enhanced for loop syntax introduced in version 1.5 of the Java
 programming language.
        
 
-
        To summarize: use the enhanced for loop by default, but consider a
-hand-written counted loop for performance-critical ArrayList iteration.
        
+
        So, you should use the enhanced for loop by default, but consider a
+hand-written counted loop for performance-critical {@link java.util.ArrayList} iteration.
        
+
+
        Tip:
+Also see Josh Bloch's Effective Java, item 46.
        
 
-
        (See also Effective Java item 46.)
        
 
-
-
        Consider Package Instead of Private Access with Private Inner Classes
        
+
+
        Consider Package Instead of Private Access with Private Inner Classes
        
 
 
        Consider the following class definition:
        
 
-
        public class Foo {
+
        +public class Foo {
     private class Inner {
         void stuff() {
             Foo.this.doStuff(Foo.this.mValue);
@@ -297,7 +272,7 @@ hand-written counted loop for performance-critical ArrayList iteration.
        
     }
 }
        
 
-
        The key things to note here are that we define a private inner class
+
        What's important here is that we define a private inner class
 (Foo$Inner) that directly accesses a private method and a private
 instance field in the outer class. This is legal, and the code prints "Value is
 27" as expected.
        
@@ -309,7 +284,8 @@ the Java language allows an inner class to access an outer class' private
 members. To bridge the gap, the compiler generates a couple of synthetic
 methods:
        
 
-
        /*package*/ static int Foo.access$100(Foo foo) {
+
        +/*package*/ static int Foo.access$100(Foo foo) {
     return foo.mValue;
 }
 /*package*/ static void Foo.access$200(Foo foo, int value) {
@@ -317,7 +293,7 @@ methods:
        
 }
        
 
 
        The inner class code calls these static methods whenever it needs to
-access the mValue field or invoke the doStuff method
+access the mValue field or invoke the doStuff() method
 in the outer class. What this means is that the code above really boils down to
 a case where you're accessing member fields through accessor methods.
 Earlier we talked about how accessors are slower than direct field
@@ -330,41 +306,52 @@ package access, rather than private access. Unfortunately this means the fields
 can be accessed directly by other classes in the same package, so you shouldn't
 use this in public API.
        
 
-
-
        Use Floating-Point Judiciously
        
+
+
+
+
        Avoid Using Floating-Point
        
 
 
        As a rule of thumb, floating-point is about 2x slower than integer on
-Android devices. This is true on a FPU-less, JIT-less G1 and a Nexus One with
-an FPU and the JIT. (Of course, absolute speed difference between those two
-devices is about 10x for arithmetic operations.)
        
+Android-powered devices.
        
 
 
        In speed terms, there's no difference between float and
 double on the more modern hardware. Space-wise, double
 is 2x larger. As with desktop machines, assuming space isn't an issue, you
 should prefer double to float.
        
 
-
        Also, even for integers, some chips have hardware multiply but lack
+
        Also, even for integers, some processors have hardware multiply but lack
 hardware divide. In such cases, integer division and modulus operations are
-performed in software — something to think about if you're designing a
+performed in software—something to think about if you're designing a
 hash table or doing lots of math.
        
 
-
-
        Know And Use The Libraries
        
+
+
+
+
        Know and Use the Libraries
        
 
 
        In addition to all the usual reasons to prefer library code over rolling
 your own, bear in mind that the system is at liberty to replace calls
 to library methods with hand-coded assembler, which may be better than the
 best code the JIT can produce for the equivalent Java. The typical example
-here is String.indexOf and friends, which Dalvik replaces with
-an inlined intrinsic. Similarly, the System.arraycopy method
+here is {@link java.lang.String#indexOf String.indexOf()} and
+related APIs, which Dalvik replaces with
+an inlined intrinsic. Similarly, the {@link java.lang.System#arraycopy
+System.arraycopy()} method
 is about 9x faster than a hand-coded loop on a Nexus One with the JIT.
        
 
-
        (See also Effective Java item 47.)
        
 
-
-
        Use Native Methods Judiciously
        
+
        Tip:
+Also see Josh Bloch's Effective Java, item 47.
        
 
-
        Native code isn't necessarily more efficient than Java. For one thing,
+
+
+
+
        Use Native Methods Carefully
        
+
+
        Developing your app with native code using the
+Android NDK
+isn't necessarily more efficient than programming with the
+Java language. For one thing,
 there's a cost associated with the Java-native transition, and the JIT can't
 optimize across these boundaries. If you're allocating native resources (memory
 on the native heap, file descriptors, or whatever), it can be significantly
@@ -376,22 +363,48 @@ processor in the G1 can't take full advantage of the ARM in the Nexus One, and
 code compiled for the ARM in the Nexus One won't run on the ARM in the G1.
        
 
 
        Native code is primarily useful when you have an existing native codebase
-that you want to port to Android, not for "speeding up" parts of a Java app.
        
+that you want to port to Android, not for "speeding up" parts of your Android app
+written with the Java language.
        
 
 
        If you do need to use native code, you should read our
 JNI Tips.
        
 
-
        (See also Effective Java item 54.)
        
+
        Tip:
+Also see Josh Bloch's Effective Java, item 54.
        
+
+
 
-
-
        Closing Notes
        
 
-
        One last thing: always measure. Before you start optimizing, make sure you
-have a problem. Make sure you can accurately measure your existing performance,
+
+
        Performance Myths
        
+
+
+
        On devices without a JIT, it is true that invoking methods via a
+variable with an exact type rather than an interface is slightly more
+efficient. (So, for example, it was cheaper to invoke methods on a
+HashMap map than a Map map, even though in both
+cases the map was a HashMap.) It was not the case that this
+was 2x slower; the actual difference was more like 6% slower. Furthermore,
+the JIT makes the two effectively indistinguishable.
        
+
+
        On devices without a JIT, caching field accesses is about 20% faster than
+repeatedly accesssing the field. With a JIT, field access costs about the same
+as local access, so this isn't a worthwhile optimization unless you feel it
+makes your code easier to read. (This is true of final, static, and static
+final fields too.)
+
+
+
+
        Always Measure
        
+
+
        Before you start optimizing, make sure you have a problem that you
+need to solve. Make sure you can accurately measure your existing performance,
 or you won't be able to measure the benefit of the alternatives you try.
        
 
 
        Every claim made in this document is backed up by a benchmark. The source
-to these benchmarks can be found in the code.google.com "dalvik" project.
        
+to these benchmarks can be found in the code.google.com
+"dalvik" project.
        
 
 
        The benchmarks are built with the
 Caliper microbenchmarking
@@ -407,4 +420,14 @@ 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.
+Traceview.
        
+
+
        For more help profiling and debugging your apps, see the following documents:
        
+
+
+
diff --git a/docs/html/training/security-tips.jd b/docs/html/training/security-tips.jd
new file mode 100644
index 000000000000..88d6017d670d
--- /dev/null
+++ b/docs/html/training/security-tips.jd
@@ -0,0 +1,759 @@
+page.title=Security Tips
+@jd:body
+
+
+
+
+
        Android has security features built
+into the operating system that significantly reduce the frequency and impact of
+application security issues. The system is designed so you can typically build your apps with
+default system and file permissions and avoid difficult decisions about security.
        
+
+
        Some of the core security features that help you build secure apps
+include:
+
          
+
        • The Android Application Sandbox, which isolates your app data and code execution
+from other apps.
          • 
+
        • An application framework with robust implementations of common
+security functionality such as cryptography, permissions, and secure
+IPC.
          • 
+
        • 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.
          • 
+
        • An encrypted filesystem that can be enabled to protect data on lost or
+stolen devices.
          • 
+
        • User-granted permissions to restrict access to system features and user data.
          • 
+
        • Application-defined permissions to control application data on a per-app basis.
          • 
+
        
+
+
        Nevertheless, it is important that you be familiar with the Android
+security best practices in this document. Following these practices as general coding habits
+will reduce the likelihood of inadvertently introducing security issues that
+adversely affect your users.
        
+
+
+
+
        Storing Data
        
+
+
        The most common security concern for an application on Android is whether the data
+that you save on the device is accessible to other apps. There are three fundamental
+ways to save data on the device:
        
+
+
        Using internal storage
        
+
+
        By default, files that you create on internal
+storage are accessible only to your app. This
+protection is implemented by Android and is sufficient for most
+applications.
        
+
+
        You should generally avoid using the {@link android.content.Context#MODE_WORLD_WRITEABLE} or
+{@link android.content.Context#MODE_WORLD_READABLE} modes for
+IPC files because they do not provide
+the ability to limit data access to particular applications, nor do they
+provide any control on data format. If you want to share your data with other
+app processes, you might instead consider using a
+content provider, which
+offers read and write permissions to other apps and can make
+dynamic permission grants on a case-by-case basis.
        
+
+
        To provide additional protection for sensitive data, you might
+choose to encrypt local files using a key that is not directly accessible to the
+application. For example, a key can be placed in a {@link java.security.KeyStore}
+and protected with a user password that is not stored on the device.  While this
+does not protect data from a root compromise that can monitor the user
+inputting the password,  it can provide protection for a lost device without file system
+encryption.
        
+
+
+
        Using external storage
        
+
+
        Files created on external
+storage, such as SD Cards, are globally readable and writable.  Because
+external storage can be removed by the user and also modified by any
+application,  you should not store sensitive information using
+external storage.
        
+
+
        As with data from any untrusted source, you should perform input
+validation when handling data from external storage.
+We strongly recommend that you not store executables or
+class files on external storage prior to dynamic loading.  If your app
+does retrieve executable files from external storage, the files should be signed and
+cryptographically verified prior to dynamic loading.
        
+
+
+
        Using content providers
        
+
+
        Content providers
+offer a structured storage mechanism that can be limited
+to your own application or exported to allow access by other applications.
+If you do not intend to provide other
+applications with access to your {@link android.content.ContentProvider}, mark them as 
+android:exported=false in the application manifest. Otherwise, set the android:exported
+attribute {@code "true"} to allow other apps to access the stored data.
+
        
+
+
        When creating a {@link android.content.ContentProvider}
+that will be exported for use by other applications, you can specify a single
+permission
+ 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.
        
+
+
        If you are using a content provider
+for sharing data between only your own apps, it is preferable to use the
+{@code
+android:protectionLevel} attribute set to {@code "signature"} protection.
+Signature permissions do not require user confirmation,
+so they provide a better user experience and more controlled access to the
+content provider data when the apps accessing the data are
+signed with
+the same key.
        
+
+
        Content providers can also provide more granular access by declaring the {@code
+android:grantUriPermissions} attribute and using the {@link
+android.content.Intent#FLAG_GRANT_READ_URI_PERMISSION} and {@link
+android.content.Intent#FLAG_GRANT_WRITE_URI_PERMISSION} flags in the
+{@link android.content.Intent} object
+that activates the component.  The scope of these permissions can be further
+limited by the 
+<grant-uri-permission element>.
        
+
+
        When accessing a content provider, use parameterized query methods such as 
+{@link android.content.ContentProvider#query(Uri,String[],String,String[],String) query()},
+{@link android.content.ContentProvider#update(Uri,ContentValues,String,String[]) update()}, and
+{@link android.content.ContentProvider#delete(Uri,String,String[]) delete()} to avoid
+potential SQL injection from untrusted sources. Note that using parameterized methods is not
+sufficient if the selection argument is built by concatenating user data
+prior to submitting it to the method.
        
+
+
        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 WHERE 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.
        
+
+
+
+
+
+
+
+
        Using Permissions
        
+
+
        Because Android sandboxes applications from each other, applications must explicitly
+share resources and data. They do this by declaring the permissions they need for additional
+capabilities not provided by the basic sandbox, including access to device features such as
+the camera.
        
+
+
+
        Requesting Permissions
        
+
+
        We recommend minimizing the number of permissions that your app requests
+Not having access to sensitive permissions reduces the risk of
+inadvertently misusing those permissions, can improve user adoption, and makes
+your app less for attackers. Generally,
+if a permission is not required for your app to function, do not request it.
        
+
+
        If it's possible to design your application in a way that does not require
+any permissions, that is preferable.  For example, rather than requesting access
+to device information to create a unique identifier, create a GUID for your application
+(see the section about Handling User Data). Or, rather than
+using external storage (which requires permission), store data
+on the internal storage.
        
+
+
        In addition to requesting permissions, your application can use the {@code <permissions>}
+to protect IPC that is security sensitive and will be exposed to other
+applications, such as a {@link android.content.ContentProvider}.
+In general, we recommend using access controls
+other than user confirmed permissions where possible because permissions can
+be confusing for users. For example, consider using the signature
+protection level on permissions for IPC communication between applications
+provided by a single developer.
        
+
+
        Do not leak permission-protected data.  This occurs when your app exposes data
+over IPC that is only available because it has a specific permission, but does
+not require that permission of any clients of it’s IPC interface. More
+details on the potential impacts, and frequency of this type of problem is
+provided in this research paper published at USENIX: http://www.cs.be
+rkeley.edu/~afelt/felt_usenixsec2011.pdf
        
+
+
+
+
        Creating Permissions
        
+
+
        Generally, you should strive to define as few permissions as possible while
+satisfying your security requirements.  Creating a new permission is relatively
+uncommon for most applications, because the system-defined
+permissions cover many situations.  Where appropriate,
+perform access checks using existing permissions.
        
+
+
        If you must create a new permission, consider whether you can accomplish
+your task with a "signature"
+protection level.  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 permission with the "dangerous"
+protection level, there are a number of complexities
+that you need to consider:
+
          
+
        • The permission must have a string that concisely expresses to a user the
+security decision they will be required to make.
          • 
+
        • The permission string must be localized to many different languages.
          • 
+
        • Users may choose not to install an application because a permission is
+confusing or perceived as risky.
          • 
+
        • Applications may request the permission when the creator of the permission
+has not been installed.
          • 
+
        
+
+
        Each of these poses a significant non-technical challenge for you as the developer
+while also confusing your users,
+which is why we discourage the use of the "dangerous" permission level.
        
+
+
+
+
+
+
        Using Networking
        
+
+
        Network transactions are inherently risky for security, because it involves transmitting
+data that is potentially private to the user. People are increasingly aware of the privacy
+concerns of a mobile device, especially when the device performs network transactions,
+so it's very important that your app implement all best practices toward keeping the user's
+data secure at all times.
        
+
+
        Using IP Networking
        
+
+
        Networking on Android is not significantly different from other Linux
+environments.  The key consideration is making sure that appropriate protocols
+are used for sensitive data, such as {@link javax.net.ssl.HttpsURLConnection} for
+secure web traffic.   We prefer use of HTTPS over HTTP anywhere that HTTPS is
+supported on the server, because mobile devices frequently connect on networks
+that are not secured, such as public Wi-Fi hotspots.
        
+
+
        Authenticated, encrypted socket-level communication can be easily
+implemented using the {@link javax.net.ssl.SSLSocket}
+class.  Given the frequency with which Android devices connect to unsecured
+wireless networks using Wi-Fi, the use of secure networking is strongly
+encouraged for all applications that communicate over the network.
        
+
+
        We have seen some applications use localhost network ports for
+handling sensitive IPC.  We discourage this approach since these interfaces are
+accessible by other applications on the device.  Instead, you should use an Android IPC
+mechanism where authentication is possible such as with a {@link android.app.Service}.  (Even
+worse than using loopback is to bind to INADDR_ANY since then your application
+may receive requests from anywhere.)
        
+
+
        Also, one common issue that warrants repeating is to make sure that you do
+not trust data downloaded from HTTP or other insecure protocols.  This includes
+validation of input in {@link android.webkit.WebView} and
+any responses to intents issued against HTTP.
        
+
+
+
        Using Telephony Networking
        
+
+
        The SMS protocol was primarily designed for
+user-to-user communication and is not well-suited for apps that want to transfer data.
+Due to the limitations of SMS, we strongly recommend the use of Google Cloud Messaging (GCM)
+and IP networking for sending data messages from a web server to your app on a user device.
        
+
+
        Beware that SMS is neither encrypted nor strongly
+authenticated on either the network or the device.  In particular, any SMS receiver
+should expect that a malicious user may have sent the SMS to your application—Do
+not rely on unauthenticated SMS data to perform sensitive commands.
+Also, you should be aware that SMS may be subject to spoofing and/or
+interception on the network.  On the Android-powered device itself, SMS
+messages are transmitted as broadcast intents, so they may be read or captured
+by other applications that have the {@link android.Manifest.permission#READ_SMS}
+permission.
        
+
+
+
+
+
+
        Performing Input Validation
        
+
+
        Insufficient input validation is one of the most common security problems
+affecting applications, regardless of what platform they run on. Android does
+have platform-level countermeasures that reduce the exposure of applications to
+input validation issues and you should use those features where possible. Also
+note that selection of type-safe languages tends to reduce the likelihood of
+input validation issues.
        
+
+
        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 buffer overflows, use after
+free, and off-by-one errors.
+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.
+You can prevent these vulneratbilities by careful handling pointers and managing
+buffers.
        
+
+
        Dynamic, string based languages such as JavaScript and SQL are also subject
+to input validation problems due to escape characters and script injection.
        
+
+
        If you are using data within queries that are submitted to an SQL database or a
+content provider, SQL injection may be an issue.  The best defense is to use
+parameterized queries, as is discussed in the above section about content providers.
+Limiting permissions to read-only or write-only can also reduce the potential
+for harm related to SQL injection.
        
+
+
        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.
        
+
+
+
+
+
+
        Handling User Data
        
+
+
        In general, the best approach for user data security is to minimize the use of APIs that access
+sensitive or personal user data. If you have access to user data and can avoid
+storing or transmitting the information, do not store or transmit the data.
+Finally, consider if there is a way that your application logic can be
+implemented using a hash or non-reversible form of the data.  For example, your
+application might use the hash of an an email address as a primary key, to
+avoid transmitting or storing the email address.  This reduces the chances of
+inadvertently exposing data, and it also reduces the chance of attackers
+attempting to exploit your application.
        
+
+
        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.
        
+
+
        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.
        
+
+
        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.
        
+
+
        Also, make sure that you do not inadvertently expose user data to other
+application on the device through overly permissive IPC, world writable files,
+or network sockets. This is a special case of leaking permission-protected data,
+discussed in the Requesting Permissions section.
        
+
+
        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 Android
+Developer Blog.
        
+
+
        Be careful when writing to on-device logs.
+In Android, logs are a shared resource, and are available
+to an application with the {@link android.Manifest.permission#READ_LOGS} permission.
+Even though the phone log data
+is temporary and erased on reboot, inappropriate logging of user information
+could inadvertently leak user data to other applications.
        
+
+
+
+
+
+
+
        Using WebView
        
+
+
        Because {@link android.webkit.WebView} consumes web content that can include HTML and JavaScript,
+improper use can introduce common web security issues such as cross-site-scripting
+(JavaScript injection).  Android includes a number of mechanisms to reduce
+the scope of these potential issues by limiting the capability of {@link android.webkit.WebView} to
+the minimum functionality required by your application.
        
+
+
        If your application does not directly use JavaScript within a {@link android.webkit.WebView}, do
+not call {@link android.webkit.WebSettings#setJavaScriptEnabled setJavaScriptEnabled()}.
+Some sample code uses this method, which you might repurpose in production
+application, so remove that method call if it's not required. By default,
+{@link android.webkit.WebView} does
+not execute JavaScript so cross-site-scripting is not possible.
        
+
+
        Use {@link android.webkit.WebView#addJavascriptInterface
+addJavaScriptInterface()} with
+particular care because it allows JavaScript to invoke operations that are
+normally reserved for Android applications.  If you use it, expose 
+{@link android.webkit.WebView#addJavascriptInterface addJavaScriptInterface()} only to
+web pages from which all input is trustworthy.  If untrusted input is allowed,
+untrusted JavaScript may be able to invoke Android methods within your app.  In general, we
+recommend exposing {@link android.webkit.WebView#addJavascriptInterface
+addJavaScriptInterface()} only to JavaScript that is contained within your application APK.
        
+
+
        If your application accesses sensitive data with a 
+{@link android.webkit.WebView}, you may want to use the
+{@link android.webkit.WebView#clearCache clearCache()} method to delete any files stored
+locally. Server-side
+headers like no-cache can also be used to indicate that an application should
+not cache particular content.
        
+
+
+
+
+
        Handling Credentials
        
+
+
        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.
        
+
+
        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.
        
+
+
        Services that will be accessible to multiple applications should be accessed
+using {@link android.accounts.AccountManager}. If possible, use the
+{@link android.accounts.AccountManager} class to invoke a cloud-based service and do not store
+passwords on the device.
        
+
+
        After using {@link android.accounts.AccountManager} to retrieve an
+{@link android.accounts.Account}, {@link android.accounts.Account#CREATOR}
+before passing in any credentials, so that you do not inadvertently pass
+credentials to the wrong application.
        
+
+
        If credentials are to be used only by applications that you create, then you
+can verify the application which accesses the {@link android.accounts.AccountManager} using
+{@link android.content.pm.PackageManager#checkSignatures checkSignature()}.
+Alternatively, if only one application will use the credential, you might use a
+{@link java.security.KeyStore} for storage.
        
+
+
+
+
+
+
        Using Cryptography
        
+
+
        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.
        
+
+
        In general, try to use the highest level of pre-existing framework
+implementation that can  support your use case.  If you need to securely
+retrieve a file from a known location, a simple HTTPS URI may be adequate and
+requires no knowledge of cryptography.  If you need a secure
+tunnel, consider using {@link javax.net.ssl.HttpsURLConnection} or
+{@link javax.net.ssl.SSLSocket}, rather than writing your own protocol.
        
+
+
        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 {@link javax.crypto.Cipher} class.
        
+
+
        Use a secure random number generator, {@link java.security.SecureRandom},
+to initialize any cryptographic keys, {@link javax.crypto.KeyGenerator}.
+Use of a key that is not generated with a secure random
+number generator significantly weakens the strength of the algorithm, and may
+allow offline attacks.
        
+
+
        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.
        
+
+
+
+
+
+
        Using Interprocess Communication
        
+
+
        Some apps attempt to implement IPC using traditional Linux
+techniques such as network sockets and shared files.  We strongly encourage you to instead
+use Android system functionality for IPC such as {@link android.content.Intent},
+{@link android.os.Binder} or {@link android.os.Messenger} with a {@link
+android.app.Service}, and {@link android.content.BroadcastReceiver}.
+The Android IPC mechanisms allow you to verify the identity of
+the application connecting to your IPC and set security policy for each IPC
+mechanism.
        
+
+
        Many of the security elements are shared across IPC mechanisms.
+If your IPC mechanism is not intended for use by other applications, set the
+{@code android:exported} attribute to {@code "false"} in the component's manifest element,
+such as for the {@code <service>}
+element.  This is useful for applications that consist of multiple processes
+within the same UID, or if you decide late in development that you do not
+actually want to expose functionality as IPC but you don’t want to rewrite
+the code.
        
+
+
        If your IPC is intended to be accessible to other applications, you can
+apply a security policy by using the {@code <permission>}
+element. If IPC is between your own separate apps that are signed with the same key,
+it is preferable to use {@code "signature"} level permission in the {@code
+android:protectionLevel}.
        
+
+
+
+
+
        Using intents
        
+
+
        Intents are the preferred mechanism for asynchronous IPC in Android.
+Depending on your application requirements, you might use {@link
+android.content.Context#sendBroadcast sendBroadcast()}, {@link
+android.content.Context#sendOrderedBroadcast sendOrderedBroadcast()},
+or an explicit intent to a specific application component.
        
+
+
        Note that ordered broadcasts can be “consumed” by a recipient, so they
+may not be delivered to all applications.  If you are sending an intent that muse be delivered
+to a specific receiver, then you must use an explicit intent that declares the receiver
+by nameintent.
        
+
+
        Senders of an intent can verify that the recipient has a permission
+specifying a non-Null permission with the method call.  Only applications with that
+permission will receive the intent.  If data within a broadcast intent may be
+sensitive, you should consider applying a permission to make sure that
+malicious applications cannot register to receive those messages without
+appropriate permissions.  In those circumstances, you may also consider
+invoking the receiver directly, rather than raising a broadcast.
        
+
+
        Note: Intent filters should not be considered
+a security feature—components
+can be invoked with explicit intents and may not have data that would conform to the intent
+filter. You should perform input validation within your intent receiver to
+confirm that it is properly formatted for the invoked receiver, service, or
+activity.
        
+
+
+
+
+
        Using services
        
+
+
        A {@link android.app.Service} is often used to supply functionality for other applications to
+use. Each service class must have a corresponding {@code } declaration in its
+manifest file.
        
+
+
        By default, services are not exported and cannot be invoked by any other
+application. However, if you add any intent filters to the service declaration, then it is exported
+by default. It's best if you explicitly declare the {@code
+android:exported} attribute to be sure it behaves as you'd like.
+Services can also be protected using the {@code android:permission}
+attribute. By doing so, other applications will need to declare
+a corresponding <uses-permission>
+ element in their own manifest to be
+able to start, stop, or bind to the service.
        
+
+
        A service can protect individual IPC calls into it with permissions, by
+calling {@link android.content.Context#checkCallingPermission
+checkCallingPermission()} before executing
+the implementation of that call.  We generally recommend using the
+declarative permissions in the manifest, since those are less prone to
+oversight.
        
+
+
+
+
        Using binder and messenger interfaces
        
+
+
        Using {@link android.os.Binder} or {@link android.os.Messenger} is the
+preferred mechanism for RPC-style IPC in Android. They provide a well-defined
+interface that enables mutual authentication of the endpoints, if required.
        
+
+
        We strongly encourage designing interfaces in a manner that does not require
+interface specific permission checks. {@link android.os.Binder} and
+{@link android.os.Messenger} objects are not declared within the
+application manifest, and therefore you cannot apply declarative permissions
+directly to them.  They generally inherit permissions declared in the
+application manifest for the {@link android.app.Service} or {@link
+android.app.Activity} within which they are
+implemented.  If you are creating an interface that requires authentication
+and/or access controls, those controls must be
+explicitly added as code in the {@link android.os.Binder} or {@link android.os.Messenger}
+interface.
        
+
+
        If providing an interface that does require access controls, use {@link
+android.content.Context#checkCallingPermission checkCallingPermission()}
+to verify whether the
+caller has a required permission. This is especially important
+before accessing a service on behalf of the caller, as the identify of your
+application is passed to other interfaces.  If invoking an interface provided
+by a {@link android.app.Service}, the {@link
+android.content.Context#bindService bindService()}
+ invocation may fail if you do not have permission to access the given service.
+ If calling an interface provided locally by your own application, it may be
+useful to use the {@link android.os.Binder#clearCallingIdentity clearCallingIdentity()}
+to satisfy internal security checks.
        
+
+
        For more information about performing IPC with a service, see
+Bound Services.
        
+
+
+
+
        Using broadcast receivers
        
+
+
        A {@link android.content.BroadcastReceiver} handles asynchronous requests initiated by
+an {@link android.content.Intent}.
        
+
+
        By default, receivers are exported and can be invoked by any other
+application. If your {@link android.content.BroadcastReceiver}
+is intended for use by other applications, you
+may want to apply security permissions to receivers using the 
+<receiver> element within the application manifest.  This will
+prevent applications without appropriate permissions from sending an intent to
+the {@link android.content.BroadcastReceiver}.
        
+
+
+
+
+
+
+
+
+
        Dynamically Loading Code
        
+
+
        We strongly discourage loading code from outside of your application APK.
+Doing so significantly increases the likelihood of application compromise due
+to code injection or code tampering.  It also adds complexity around version
+management and application testing.  Finally, it can make it impossible to
+verify the behavior of an application, so it may be prohibited in some
+environments.
        
+
+
        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.
        
+
+
        The major security risk associated with dynamically loading code is that the
+code needs to come from a verifiable source. If the modules are included
+directly within your APK, then they cannot be modified by other applications.
+This is true whether the code is a native library or a class being loaded using
+{@link dalvik.system.DexClassLoader}.  We have seen many instances of applications
+attempting to load code from insecure locations, such as downloaded from the
+network over unencrypted protocols or from world writable locations such as
+external storage. These locations could allow someone on the network to modify
+the content in transit, or another application on a users device to modify the
+content on the device, respectively.
        
+
+
+
+
+
+
        Security in a Virtual Machine
        
+
+
        Dalvik is Android's runtime virtual machine (VM). Dalvik was built specifically for Android,
+but many of the concerns regarding secure code in other virtual machines also apply to Android.
+In general, you shouldn't concern yourself with security issues relating to the virtual machine.
+Your application runs in a secure sandbox environment, so other processes on the system cannnot
+access your code or private data.
        
+
+
        If you're interested in diving deeper on the subject of virtual machine security,
+we recommend that you familiarize yourself with some
+existing literature on the subject. Two of the more popular resources are:
+
        
+
+
        This document is focused on the areas which are Android specific or
+different from other VM environments.  For developers experienced with VM
+programming in other environments, there are two broad issues that may be
+different about writing apps for Android:
+
          
+
        • 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.
          • 
+
+
        • Given the limited storage on mobile devices, it’s common for developers
+to want to build modular applications and use dynamic class loading.  When
+doing this, consider both the source where you retrieve your application logic
+and where you store it locally. Do not use dynamic class loading from sources
+that are not verified, such as unsecured network sources or external storage,
+because that code might be modified to include malicious behavior.
          • 
+
        
+
+
+
+
        Security in Native Code
        
+
+
        In general, we encourage developers to use the Android SDK for
+application development, rather than using native code with the
+Android NDK.  Applications built
+with native code are more complex, less portable, and more like to include
+common memory corruption errors such as buffer overflows.
        
+
+
        Android is built using the Linux kernel and being familiar with Linux
+development security best practices is especially useful if you are going to
+use native code. Linux security practices are beyond the scope of this document,
+but one of the most popular resources is “Secure Programming for
+Linux and Unix HOWTO”, available at 
+http://www.dwheeler.com/secure-programs.
        
+
+
        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 Android Security
+Overview and you should be familiar with application permissions even if
+you are using native code.
        
+
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index 1c85ae840188..ece55823e44c 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -4,741 +4,963 @@
   
      • 
     
        
       
-        Get Started
+        Getting Started
       
     
        
 
     
-  
        • 
-  
      • 
-    
        
-      
-      Advanced Training
-      
-    
        
-    
+  
        •     
+  
 
-       
      • 
-        
        
-            Performing Network Operations
-          
        
+  
      • 
+    
        
+      
+      Building Apps with
        Multimedia
+              
+    
        
+    
+  
        • 
+  
+      
+      
 
+  
      • 
+    
        
+      
+      Building Apps with
        Graphics & Animation
+              
+    
        
+    
+  
        • 
+  
       
+
+  
      • 
+    
        
+      
+      Building Apps with
        
+              Connectivity & the Cloud
+              
+    
        
+    
+  
        • 
+  
+  
+  
 
+  
      • 
+    
        
+      
+      Building Apps with
        
+              User Info & Location
+              
+    
        
+    
+  
        • 
+  
+      
+      
+
+  
      • 
+    
        
+      
+      Best Practices for
        
+              User Experience & UI
+              
+    
        
+    
+  
        • 
+  
+  
+      
 
+  
      • 
+    
        
+      
+      Best Practices for
        
+              Performance
+              
+    
        
+    
+  
        •  
+      
+      
 
+  
      • 
+    
        
+      
+      Best Practices for
        
+              Security & Privacy
+              
+    
        
+    
+  
        • 
+  
 
 
+  
      • 
+    
        
+      
+      Using Google Play to
        
+              Distribute & Monetize
+              
+    
        
+    
   
        • 
+  
+