Merge "Fix crash if drawable doesn't have constant state" into nyc-mr1-dev
diff --git a/core/java/android/os/RecoverySystem.java b/core/java/android/os/RecoverySystem.java
index 90bd11f..0b3abaa 100644
--- a/core/java/android/os/RecoverySystem.java
+++ b/core/java/android/os/RecoverySystem.java
@@ -93,6 +93,14 @@
*/
public static final File UNCRYPT_PACKAGE_FILE = new File(RECOVERY_DIR, "uncrypt_file");
+ /**
+ * UNCRYPT_STATUS_FILE stores the time cost (and error code in the case of a failure)
+ * of uncrypt.
+ *
+ * @hide
+ */
+ public static final File UNCRYPT_STATUS_FILE = new File(RECOVERY_DIR, "uncrypt_status");
+
// Length limits for reading files.
private static final int LOG_FILE_MAX_LENGTH = 64 * 1024;
diff --git a/docs/html/_redirects.yaml b/docs/html/_redirects.yaml
index 8ddb982..e71cf2b 100644
--- a/docs/html/_redirects.yaml
+++ b/docs/html/_redirects.yaml
@@ -842,6 +842,10 @@
to: /topic/performance/power/network/gather-data.html
- from: /training/performance/battery/network/index.html
to: /topic/performance/power/network/index.html
+- from: /training/articles/memory.html
+ to: /topic/performance/memory.html
+- from: /topic/performance/optimizing-view-hierarchies.html
+ to: /topic/performance/rendering/optimizing-view-hierarchies.html
# Redirects for the new [dac]/topic/libraries/ area
diff --git a/docs/html/topic/performance/_book.yaml b/docs/html/topic/performance/_book.yaml
index e053a2c..ba7c8b5 100644
--- a/docs/html/topic/performance/_book.yaml
+++ b/docs/html/topic/performance/_book.yaml
@@ -1,34 +1,61 @@
toc:
-- title: Reducing Network Battery Drain
- path: /topic/performance/power/network/index.html
+- title: Optimizing for Battery Life
+ path: /topic/performance/power/index.html
path_attributes:
- name: description
- value: Access the network while going easy on battery life.
+ value: Learn to make your app more battery-friendly.
section:
- - title: Collecting Network Traffic Data
- path: /topic/performance/power/network/gather-data.html
- - title: Analyzing Network Traffic Data
- path: /topic/performance/power/network/analyze-data.html
- - title: Optimizing User-Initiated Network Use
- path: /topic/performance/power/network/action-user-traffic.html
- - title: Optimizing Server-Initiated Network Use
- path: /topic/performance/power/network/action-server-traffic.html
- - title: Optimizing General Network Use
- path: /topic/performance/power/network/action-any-traffic.html
-- title: Implementing Doze
- path: /training/monitoring-device-state/doze-standby.html
+ - title: Network Use and Battery Consumption
+ path: /topic/performance/power/network/index.html
+ section:
+ - title: Collecting Network Traffic Data
+ path: /topic/performance/power/network/gather-data.html
+ - title: Analyzing Data Traffic
+ path: /topic/performance/power/network/analyze-data.html
+ - title: Optimizing User-Initiated Network Use
+ path: /topic/performance/power/network/action-user-traffic.html
+ - title: Optimizing App-Initiated Network Use
+ path: topic/performance/power/network/action-app-traffic.html
+ - title: Optimizing Server-Initiated Network Use
+ path: /topic/performance/power/network/action-server-traffic.html
+ - title: Optimizing General Network Use
+ path: /topic/performance/power/network/action-any-traffic.html
+ - title: Doze and App Standby
+ path: /training/monitoring-device-state/doze-standby.html
+ path_attributes:
+ - name: description
+ value: Help ensure the device isn't depleting the battery when not in use.
+ - title: Battery Historian
+ path: /topic/performance/power/battery-historian.html
+- title: Rendering
+ path: /topic/performance/rendering/index.html
path_attributes:
- name: description
- value: Help ensure the device isn't depleting the battery when not in use.
+ value: Speed up your app's rendering
+ section:
+ - title: Reducing Overdraw
+ path: /topic/performance/rendering/overdraw.html
+ - title: Optimizing View Hierarchies
+ path: /topic/performance/rendering/optimizing-view-hierarchies.html
+ - title: Using the Profile GPU Tool
+ path: /topic/performance/rendering/profile-gpu.html
+- title: Intelligent Job-Scheduling
+ path: /topic/performance/scheduling.html
+- title: Background Optimization
+ path: /topic/performance/background-optimization.html
+- title: Reducing APK Size
+ path: /topic/performance/reduce-apk-size.html
+- title: Reducing Image Download Sizes
+ path: /topic/performance/network-xfer.html
- title: Launch-Time Performance
path: /topic/performance/launch-time.html
- title: Better Performance through Threading
path: /topic/performance/threads.html
-- title: Optimizing View Hierarchies
- path: /topic/performance/optimizing-view-hierarchies.html
-- title: Background Optimization
- path: /topic/performance/background-optimization.html
-- title: Intelligent Job-Scheduling
- path: /topic/performance/scheduling.html
-- title: Reducing APK Size
- path: /topic/performance/reduce-apk-size.html
+- title: Manage Your App's Memory
+ path: /topic/performance/memory.html
+- title: Overview of Memory Managemement
+ path: /topic/performance/memory-overview.html
+ path_attributes:
+ - name: description
+ value: How to keep your app's memory footprint small in order to improve performance on a variety of mobile devices.
+
diff --git a/docs/html/topic/performance/images/app-rankings.png b/docs/html/topic/performance/images/app-rankings.png
new file mode 100644
index 0000000..9dd60e5
--- /dev/null
+++ b/docs/html/topic/performance/images/app-rankings.png
Binary files differ
diff --git a/docs/html/topic/performance/images/bars.png b/docs/html/topic/performance/images/bars.png
new file mode 100644
index 0000000..3afea46
--- /dev/null
+++ b/docs/html/topic/performance/images/bars.png
Binary files differ
diff --git a/docs/html/topic/performance/images/beforeafterindexed.png b/docs/html/topic/performance/images/beforeafterindexed.png
new file mode 100644
index 0000000..dc7762e
--- /dev/null
+++ b/docs/html/topic/performance/images/beforeafterindexed.png
Binary files differ
diff --git a/docs/html/topic/performance/images/comparison.png b/docs/html/topic/performance/images/comparison.png
new file mode 100644
index 0000000..18f204c
--- /dev/null
+++ b/docs/html/topic/performance/images/comparison.png
Binary files differ
diff --git a/docs/html/topic/performance/images/decisions.png b/docs/html/topic/performance/images/decisions.png
new file mode 100644
index 0000000..d4f21f8
--- /dev/null
+++ b/docs/html/topic/performance/images/decisions.png
Binary files differ
diff --git a/docs/html/topic/performance/images/dropdown.png b/docs/html/topic/performance/images/dropdown.png
new file mode 100644
index 0000000..59ec6110
--- /dev/null
+++ b/docs/html/topic/performance/images/dropdown.png
Binary files differ
diff --git a/docs/html/topic/performance/images/generic-timeline.png b/docs/html/topic/performance/images/generic-timeline.png
new file mode 100644
index 0000000..04388b6
--- /dev/null
+++ b/docs/html/topic/performance/images/generic-timeline.png
Binary files differ
diff --git a/docs/html/topic/performance/images/moarparrots.png b/docs/html/topic/performance/images/moarparrots.png
new file mode 100644
index 0000000..ee10ec1
--- /dev/null
+++ b/docs/html/topic/performance/images/moarparrots.png
Binary files differ
diff --git a/docs/html/topic/performance/images/palette.png b/docs/html/topic/performance/images/palette.png
new file mode 100644
index 0000000..eb6be6b
--- /dev/null
+++ b/docs/html/topic/performance/images/palette.png
Binary files differ
diff --git a/docs/html/topic/performance/images/parrot.png b/docs/html/topic/performance/images/parrot.png
new file mode 100644
index 0000000..7a8b86a
--- /dev/null
+++ b/docs/html/topic/performance/images/parrot.png
Binary files differ
diff --git a/docs/html/topic/performance/images/pug-visualization.png b/docs/html/topic/performance/images/pug-visualization.png
new file mode 100644
index 0000000..8270d0e
--- /dev/null
+++ b/docs/html/topic/performance/images/pug-visualization.png
Binary files differ
diff --git a/docs/html/topic/performance/images/pugspecificdata.png b/docs/html/topic/performance/images/pugspecificdata.png
new file mode 100644
index 0000000..1c2be83
--- /dev/null
+++ b/docs/html/topic/performance/images/pugspecificdata.png
Binary files differ
diff --git a/docs/html/topic/performance/images/s-generic-closeup.png b/docs/html/topic/performance/images/s-generic-closeup.png
new file mode 100644
index 0000000..6685d51
--- /dev/null
+++ b/docs/html/topic/performance/images/s-generic-closeup.png
Binary files differ
diff --git a/docs/html/topic/performance/images/s-profiler-legend.png b/docs/html/topic/performance/images/s-profiler-legend.png
new file mode 100644
index 0000000..968fd38
--- /dev/null
+++ b/docs/html/topic/performance/images/s-profiler-legend.png
Binary files differ
diff --git a/docs/html/topic/performance/images/vq.gif b/docs/html/topic/performance/images/vq.gif
new file mode 100644
index 0000000..cbf6a35
--- /dev/null
+++ b/docs/html/topic/performance/images/vq.gif
Binary files differ
diff --git a/docs/html/topic/performance/index.jd b/docs/html/topic/performance/index.jd
index e08db15..2b6b197 100644
--- a/docs/html/topic/performance/index.jd
+++ b/docs/html/topic/performance/index.jd
@@ -1,4 +1,4 @@
-page.title=Performance
+page.title=Performance and Power
page.article=true
page.metaDescription=Improve your app's performance by learning how to optimize power consumption, launch times, and other important areas of performance.
diff --git a/docs/html/topic/performance/memory-overview.jd b/docs/html/topic/performance/memory-overview.jd
new file mode 100644
index 0000000..58067d2
--- /dev/null
+++ b/docs/html/topic/performance/memory-overview.jd
@@ -0,0 +1,288 @@
+page.title=Overview of Android Memory Management
+page.tags=ram,memory,paging,mmap
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+<ol class="nolist">
+ <li><a href="#gc">Garbage collection</a></li>
+ <li><a href="#SharingRAM">Sharing Memory</a></li>
+ <li><a href="#AllocatingRAM">Allocating and Reclaiming App Memory</a></li>
+ <li><a href="#RestrictingMemory">Restricting App Memory</a></li>
+ <li><a href="#SwitchingApps">Switching Apps</a></li>
+</ol>
+<h2>See Also</h2>
+<ul>
+ <li><a href="{@docRoot}training/articles/memory.html">Manage Your App's Memory</a>
+ </li>
+ <li><a href="{@docRoot}studio/profile/investigate-ram.html">Investigating Your RAM Usage</a>
+ </li>
+</ul>
+
+</div>
+</div>
+
+<p>
+ The Android Runtime (ART) and Dalvik virtual machine use
+ <a href="http://en.wikipedia.org/wiki/Paging" class="external-link">paging</a>
+ and <a href="http://en.wikipedia.org/wiki/Memory-mapped_files" class="external-link">memory-mapping</a>
+ (mmapping) to manage memory. This means that any memory an app
+ modifies—whether by allocating
+ new objects or touching mmapped pages—remains resident in RAM and
+ cannot be paged out. The only way to release memory from an app is to release
+ object references that the app holds, making the memory available to the
+ garbage collector.
+ That is with one exception: any files
+ mmapped in without modification, such as code,
+ can be paged out of RAM if the system wants to use that memory elsewhere.
+</p>
+
+<p>
+ This page explains how Android manages app processes and memory
+ allocation. For more information about how to manage memory more efficiently
+ in your app, see
+ <a href="{@docRoot}training/articles/memory.html">Manage Your App's Memory</a>.
+</p>
+
+<!-- Section 1 #################################################### -->
+
+<h2 id="gc">Garbage collection</h2>
+
+<p>
+ A managed memory environment, like the ART or Dalvik virtual machine,
+ keeps track of each memory allocation. Once it determines
+ that a piece of memory is no longer being used by the program,
+ it frees it back to the heap, without any intervention from the programmer.
+ The mechanism for reclaiming unused memory
+ within a managed memory environment
+ is known as <i>garbage collection</i>. Garbage collection has two goals:
+ find data objects in a program that cannot be accessed in the future; and
+ reclaim the resources used by those objects.
+</p>
+
+<p>
+ Android’s memory heap is a generational one, meaning that there are
+ different buckets of allocations that it tracks,
+ based on the expected life and size of an object being allocated.
+ For example, recently allocated objects belong in the <i>Young generation</i>.
+ When an object stays active long enough, it can be promoted
+ to an older generation, followed by a permanent generation.
+</p>
+
+<p>
+ Each heap generation has its own dedicated upper limit on the amount
+ of memory that objects there can occupy. Any time a generation starts
+ to fill up, the system executes a garbage collection
+ event in an attempt to free up memory. The duration of the garbage collection
+ depends on which generation of objects it's collecting
+ and how many active objects are in each generation.
+</p>
+
+<p>
+ Even though garbage collection can be quite fast, it can still
+ affect your app's performance. You don’t generally control
+ when a garbage collection event occurs from within your code.
+ The system has a running set of criteria for determining when to perform
+ garbage collection. When the criteria are satisfied,
+ the system stops executing the process and begins garbage collection. If
+ garbage collection occurs in the middle of an intensive processing loop
+ like an animation or during music playback, it can increase processing time.
+ This increase can potentially push code execution in your app past the
+ recommended 16ms threshold for efficient and smooth frame rendering.
+</p>
+
+<p>
+ Additionally, your code flow may perform kinds of work that
+ force garbage collection events to occur
+ more often or make them last longer-than-normal.
+ For example, if you allocate multiple objects in the
+ innermost part of a for-loop during each frame of an alpha
+ blending animation, you might pollute your memory heap with a
+ lot of objects.
+ In that circumstance, the garbage collector executes multiple garbage
+ collection events and can degrade the performance of your app.
+</p>
+
+<p>
+ For more general information about garbage collection, see
+ <a href="https://en.wikipedia.org/wiki/Garbage_collection_(computer_science)"
+ class="external-link">Garbage collection</a>.
+</p>
+
+<!-- Section 2 #################################################### -->
+
+<h2 id="SharingRAM">Sharing Memory</h2>
+
+<p>
+ In order to fit everything it needs in RAM,
+ Android tries to share RAM pages across processes. It
+ can do so in the following ways:
+</p>
+
+<ul>
+ <li>
+ Each app process is forked from an existing process called Zygote.
+ The Zygote process starts when the system boots and loads common
+ framework code and resources
+ (such as activity themes). To start a new app process,
+ the system forks the Zygote process then
+ loads and runs the app's code in the new process.
+ This approach allows most of the RAM pages allocated for
+ framework code and resources to be shared across all app processes.
+ </li>
+
+ <li>
+ Most static data is mmapped into a process.
+ This technique allows data to be shared
+ between processes, and also allows it to be paged
+ out when needed. Example static data include:
+ Dalvik code (by placing it in a pre-linked <code>.odex</code>
+ file for direct mmapping), app resources
+ (by designing the resource table to be a structure
+ that can be mmapped and by aligning the zip
+ entries of the APK), and traditional project
+ elements like native code in <code>.so</code> files.
+ </li>
+
+ <li>
+ In many places, Android shares the same dynamic
+ RAM across processes using explicitly allocated
+ shared memory regions (either with ashmem or gralloc).
+ For example, window surfaces use shared
+ memory between the app and screen compositor, and
+ cursor buffers use shared memory between the
+ content provider and client.
+ </li>
+</ul>
+
+<p>
+ Due to the extensive use of shared memory, determining
+ how much memory your app is using requires
+ care. Techniques to properly determine your app's
+ memory use are discussed in
+ <a href="{@docRoot}studio/profile/investigate-ram.html">Investigating Your RAM Usage</a>.
+</p>
+
+<!-- Section 3 #################################################### -->
+
+<h2 id="AllocatingRAM">Allocating and Reclaiming App Memory</h2>
+
+<p>
+ The Dalvik heap is constrained to a
+ single virtual memory range for each app process. This defines
+ the logical heap size, which can grow as it needs to
+ but only up to a limit that the system defines
+ for each app.
+</p>
+
+<p>
+ The logical size of the heap is not the same as
+ the amount of physical memory used by the heap.
+ When inspecting your app's heap, Android computes
+ a value called the Proportional Set Size (PSS),
+ which accounts for both dirty and clean pages
+ that are shared with other processes—but only in an
+ amount that's proportional to how many apps share
+ that RAM. This (PSS) total is what the system
+ considers to be your physical memory footprint.
+ For more information about PSS, see the
+ <a href="{@docRoot}studio/profile/investigate-ram.html">Investigating Your RAM Usage</a>
+ guide.
+</p>
+
+<p>
+ The Dalvik heap does not compact the logical
+ size of the heap, meaning that Android does not
+ defragment the heap to close up space. Android
+ can only shrink the logical heap size when there
+ is unused space at the end of the heap. However,
+ the system can still reduce physical memory used by the heap.
+ After garbage collection, Dalvik
+ walks the heap and finds unused pages, then returns
+ those pages to the kernel using madvise. So, paired
+ allocations and deallocations of large
+ chunks should result in reclaiming all (or nearly all)
+ the physical memory used. However,
+ reclaiming memory from small allocations can be much
+ less efficient because the page used
+ for a small allocation may still be shared with
+ something else that has not yet been freed.
+
+</p>
+
+<!-- Section 4 #################################################### -->
+
+<h2 id="RestrictingMemory">Restricting App Memory</h2>
+
+<p>
+ To maintain a functional multi-tasking environment,
+ Android sets a hard limit on the heap size
+ for each app. The exact heap size limit varies
+ between devices based on how much RAM the device
+ has available overall. If your app has reached the
+ heap capacity and tries to allocate more
+ memory, it can receive an {@link java.lang.OutOfMemoryError}.
+</p>
+
+<p>
+ In some cases, you might want to query the
+ system to determine exactly how much heap space you
+ have available on the current device—for example, to
+ determine how much data is safe to keep in a
+ cache. You can query the system for this figure by calling
+ {@link android.app.ActivityManager#getMemoryClass() }.
+ This method returns an integer indicating the number of
+ megabytes available for your app's heap.
+</p>
+
+<!-- Section 5 #################################################### -->
+
+<h2 id="SwitchingApps">Switching apps</h2>
+
+<p>
+ When users switch between apps,
+ Android keeps apps that
+ are not foreground—that is, not visible to the user or running a
+ foreground service like music playback—
+ in a least-recently used (LRU) cache.
+ For example, when a user first launches an app,
+ a process is created for it; but when the user
+ leaves the app, that process does <em>not</em> quit.
+ The system keeps the process cached. If
+ the user later returns to the app, the system reuses the process, thereby
+ making the app switching faster.
+</p>
+
+<p>
+ If your app has a cached process and it retains memory
+ that it currently does not need,
+ then your app—even while the user is not using it—
+ affects the system's
+ overall performance. As the system runs low on memory,
+ it kills processes in the LRU cache
+ beginning with the process least recently used. The system also
+ accounts for processes that hold onto the most memory
+ and can terminate them to free up RAM.
+</p>
+
+<p class="note">
+ <strong>Note:</strong> When the system begins killing processes in the
+ LRU cache, it primarily works bottom-up. The system also considers which
+ processes consume more memory and thus provide the system
+ more memory gain if killed.
+ The less memory you consume while in the LRU list overall,
+ the better your chances are
+ to remain in the list and be able to quickly resume.
+</p>
+
+<p>
+ For more information about how processes are cached while
+ not running in the foreground and how
+ Android decides which ones
+ can be killed, see the
+ <a href="{@docRoot}guide/components/processes-and-threads.html">Processes and Threads</a>
+ guide.
+</p>
diff --git a/docs/html/topic/performance/memory.jd b/docs/html/topic/performance/memory.jd
new file mode 100644
index 0000000..ef1c4ae
--- /dev/null
+++ b/docs/html/topic/performance/memory.jd
@@ -0,0 +1,593 @@
+page.title=Manage Your App's Memory
+page.tags=ram,low memory,OutOfMemoryError,onTrimMemory
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+<ol>
+ <li><a href="#monitor">Monitor Available Memory and Memory Usage</a>
+ <ul>
+ <li><a href="#AnalyzeRam">Tools for analyzing RAM usage</a></li>
+ <li><a href="#release">Release memory in response to events</a></li>
+ <li><a href="#CheckHowMuchMemory">Check how much memory you should use</a></li>
+ </ul>
+ </li>
+ <li><a href="#code">Use More Efficient Code Constructs</a>
+ <ul>
+ <li><a href="#Services">Use services sparingly</a></li>
+ <li><a href="#DataContainers">Use optimized data containers</a></li>
+ <li><a href="#Abstractions">Be careful with code abstractions</a></li>
+ <li><a href="#NanoProto">Use nano protobufs for serialized data</a></li>
+ <li><a href="#churn">Avoid memory churn</a></li>
+ </ul>
+ </li>
+ <li><a href="#remove">Remove Memory-Intensive Resources and Libraries</a>
+ <ul>
+ <li><a href="#reduce">Reduce overall APK size</a></li>
+ <li><a href="#DependencyInjection">Avoid dependency injection frameworks</a></li>
+ <li><a href="#ExternalLibs">Be careful about using external libraries</a></li>
+ </ul>
+ </li>
+</ol>
+<h2>See Also</h2>
+<ul>
+ <li><a href="{@docRoot}training/articles/memory-overview.html">Overview of Android Memory Management</a>
+ </li>
+ <li><a href="{@docRoot}studio/profile/investigate-ram.html">Investigating Your RAM Usage</a>
+ </li>
+ <li><a href="{@docRoot}topic/performance/reduce-apk-size.html">Reduce APK Size</a></li>
+</ul>
+
+</div>
+</div>
+
+<!-- INTRO #################################################### -->
+
+<p>
+ Random-access memory (RAM) is a valuable
+ resource in any software development environment, but
+ it's even more valuable on a mobile operating system
+ where physical memory is often constrained.
+ Although both the Android Runtime (ART) and Dalvik virtual machine perform
+ routine garbage collection, this does not mean you can ignore
+ when and where your app allocates and releases memory.
+ You still need to avoid
+ introducing memory leaks, usually caused by holding onto
+ object references in static member variables, and
+ release any {@link java.lang.ref.Reference} objects at the appropriate
+ time as defined by
+ lifecycle callbacks.
+</p>
+
+<p>
+ This page explains how you can
+ proactively reduce memory usage within your app.
+ For more information about general
+ practices to clean up your resources when programming in Java,
+ refer to other books or online
+ documentation about managing resource references.
+ If you’re looking for information about how to
+ analyze memory in a running app, read
+ <a href="#AnalyzeRam">Tools for analyzing RAM usage</a>.
+ For more detailed information about how the Android Runtime and Dalvik
+ virtual machine manage memory, see the
+ <a href="{@docRoot}training/articles/memory-overview.html">Overview of Android Memory Management</a>.
+</p>
+
+<!-- Section 1 #################################################### -->
+
+<h2 id="monitor">Monitor Available Memory and Memory Usage</h2>
+
+<p>
+ The Android framework, Android Studio, and Android SDK
+ can help you analyze and adjust your app's memory usage.
+ The Android framework
+ exposes several APIs that allow your app to reduce its memory usage
+ dynamically during runtime. Android Studio and the Android SDK
+ contain several tools that allow you to investigate how your
+ app uses memory.
+</p>
+
+<!-- Section 1.1 #################################################### -->
+
+<h3 id="AnalyzeRam">Tools for analyzing RAM usage</h3>
+
+<p>
+ Before you can fix the memory usage problems in your app, you first need
+ to find them. Android Studio and the Android SDK include several tools
+ for analyzing memory usage in your app:
+</p>
+
+<ol>
+ <li>
+ The Device Monitor has a Dalvik Debug Monitor Server (DDMS) tool that allows
+ you to inspect memory allocation within your app process.
+ You can use this information to understand how your
+ app uses memory overall. For example, you can force a garbage collection
+ event and then view the types of objects that remain in memory. You can
+ use this information to identify operations or actions within your app
+ that allocate or leave excessive amounts of objects in memory.
+
+ <p>For more information about how to use the DDMS tool, see
+ <a href="/studio/profile/ddms.html">Using DDMS</a>.
+ </p>
+ </li>
+
+ <li>
+ The Memory Monitor in Android Studio shows you how your app allocates
+ memory over the course of a single session.
+ The tool shows a graph of available
+ and allocated Java memory over time, including garbage collection events.
+ You can also initiate garbage collection events and take a snapshot of
+ the Java heap while your app runs. The output from the Memory Monitor tool
+ can help you identify points when your app experiences excessive garbage
+ collection events, leading to app slowness.
+ <p>
+ For more information about how to use Memory Monitor tool, see
+ <a href="{@docRoot}tools/debugging/debugging-memory.html#ViewHeap">Viewing Heap Updates</a>.
+ </p>
+ </li>
+
+ <li>
+ Garbage collection events also show up in the Traceview viewer. Traceview
+ allows you to view trace log files as both a timeline and as a profile
+ of what happened within a method. You can use this tool to determine
+ what code was executing when a garbage collection event occurred.
+ <p>
+ For more information about how to use the Traceview viewer, see
+ <a href="https://developer.android.com/studio/profile/traceview.html">Profiling with Traceview and dmtracedump</a>.
+ </p>
+ </li>
+
+ <li>
+ The Allocation Tracker tool in Android Studio gives you a detailed look
+ at how your app allocates memory.
+ The Allocation Tracker records an app's memory allocations and lists
+ all allocated objects within the profiling snapshot. You can use this
+ tool to track down parts of your code that allocate too many objects.
+
+ <p>
+ For more information about how to use the Allocation Tracker tool, see
+ <a href="{docRoot}studio/profile/allocation-tracker-walkthru.html">Allocation Tracker Walkthrough</a>.
+ </p>
+ </li>
+
+</ol>
+
+<!-- Section 1.2 #################################################### -->
+
+<h3 id="release">Release memory in response to events</h3>
+
+<p>
+ An Android device can run with varying amounts of free memory
+ depending on the physical amount of RAM on the device and how the user
+ operates it. The system broadcasts signals to indicate when it is under
+ memory pressure, and apps should listen for these signals and adjust
+ their memory usage as appropriate.
+</p>
+
+</p>
+ You can use the {@link android.content.ComponentCallbacks2} API
+ to listen for these signals and then adjust your memory
+ usage in response to app lifecycle
+ or device events. The
+ {@link android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()}
+ method allows your app to listen for memory related events when the app runs
+ in the foreground (is visible) and when it runs in the background.
+</p>
+
+<p>
+ To listen for these events, implement the {@link
+ android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()}
+ callback in your {@link android.app.Activity}
+ classes, as shown in the following code snippet.
+</p>
+
+<pre class="prettyprint">
+import android.content.ComponentCallbacks2;
+// Other import statements ...
+
+public class MainActivity extends AppCompatActivity
+ implements ComponentCallbacks2 {
+
+ // Other activity code ...
+
+ /**
+ * Release memory when the UI becomes hidden or when system resources become low.
+ * @param level the memory-related event that was raised.
+ */
+ public void onTrimMemory(int level) {
+
+ // Determine which lifecycle or system event was raised.
+ switch (level) {
+
+ case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN:
+
+ /*
+ Release any UI objects that currently hold memory.
+
+ The user interface has moved to the background.
+ */
+
+ break;
+
+ case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE:
+ case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW:
+ case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL:
+
+ /*
+ Release any memory that your app doesn't need to run.
+
+ The device is running low on memory while the app is running.
+ The event raised indicates the severity of the memory-related event.
+ If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
+ begin killing background processes.
+ */
+
+ break;
+
+ case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND:
+ case ComponentCallbacks2.TRIM_MEMORY_MODERATE:
+ case ComponentCallbacks2.TRIM_MEMORY_COMPLETE:
+
+ /*
+ Release as much memory as the process can.
+
+ The app is on the LRU list and the system is running low on memory.
+ The event raised indicates where the app sits within the LRU list.
+ If the event is TRIM_MEMORY_COMPLETE, the process will be one of
+ the first to be terminated.
+ */
+
+ break;
+
+ default:
+ /*
+ Release any non-critical data structures.
+
+ The app received an unrecognized memory level value
+ from the system. Treat this as a generic low-memory message.
+ */
+ break;
+ }
+ }
+}
+</pre>
+
+<p>
+ The
+ {@link android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()}
+ callback was added in Android 4.0 (API level 14). For earlier versions,
+ you can use the
+ {@link android.content.ComponentCallbacks#onLowMemory()}
+ callback as a fallback for older versions, which is roughly equivalent to the
+ {@link android.content.ComponentCallbacks2#TRIM_MEMORY_COMPLETE} event.
+</p>
+
+<!-- Section 1.3 #################################################### -->
+
+<h3 id="CheckHowMuchMemory">Check how much memory you should use</h3>
+
+<p>
+ To allow multiple running processes, Android sets a hard limit
+ on the heap size alloted for each app. The exact heap size limit varies
+ between devices based on how much RAM the device
+ has available overall. If your app has reached the heap capacity and
+ tries to allocate more
+ memory, the system throws an {@link java.lang.OutOfMemoryError}.
+</p>
+
+<p>
+ To avoid running out of memory, you can to query the system to determine
+ how much heap space you have available on the current device.
+ You can query the system for this figure by calling
+ {@link android.app.ActivityManager#getMemoryInfo(android.app.ActivityManager.MemoryInfo) getMemoryInfo()}.
+ This returns an
+ {@link android.app.ActivityManager.MemoryInfo } object that provides
+ information about the device's
+ current memory status, including available memory, total memory, and
+ the memory threshold—the memory level below which the system begins
+ to kill processes. The
+ {@link android.app.ActivityManager.MemoryInfo } class also exposes a simple
+ boolean field,
+ {@link android.app.ActivityManager.MemoryInfo#lowMemory }
+ that tells you whether the device is running low on memory.
+</p>
+
+<p>
+ The following code snippet shows an example of how you can use the
+ {@link android.app.ActivityManager#getMemoryInfo(android.app.ActivityManager.MemoryInfo) getMemoryInfo()}.
+ method in your application.
+</p>
+
+<pre class="prettyprint">
+public void doSomethingMemoryIntensive() {
+
+ // Before doing something that requires a lot of memory,
+ // check to see whether the device is in a low memory state.
+ ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();
+
+ if (!memoryInfo.lowMemory) {
+ // Do memory intensive work ...
+ }
+}
+
+// Get a MemoryInfo object for the device's current memory status.
+private ActivityManager.MemoryInfo getAvailableMemory() {
+ ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
+ ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
+ activityManager.getMemoryInfo(memoryInfo);
+ return memoryInfo;
+}
+</pre>
+
+<!-- Section 2 #################################################### -->
+
+<h2 id="code">Use More Memory-Efficient Code Constructs</h2>
+
+<p>
+ Some Android features, Java classes, and code constructs tend to
+ use more memory than others. You can minimize how
+ much memory your app uses by choosing more efficient alternatives in
+ your code.
+</p>
+
+<!-- Section 2.1 #################################################### -->
+
+<h3 id="Services">Use services sparingly</h3>
+
+<p>
+ Leaving a service running when it’s not needed is
+ <strong>one of the worst memory-management
+ mistakes</strong> an Android app can make. If your app needs a
+ <a href="{@docRoot}guide/components/services.html">service</a>
+ to perform work in the background, do not keep it running unless
+ it needs to run a job. Remember to stop your service when it has completed
+ its task. Otherwise, you can inadvertently cause a memory leak.
+</p>
+
+<p>
+ When you start a service, the system prefers to always keep the process
+ for that service running. This behavior
+ makes services processes very expensive
+ because the RAM used by a service remains unavailable to other processes.
+ This reduces the number of cached processes that the system can keep in
+ the LRU cache, making app switching less efficient. It can even lead to
+ thrashing in the system when memory is tight and the system can’t
+ maintain enough processes to host all the services currently running.
+</p>
+
+<p>
+ You should generally avoid use of persistent services because of
+ the on-going demands they place on available memory. Instead, we
+ recommend that you use an alternative implementation
+ such as {@link android.app.job.JobScheduler}. For more information about
+ how to use {@link android.app.job.JobScheduler} to schedule background
+ processes, see
+ <a href="/topic/performance/background-optimization.html">Background Optimizations</a>.
+<p>
+ If you must use a service, the
+ best way to limit the lifespan of your service is to use an {@link
+ android.app.IntentService}, which finishes
+ itself as soon as it's done handling the intent that started it.
+ For more information, read
+ <a href="{@docRoot}training/run-background-service/index.html">Running in a Background Service</a>.
+</p>
+
+<!-- Section 2.2 #################################################### -->
+
+<h3 id="DataContainers">Use optimized data containers</h3>
+
+<p>
+ Some of the classes provided by the programming language are not optimized for
+ use on mobile devices. For example, the generic
+ {@link java.util.HashMap} implementation can be quite memory
+ inefficient because it needs a separate entry object for every mapping.
+</p>
+
+<p>
+ The Android framework includes several optimized data containers, including
+ {@link android.util.SparseArray}, {@link android.util.SparseBooleanArray},
+ and {@link android.support.v4.util.LongSparseArray}.
+ For example, the {@link android.util.SparseArray} classes are more
+ efficient because they avoid the system's need to
+ <acronym title="Automatic conversion from primitive types to object classes (such as int to Integer)">autobox</acronym>
+ the key and sometimes value (which creates yet another object or
+ two per entry).
+</p>
+
+<p>
+ If necessary, you can always switch to raw arrays for a really lean data
+ structure.
+</p>
+
+<!-- Section 2.3 #################################################### -->
+
+<h3 id="Abstractions">Be careful with code abstractions</h3>
+
+<p>
+ Developers often use abstractions simply as a good programming practice,
+ because abstractions can improve code flexibility and maintenance.
+ However, abstractions come at a significant cost:
+ generally they require a fair amount more code that
+ needs to be executed, requiring more time and
+ more RAM for that code to be mapped into memory.
+ So if your abstractions aren't supplying a
+ significant benefit, you should avoid them.
+</p>
+
+<p>
+ For example, enums often require more than twice as much memory as static
+ constants. You should strictly avoid using enums on Android.
+</p>
+
+<!-- Section 2.4 #################################################### -->
+
+<h3 id="NanoProto">Use nano protobufs for serialized data</h3>
+
+<p>
+ <a href="https://developers.google.com/protocol-buffers/docs/overview">Protocol buffers</a>
+ are a language-neutral, platform-neutral, extensible mechanism
+ designed by Google for serializing structured data—similar to XML, but
+ smaller, faster, and simpler. If you decide to use
+ protobufs for your data, you should always use nano protobufs in your
+ client-side code. Regular protobufs generate extremely verbose code, which
+ can cause many kinds of problems in your app such as
+ increased RAM use, significant APK size increase, and slower execution.
+</p>
+
+<p>
+ For more information, see the "Nano version" section in the
+ <a href="https://android.googlesource.com/platform/external/protobuf/+/master/java/README.txt"
+class="external-link">protobuf readme</a>.
+</p>
+
+<!-- Section 2.5 #################################################### -->
+
+<h3 id="churn">Avoid memory churn</h3>
+
+<p>
+ As mentioned previously, garbage collections events don't normally affect
+ your app's performance. However, many garbage collection events that occur
+ over a short period of time can quickly eat up your frame time. The more time
+ that the system spends on garbage collection, the less time it has to do
+ other stuff like rendering or streaming audio.
+</p>
+
+<p>
+ Often, <em>memory churn</em> can cause a large number of
+ garbage collection events to occur. In practice, memory churn describes the
+ number of allocated temporary objects that occur in a given amount of time.
+</p>
+
+<p>
+ For example, you might allocate multiple temporary objects within a
+ <code>for</code> loop. Or you might create new
+ {@link android.graphics.Paint} or {@link android.graphics.Bitmap}
+ objects inside the
+ {@link android.view.View#onDraw(android.graphics.Canvas) onDraw()}
+ function of a view.
+ In both cases, the app creates a lot of objects quickly at high volume.
+ These can quickly consume all the available memory in the young generation,
+ forcing a garbage collection event to occur.
+</p>
+
+<p>
+ Of course, you need to find the places in your code where
+ the memory churn is high before you can fix them. Use the tools discussed in
+ <a href="#AnalyzeRam">Analyze your RAM usage</a>
+</p>
+
+<p>
+ Once you identify the problem areas in your code, try to reduce the number of
+ allocations within performance critical areas. Consider moving things out of
+ inner loops or perhaps moving them into a
+ <a href="https://en.wikipedia.org/wiki/Factory_method_pattern" class="external-link">Factory</a>
+ based allocation structure.
+</p>
+
+<!-- Section 3 #################################################### -->
+
+<h2 id="remove">Remove Memory-Intensive Resources and Libraries</h2>
+
+<p>
+ Some resources and libraries within your code can gobble up memory without
+ you knowing it. Overall size of your APK, including third-party libraries
+ or embedded resources, can affect how much memory your app consumes. You can
+ improve your app's memory consumption by removing any redundant, unnecessary,
+ or bloated components, resources, or libraries from your code.
+</p>
+
+<!-- Section 3.1 #################################################### -->
+
+<h3 id="reduce">Reduce overall APK size</h3>
+
+<p>
+ You can significantly reduce your app's memory usage by reducing the overall
+ size of your app. Bitmap size, resources, animation frames, and third-party
+ libraries can all contribute to the size of your APK.
+ Android Studio and the Android SDK provide multiple tools
+ to help you reduce the size of your resources and external dependencies.
+</p>
+
+<p>
+ For more information about how to reduce your overall APK size, see
+ <a href="{@docRoot}topic/performance/reduce-apk-size.html">Reduce APK Size</a>.
+</p>
+
+<!-- Section 3.2 #################################################### -->
+
+<h3 id="DependencyInjection">Use caution with dependency injection frameworks</h3>
+
+<p>
+ Dependency injection framework such as
+ <a href="https://code.google.com/p/google-guice/" class="external-link">Guice</a>
+ or
+ <a href="https://github.com/roboguice/roboguice" class="external-link">RoboGuice</a>
+ can simplify the code you write and provide an adaptive environment
+ that's useful for testing and other configuration changes. However, dependency
+ frameworks aren't always optimized for mobile devices.
+</p>
+
+<p>
+ For example, these frameworks tend to initialize processes by
+ scanning your code for annotations. This which can require significant
+ amounts of your code to be mapped into RAM unnecessarily. The system
+ allocates these mapped pages into clean memory so Android can drop them; yet
+ that can't happen until the pages have remained in memory for a long period
+ of time.
+ </p>
+
+<p>
+ If you need to use a dependency injection framework in your app, consider
+ using
+ <a class="external-link" href="http://google.github.io/dagger/">Dagger</a>
+ instead. For example, Dagger does not use reflection to scan your app's code.
+ Dagger's strict implementation means that it can be used in Android apps
+ without needlessly increasing memory usage.
+</p>
+
+<!-- Section 3.3 #################################################### -->
+
+<h3 id="ExternalLibs">Be careful about using external libraries</h3>
+
+<p>
+ External library code is often not written for mobile environments and
+ can be inefficient when used
+ for work on a mobile client. When you decide to use an
+ external library, you may need to optimize that library for mobile devices.
+ Plan for that work up-front and analyze the library in terms of code size and
+ RAM footprint before deciding to use it at all.
+</p>
+
+<p>
+ Even some mobile-optimized libraries can cause problems due to differing
+ implementations. For example, one library may use nano protobufs
+ while another uses micro protobufs, resulting in two different protobuf
+ implementations in your app. This can happen with different
+ implementations of logging, analytics, image loading frameworks,
+ caching, and many other things you don't expect.
+</p>
+
+<p>
+ Although <a href="{@docRoot}tools/help/proguard.html">ProGuard</a> can
+ help to remove APIs and resources with the right flags, it can't remove a
+ library's large internal dependencies. The features that you want in these
+ libraries may require lower-level dependencies. This becomes especially
+ problematic when you use an {@link android.app.Activity } subclass from a
+ library (which will tend to have wide swaths of dependencies),
+ when libraries use reflection (which is common and means you need to spend a
+ lot of time manually tweaking ProGuard to get it to work), and so on.
+</p>
+
+<p>
+ Also avoid using a shared library for just one or two features out of dozens.
+ You don't want to pull in a large amount of code and overhead that
+ you don't even use. When you consider whether to use a library, look for
+ an implementation that strongly matches what you need. Otherwise, you might
+ decide to create your own implementation.
+</p>
+
diff --git a/docs/html/topic/performance/network-xfer.jd b/docs/html/topic/performance/network-xfer.jd
new file mode 100644
index 0000000..7fe5594
--- /dev/null
+++ b/docs/html/topic/performance/network-xfer.jd
@@ -0,0 +1,374 @@
+page.title=Reducing Image Download Sizes
+page.metaDescription=Improve network performance by optimizing image size.
+
+meta.tags="performance"
+page.tags="performance"
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+ <ol>
+
+ <li>
+ <a href="#uif">Understanding Image Formats</a>
+ <ul>
+ <li><a href="#png">PNG</a></li>
+ <li><a href="#jpg">JPG</a></li>
+ <li><a href="#webp">WebP</a></li>
+ </ul>
+ </li>
+ <li>
+ <a href="#sf">Selecting a Format</a></li>
+ <li><a href="#doqv">Determining Optimal Quality Values</a>
+ <ul>
+ <li><a href="#sv">Scalar Values (JPG, WebP only)</a></li>
+ <li><a href="#butter">Butteraugli</a></li>
+ </ul>
+ </li>
+ <li><a href="#sizes">Serving Sizes</a></li>
+ </ol>
+ </div>
+</div>
+
+<p>
+Most download traffic consists of images. As a result, the smaller you can make
+your downloadable images, the better a network experience your app can provide
+for users. This page provides guidance on making image files smaller and more
+network-friendly.
+</p>
+
+<h2 id="uif">Understanding Image Formats</h2>
+
+<p>Android apps typically use images that are in one or more of the following file
+formats: PNG, JPG, and WebP. For each of these formats, there are steps you can
+take to reduce image sizes.
+</p>
+
+<h3 id="png">PNG</h3>
+
+<p>
+A key to making your PNG files smaller is reducing the number of unique
+colors used in each row of pixels that comprises the image. By using fewer
+colors, you improve the compression potential at all of the other stages of
+the pipeline.
+</p>
+
+<p>
+Reducing the number of unique colors makes a significant difference because PNG
+compression effectiveness is partly a function of the degree to which
+horizontally adjacent pixel colors vary. Thus, reducing the number of unique
+colors in each row of your PNG images can help in reducing their file sizes.
+</p>
+
+<p>
+When deciding whether to pursue this strategy, you should keep in mind that
+reducing the number of unique colors effectively amounts to applying a lossy
+encoding stage to the image. However, an encoding tool may not be a good
+judge of how bad a seemingly small error looks to the human eye. Therefore,
+you should perform this work manually in order to help ensure
+the right balance between efficient compression and acceptable image quality.
+</p>
+
+<p>
+There are two particularly useful approaches you can take: striving for indexed
+formats, and applying vector quantization.
+</p>
+
+
+<h4 id="strive">Strive for indexed formats</h4>
+
+<p>
+Any attempt at color reduction should start with trying to optimize your colors
+so that you can use the INDEXED format when exporting the image as a PNG. The
+INDEXED color mode works by choosing the best 256 colors to use, and replacing
+all pixel values with indices into that color palette. The result is a
+reduction from 16 million (potential) colors to only 256 colors: from 3 (without
+transparency) or 4 (with transparency) bytes per pixel to 1 byte per pixel.
+This change is a significant first-step file size reduction.
+</p>
+
+<p>
+Figure 1 shows shows an image and its indexed variant.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/beforeafterindexed.png">
+ <p class="img-caption">
+Figure 1. An image before and after conversion to the INDEXED format.
+ </p>
+
+
+<p>
+Figure 2 shows the color palette for the image in Figure 1:
+</p>
+
+ <img src="{@docRoot}topic/performance/images/palette.png">
+ <p class="img-caption">
+Figure 2. The color palette for the image in Figure 1.
+ </p>
+
+<p>
+Representing your image as a paletted image goes a long way toward
+significantly improving the file size, so it's worth investigating if the
+majority of your images can be converted.
+</p>
+
+<p>
+Of course, not every image can be accurately represented with only 256 colors.
+Some images, for example, might need 257, 310, 512, or 912 colors to
+look correct. In such cases, vector quantization can also be helpful.
+</p>
+
+<h4 id="vq">Vector quantization</h4>
+
+<p>
+The process of creating an indexed image may be better described as vector
+quantization (VQ). VQ serves as a rounding process for multidimensional
+numbers. In this process, all the colors in your image get grouped based upon
+their similarity. For a given group, all colors in that group are replaced by a
+single <em>center point</em> value, which minimizes error for colors in that
+cell (or "site" if you're using the Voronoi terminology). In Figure 3,
+the green dots represent input colors, and the red dots are the center points
+that replace the input colors. Each cell is bounded by blue lines.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/vq.gif">
+ <p class="img-caption">
+Figure 3. Applying vector quantization to the colors in an image.
+</p>
+
+<p>
+The result of applying VQ to an image reduces the number of unique colors,
+replacing each group of colors with a single color that's "pretty close"
+in visual quality.
+</p>
+
+<p>
+This technique also allows you to define the maximum number of unique colors in
+your image. For example, Figure 4 shows the a parrot head in 16.7 million colors
+(24 bits per pixel, or bpp) alongside a version that only allows only
+16 (3 bpp) unique colors to be used.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/parrot.png">
+ <p class="img-caption">
+Figure 4. Image before and after application of vector quantification.
+ </p>
+
+<p>
+Immediately, you can see that there's a loss of quality; most of the gradient
+colors have been replaced, imparting a banding effect to the image. This image
+needs more than 16 unique colors.
+</p>
+
+<p>
+Setting up a VQ step in your pipeline can help you get a better sense of the
+true number of unique colors that your image uses, and can help you reduce them
+significantly. There are a number of readily available tools that you can use
+to help you implement this technique.
+</p>
+
+<h3 id="jpg">JPG</h3>
+
+<p>
+If you are using JPG images, there are several small changes you can make that
+potentially provide significant file-size savings. These include:
+</p>
+
+<ul>
+ <li>
+Producing a smaller file size through different encoding methods (without
+impacting quality).
+ </li>
+
+ <li>
+Adjusting quality slightly in order to yield better compression.
+ </li>
+</ul>
+
+<p>Pursuing these strategies can often net you file-size reductions of up to
+25%.
+</p>
+
+<p>
+When choosing tools, remember that photo exporting tools can
+insert unnecessary metadata, such as GPS information, into your images. At
+a minimum, try to leverage existing tools to help strip out this information
+from your files.
+</p>
+
+<h3 id="webp">WebP</h3>
+
+<p>
+WebP is a newer image format supported from Android 4.2.1 (API level 17). This
+format provides superior lossless and lossy compression for images on the web.
+Using WebP, developers can create smaller, richer images. WebP lossless image
+files are, on average,
+<a href="https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#conclusions">
+26% smaller</a> than PNGs. These image files also support
+transparency (also known as alpha channel) at a cost of just
+<a href="https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#results">
+22% more</a> bytes.
+</p>
+
+<p>
+WebP lossy images are
+<a href="https://developers.google.com/speed/webp/docs/webp_study#experiment_1_webp_vs_jpeg_at_equal_ssim_index">
+25-34% smaller</a> than comparable JPG images at equivalent
+<a href="https://en.wikipedia.org/wiki/Structural_similarity">SSIM</a>
+quality indices. For cases when lossy RGB compression is acceptable, lossy
+WebP also supports transparency, typically producing file sizes 3 times smaller
+than PNG.
+</p>
+
+<p>
+For more information about WebP, visit the
+<a href="https://developers.google.com/speed/webp/">WebP site</a>.
+</p>
+
+<h2 id="sf">Selecting a Format</h2>
+
+<p>
+Different image formats are suitable for different types of images. JPG and PNG
+have very different compression processes, and they produce quite different
+results.
+</p>
+
+<p>
+The decision between PNG and JPG often comes down to the complexity of the
+image itself. Figure 5 shows two images that come out quite differently
+depending on which compression scheme the developer applies. The image on the
+left has many small details, and thus compresses more efficiently with JPG. The
+image on the right, with runs of the same color, compresses more efficiently
+with PNG.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/comparison.png">
+ <p class="img-caption">
+Figure 5. Suitable cases for JPG vs. PNG
+ </p>
+
+
+<p>
+WebP as a format can support both lossy and lossless modes, making it an ideal
+replacement for both PNG and JPG. The only thing to keep in mind is that it
+only has native support on devices running Android 4.2.1 (API level 17) and
+higher. Fortunately, the large
+<a
+href="https://developer.android.com/about/dashboards/index.html#Platform">
+majority of devices</a> satisfy that requirement.
+</p>
+
+<p>
+Figure 6 provides a simple visualization to help you decide which compression
+scheme to use.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/decisions.png">
+ <p class="img-caption">
+Figure 6. Deciding on a compression scheme
+ </p>
+
+<h2 id="doqv">Determining Optimal Quality Values</h2>
+
+<p>
+There are several techniques you can use to achieve the right balance between
+compression and image quality. One technique uses scalar values and therefore
+only works for JPG and WebP. The other technique takes advantage of the
+Butteraugli library, and is usable for all image formats.
+</p>
+
+<h3 id="sv">Scalar values (JPG and WebP only)</h3>
+
+<p>
+The power of JPG and WebP comes from the fact that you can use a scalar value
+to balance quality against file size. The trick is finding out what the correct
+quality value is for your image. Too low a quality level produces a small file
+at the cost of image quality. Too high a quality level increases file size
+without providing a noticeable benefit to the user.
+</p>
+
+<p>
+The most straightforward solution is to pick some non-maximum value, and use
+that value. However, be aware that the quality value affects every image
+differently. While a quality of 75%, for example, may look fine on most images,
+there may be some cases do not fare as well. You should make sure to test your
+chosen maximum value against a representative sample of images. Also, make
+sure to perform all of your tests against the original images, and not on
+compressed versions.
+</p>
+
+<p>
+For large media applications that upload and re-send millions of JPGs a day,
+hand-tuning for each asset is impractical. You might address this challenge by
+specifying several different quality levels, according to image category. For
+example, you might set 35% as the quality setting for thumbnails, since a
+smaller image hides more compression artifacts.
+</p>
+
+<h3 id="butter">Butteraugli</h4>
+
+<p>
+The Butteraugli project is a library to test an image's Psychovisual Error
+Threshold: the point at which a viewer starts to notice image degradation. In
+other words, this project attempts to quantify how distorted your compressed
+image is.
+</p>
+
+<p>
+Butteraugli allows you to define a goal for visual quality, and then run PNG,
+JPG, WebP lossy, and WebP lossless compressions. You can then choose the image
+that is the best balance of file size and Butteraugli level. Figure 7 shows an
+example of how Butteraugli was used to find the minimal JPG quality level
+before the visual distortion was high enough for a user could perceive a
+problem; the result is a roughly 65% reduction in file size.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/moarparrots.png">
+ <p class="img-caption">
+Figure 7. An image before and after application of Butteraugli technology.
+ </p>
+
+<p>
+Butteraugli allows you to proceed based on either output or input. That is, you
+can look for the lowest quality setting before a user perceives noticeable
+distortion in the resulting image, or you can iteratively set image-distortion
+levels to learn their associated quality levels.
+</p>
+
+<h2 id="sizes">Serving Sizes</h2>
+
+<p>
+It is tempting to keep only a single resolution of an image on a server. When a
+device accesses the image, the server serves it at that one resolution and
+leaves downscaling to the device.
+</p>
+
+<p>
+This solution is convenient for the developer, but potentially painful for the
+user, because the solution forces the user to download much more data than they
+need.
+
+You should instead store multiple sizes of images, and serve the size that is
+most appropriate for a particular use case. For example, for a thumbnail,
+serving an actual thumbnail image instead of serving and downscaling a
+full-size version consumes much less network bandwidth
+</p>
+
+</p>
+This approach is good for download speed, and is less costly for users who may
+be using limited or metered data plans. Proceeding like this also results in
+the image's taking less space on the device and in main memory. In the
+case of large images, such as 4K ones, this approach also saves the device
+from having to resize images before loading them.
+</p>
+
+<p>
+Implementing this approach requires that you have a backend image service to
+provide images at various resolutions with proper caching. There are existing
+services that can provide help with this task. For example,
+<a href="https://cloud.google.com/appengine/">App Engine</a> comes
+with image resizing functionality already installed.
+</p>
diff --git a/docs/html/topic/performance/power/battery-historian.jd b/docs/html/topic/performance/power/battery-historian.jd
new file mode 100644
index 0000000..79ea59d
--- /dev/null
+++ b/docs/html/topic/performance/power/battery-historian.jd
@@ -0,0 +1,247 @@
+page.title=Analyzing Power Use with Battery Historian
+page.metaDescription=Improve network performance by optimizing image size.
+
+meta.tags="power"
+page.tags="power"
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+ <ol>
+ <li>
+ <a href="#sv">System-wide View</a>
+ </li>
+ <li>
+ <a href="#asd">App-Specific Data</a>
+ </li>
+ <li>
+ <a href="#usecases">Other Cases Where Battery Historian Can Help</a>
+ </li>
+ </ol>
+<h2>See also</h2>
+ <ol>
+ <li>
+ <a href="https://github.com/google/battery-historian">Battery Historian
+ on GitHub</a>
+ </li>
+
+ <li>
+ <a href="https://developer.android.com/studio/profile/battery-historian.html">
+ Batterystats and Battery Historian Walkthrough
+ </li>
+
+ <li>
+ <a href="https://youtu.be/VC2Hlb22mZM?list=PLOU2XLYxmsILe6_eGvDN3GyiodoV3qNSC&t=2063"
+ target="_blank">
+ Battery Historian talk at Google I/O 2016</a>
+ </li>
+ </ol>
+ </div>
+</div>
+
+<p>
+The Battery Historian tool provides insight into a device’s battery consumption
+over time. At a system-wide level, the tool visualizes power-related events from
+the system logs in an HTML representation. At an app-specific level, the tool
+provides a variety of data that can help you identify battery-draining app
+behavior.
+</p>
+
+<p>
+This document describes some of the ways you can use Battery Historian
+to learn about battery-consumption patterns. The document begins by explaining
+how to read the system-wide data that Battery Historian reports. Then,
+it presents ways in which you can use Battery Historian to diagnose
+and troubleshoot your own app's behavior related to battery consumption.
+Last, it offers several tips on scenarios in which Battery Historian may be
+particularly useful.
+</p>
+
+<h2 id="sv">System-wide View</h2>
+
+<p>
+The Battery Historian tool provides a system-wide visualization of various
+app and system behaviors, along with their correlation against battery
+consumption over time. This view, shown in Figure 1, can help you
+diagnose and identify power use issues with your app.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/generic-timeline.png">
+ <p class="img-caption">
+<strong>Figure 1.</strong>
+Battery Historian’s display of system-wide events affecting power
+consumption.
+ </p>
+
+<p>
+Of particular interest in this figure is the black, horizontal, downward trend
+line representing Battery Level, measured on the y-axis. For example, at the
+very beginning of the Battery Level line, at approximately 6:50 AM, the
+visualization shows a relatively steep drop in battery level.
+</p>
+
+<p>
+Figure 2 provides a close-up of that part of the display.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/s-generic-closeup.png">
+ <p class="img-caption">
+<strong>Figure 2.</strong>
+A close-up of the Battery Historian timeline from roughly 6:50 AM to 7:20 AM.
+ </p>
+
+<p>
+At the very beginning of the Battery Level line, as battery decline steeply,
+the display shows three things happening: The CPU is running, an app has
+acquired a wakelock, and the screen is on. In this way, Battery Historian helps
+you understand what events are happening when battery consumption is high. You
+can then target these behaviors in your app and investigate whether there are
+related optimizations you can make.
+</p>
+
+<p>
+The system-wide visualization can provide other clues, as well. For instance, if
+it shows that the mobile radio is frequently being turned off and on, there may
+be an opportunity to optimize this behavior through <a href=”intelligent
+scheduling page”>intelligent scheduling APIs</a> such as JobScheduler or
+Firebase Job Dispatcher.
+</p>
+
+<p>
+The next section explains how to investigate behavior and events specific to
+your own app.
+</p>
+
+<p>
+<h2 id="asd">App-Specific Data</h2>
+</p>
+
+<p>
+In addition to the macro-level data provided by the system-wide view, Battery
+Historian also provides tables and some visualization of data specific to each
+app running on your device. The tabular data includes:
+</p>
+
+<ul>
+ <li>The app’s estimated power use on the device.</li>
+ <li>Network information.</li>
+ <li>Wakelocks.</li>
+ <li>Services.</li>
+ <li>Process info.</li>
+</ul>
+
+<p>
+The tables provide two dimensions of data about your app. First, you can look
+up where your app’s power usage ranks compared to other apps. To do so, click
+<em>Device Power Estimates</em> table under <em>Tables</em>. This example
+examines a fictional app called Pug Power.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/app-rankings.png">
+ <p class="img-caption">
+<strong>Figure 3.</strong> Investigating which apps consume the most power.
+ </p>
+
+<p>
+The table in Figure 3 reveals that Pug Power is the ninth biggest consumer of
+battery power on this device, and the third biggest app that is not part of the
+OS. This data suggests that this app bears deeper investigation.
+</p>
+
+<p>
+To look up the data for a specific app, enter its package name into the lower
+of the two dropdown menus under <em>App Selection</em>, located under the left
+side of the visualization.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/dropdown.png">
+ <p class="img-caption">
+<strong>Figure 4.</strong> Entering a specific app whose data to view.
+ </p>
+
+<p>
+When you select a specific app, the following data visualization categories
+change to display app-specific data instead of system-wide data:
+</p>
+
+<ul>
+ <li>SyncManager.</li>
+ <li>Foreground process.</li>
+ <li>Userspace Wakelock.</li>
+ <li>Top app.</li>
+ <li>JobScheduler.</li>
+ <li>Activity Manager Proc.</li>
+</ul>
+
+The SyncManager and JobScheduler visualizations immediately make it obvious if
+your app performs syncs and executes jobs more frequently than necessary. In
+doing so, they can quickly reveal an opportunity to optimize your app’s
+behavior for improved battery performance.
+
+<p>
+You can also obtain one more piece of app-specific visualization data,
+<em>Userspace Wakelock</em>. To include this information in the bug report,
+enter the following command in your terminal window:
+</p>
+
+<pre>
+$ adb shell dumpsys batterystats --enable full-wake-history
+</pre>
+
+<p class="note">
+<strong>Note:</strong> From Android 6.0 (API level 23), the platform includes
+Doze functionality, which imposes certain optimizations on apps. For example,
+Doze batches jobs to take place during brief maintenance windows, regardless of
+how JobScheduler has scheduled them.
+</p>
+
+<p>
+Figures 5 and 6 show data for Pug Power: Figure 5
+shows the visualization of
+the app-specific data, and Figure 6 shows the corresponding tabular data.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/pug-visualization.png">
+ <p class="img-caption">
+<strong>Figure 5.</strong> Visualization of data for fictional app Pug Power.
+ </p>
+
+ <img src="{@docRoot}topic/performance/images/pugspecificdata.png">
+ <p class="img-caption">
+<strong>Figure 6.</strong> Tabular data for the fictional Pug Power app.
+ </p>
+
+<p>
+A look at the visualization does not show anything immediately obvious.
+The JobScheduler line shows that the app has no jobs scheduled. The SyncManager
+line shows that the app has not performed any syncs.
+</p>
+
+<p>
+However, examination of the <em>Wakelocks</em> segment of the tabular data
+reveals that Pug Power acquires wakelocks totaling over an hour. This unusual
+and costly behavior can account for the app’s high level of power consumption.
+This piece of information helps the developer target an area where optimization
+is likely to greatly help. In this case, why does the app acquire so much
+wakelock time, and how can the developer ameliorate this behavior?
+</p>
+
+<h2 id="usecases">Other Cases Where Battery Historian Can Help</h2>
+
+<p>
+There are many other cases in which Battery Historian can help you diagnose
+opportunities for improving battery behavior. For example, Battery Historian
+can tell you if your app is:
+</p>
+
+<ul>
+ <li>Firing wakeup alarms overly frequently (every 10 seconds or less).</li>
+ <li>Continuously holding a GPS lock.</li>
+ <li>Scheduling jobs every 30 seconds or less.</li>
+ <li>Scheduling syncs every 30 seconds or less.</li>
+ <li>Using the cellular radio more frequently than you expect.</li>
+</ul>
+
diff --git a/docs/html/topic/performance/power/index.jd b/docs/html/topic/performance/power/index.jd
new file mode 100644
index 0000000..88addce
--- /dev/null
+++ b/docs/html/topic/performance/power/index.jd
@@ -0,0 +1,125 @@
+page.title=Optimizing for Battery Life
+page.metaDescription=Learn how to help your app go easier on the battery.
+
+meta.tags="performance"
+page.tags="performance"
+
+@jd:body
+
+<div id="qv-wrapper">
+ <div id="qv">
+ <h2>
+ In this document
+ </h2>
+ <ol>
+ <li>
+ <a href="#lazy">Lazy First</a>
+ </li>
+ <li>
+ <a href="#features">Platform Features</a>
+ </li>
+ <li>
+ <a href="#toolery">Tooling</a>
+ </li>
+ </ol>
+ </div>
+</div>
+
+<p>Battery life is the single most important aspect of the mobile user
+experience. A device without power offers no functionality at all.
+For this reason, it is critically important that apps be as respectful of
+battery life as possible.</p>
+
+<p>There are three important things to keep in mind in keeping your app
+power-thrifty:</p>
+<ul>
+<li>Make your apps <em>Lazy First</em>.</li>
+<li>Take advantage of platform features that can help manage your app's battery
+consumption.</li>
+<li>Use tools that can help you identify battery-draining culprits.</li>
+</ul>
+
+<h2 id="lazy">Lazy First</h2>
+
+<p>Making your app Lazy First means looking for ways to reduce and optimize
+operations that are particularly battery-intensive. The core questions
+underpinning Lazy First design are:
+
+<ul>
+
+ <li><strong>Reduce:</strong> Are there redundant operations your app can cut
+out? For example, can it cache downloaded data instead of repeatedly waking
+ up the radio to re-download the data?</li>
+
+ <li><strong>Defer:</strong> Does an app need to perform an action right
+ away? For example,
+ can it wait until the device is charging before it backs data up to the
+ cloud?</li>
+
+ <li><strong>Coalesce:</strong> Can work be batched, instead of putting the
+ device
+ into an active state many times? For example, is it really necessary for
+ several dozen apps to each turn on the radio at separate times to send
+ their messages? Can the messages instead be transmitted during a
+ single awakening of the radio?</li>
+</ul>
+
+<p>
+You should ask these questions when it comes to using the CPU,
+the radio, and the screen. Lazy First design is often a good way
+to tame these battery killers.
+</p>
+
+<p>
+To help you achieve these and other efficiencies, the Android platform
+provides a number of features to help maximize battery life.
+</p>
+
+<h2 id="features">Platform Features</h2>
+
+<p>
+Broadly speaking, the Android platform provides two categories of help
+for you to optimize your app's battery use. First, it provides several
+APIs that you can implement in your app. You can learn more about these APIs in
+<a href="/topic/performance/scheduling.html">Intelligent Job Scheduling</a>
+and <a href="/performance/power/network/index.html">
+Network Use and Battery Consumption</a>.
+</p>
+
+<p>
+There are also internal mechanisms in the platform to help conserve
+battery life. While they are not APIs that you implement programmatically,
+you should still be aware of them so that your app can leverage them
+successfully. For more information, see
+<a href="/training/monitoring-device-state/doze-standby.html">Doze and
+App Standby</a>.</p>
+
+<p>
+You can get even more benefit out of these features by using the tools
+available for the platform to discover the parts of your app that consume
+the most power. Finding what to target is a big step toward
+successful optimization.
+</p>
+
+<h2 id ="toolery">Tooling</h2>
+
+<p>There are tools for Android, including
+<a href="/studio/profile/dev-options-rendering.html">Profile GPU Rendering</a>
+and <a class="external-link"
+href="https://github.com/google/battery-historian">Battery Historian</a>
+to help you identify areas that you can optimize for better battery life.
+Take advantage of these tools to target areas where you can apply the
+principles of Lazy First.
+</p>
+
+<section class="dac-section dac-small" id="latest-games"><div class="wrap">
+ <h2 class="norule" style="margin:0 0">More resources</h2>
+ <div class="resource-widget resource-flow-layout col-16"
+ data-query="collection:develop/performance/landing"
+ data-sortOrder="random"
+ data-cardSizes="6x6"
+ data-maxResults="24"
+ data-items-per-page="24"
+ data-initial-results="3"></div>
+ </div>
+</section>
diff --git a/docs/html/topic/performance/rendering/index.jd b/docs/html/topic/performance/rendering/index.jd
new file mode 100644
index 0000000..e04605c
--- /dev/null
+++ b/docs/html/topic/performance/rendering/index.jd
@@ -0,0 +1,60 @@
+page.title=Rendering
+page.article=true
+
+page.tags=battery
+page.metaDescription=Learn how to optimize your app's rendering performance.
+
+@jd:body
+
+
+<iframe width="448" height="252"
+ src="//www.youtube.com/embed/wIy8g8yNhNk?autohide=1&showinfo=0"
+ frameborder="0" allowfullscreen=""
+ style="float: right; margin: 0 0 20px 20px;"></iframe>
+
+<p>
+ A key aspect of your app that influences your users' perception of quality is
+ the smoothness with which it renders images and text to the screen. It is
+ important to avoid jank and sluggish responsiveness when your app is drawing
+ to the screen.
+</p>
+
+<p>
+ This section helps you learn several ways to optimize your app's rendering
+ performance: reducing overdraw, optimizing view hierarchies, and taking
+ advantage of the Profile GPU tool.
+</p>
+
+<h2>Rendering Actions</h2>
+
+<dl>
+ <dt>
+ <strong><a href="overdraw.html">
+ Reducing Overdraw</a></strong>
+ </dt>
+ <dd>
+ Minimize the number of times you app redraws the same pixel in a single
+ frame.
+ </dd>
+
+ <dt>
+ <strong><a href="profile-gpu.html">
+ Optimizing View Hierarchies</a></strong>
+ </dt>
+ <dd>
+ Make sure your layout and measurement are executing efficiently, and
+ avoid double taxation.
+ </dd>
+
+
+ <dt>
+ <strong><a href="profile-gpu.html">
+ Using the Profile GPU Tool</a></strong>
+ </dt>
+ <dd>
+ Take advantage of this on-device tool to identify bottlenecks that
+ may be slowing your app's rendering down.
+ </dd>
+
+
+</dl>
diff --git a/docs/html/topic/performance/optimizing-view-hierarchies.jd b/docs/html/topic/performance/rendering/optimizing-view-hierarchies.jd
similarity index 100%
rename from docs/html/topic/performance/optimizing-view-hierarchies.jd
rename to docs/html/topic/performance/rendering/optimizing-view-hierarchies.jd
diff --git a/docs/html/topic/performance/rendering/overdraw.jd b/docs/html/topic/performance/rendering/overdraw.jd
new file mode 100644
index 0000000..c1feff5
--- /dev/null
+++ b/docs/html/topic/performance/rendering/overdraw.jd
@@ -0,0 +1,197 @@
+page.title=Reducing Overdraw
+page.metaDescription=Improve performance by reducing unnecessary rendering.
+
+meta.tags="performance"
+page.tags="performance"
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+ <ol>
+
+ <li>
+ <a href="#understanding">Understanding Overdraw</a>
+ </li>
+ <li>
+ <a href="#finding">Finding Overdraw Problems</a>
+ </li>
+ <li>
+ <a href="#fixing">Fixing Overdraw</a>
+ </li>
+ </ol>
+ </div>
+</div>
+
+<p>
+An app may draw the same pixel more than once within a single frame, an event
+called <em>overdraw</em>. Overdraw is usually unnecessary, and best
+eliminated. It manifests itself as a performance problem by wasting GPU time to
+render pixels that don't contribute to what the user sees on the screen.
+</p>
+
+<p>
+This document explains overdraw: what it is, how to diagnose it, and actions you
+can take to eliminate or mitigate it.
+</p>
+
+<h2 name="understanding">Understanding Overdraw</h2>
+
+<p>
+Overdraw refers to the system's drawing a pixel on the screen multiple times
+in a single frame of rendering. For example, if we have a bunch of stacked UI
+cards, each card hides a portion of the one below it.
+</p>
+
+<p>
+However, the system still needs to draw even the hidden portions of the cards
+in the stack. This is because stacked cards are rendered according to the
+<a class="external-link"
+href="https://en.wikipedia.org/wiki/Painter%27s_algorithm">painter's
+algorithm</a>: that is, in back-to-front order.
+This sequence of rendering allows the system to apply proper alpha blending to
+translucent objects such as shadows.
+</p>
+
+<h2 name="finding">Finding Overdraw Problems</h2>
+
+<p>
+The platform offers several tools to help you determine if overdraw is
+affecting your app's performance. These tools are available right on the device,
+and accessible by turning on <strong>Developer Settings</strong></a> under
+<em>Settings</em>. For more information about device developer settings, see
+<a href="/studio/run/device.html#developer-device-options">Run Apps on a
+Hardware Device</a>.
+</p>
+
+<h3 id="dgot">Debug GPU overdraw tool</h3>
+
+<p>
+The Debug GPU Overdraw tool uses color-coding to show the number of times your
+app draws each pixel on the screen. The higher this count, the
+more likely it is that overdraw affects your app's performance.
+</p>
+
+<p>
+For more information on how to use the tool, refer to the related
+<a href="/studio/profile/dev-options-overdraw.html">walkthrough</a>
+and
+<a href="https://io2015codelabs.appspot.com/codelabs/android-performance-debug-gpu-overdraw#1">
+codelab</a>.
+</p>
+
+<h3 id="pgrt">Profile GPU rendering tool</h3>
+
+<p>
+The Profile GPU Rendering tool displays, as a scrolling histogram, the time
+each stage of the rendering pipeline takes to display a single frame. The
+<em>Process</em> part of each bar, indicated in orange, shows when the system
+is swapping buffers; this metric provides important clues about overdraw.
+</p>
+
+<p>
+On less performant GPUs, available fill-rate (the speed at which the GPU can
+fill the frame buffer) can be quite low. As the number of
+pixels required to draw a frame increases, the GPU may take longer to process
+new commands, and ask the rest of the system to wait until it can catch up.
+The <em>Process</em> bar shows that this spike happens as the GPU gets
+overwhelmed trying to draw pixels as fast as possible. Issues other than
+raw numbers of pixels may also cause this metric to spike. For example,
+if the Debug GPU Overdraw tool shows heavy overdraw and <em>Process</em> spikes,
+there's likely an issue with overdraw.
+</p>
+
+<p class="note"><strong>Note: </strong>The
+<a href="https://developer.android.com/studio/profile/dev-options-rendering.html">
+Profile GPU Rendering</a> tool does not
+work with apps that use the NDK. This is because the system pushes framework
+messages to the background whenever OpenGL takes a full-screen context. In
+such cases, you may find a profiling tool provided by the GPU manufacturer
+helpful.</p>
+
+<h2 name="fixing">Fixing Overdraw</h2>
+
+<p>
+There are several strategies you can pursue to reduce or eliminate overdraw:
+</p>
+
+<ul>
+ <li>Removing unneeded backgrounds in layouts.</li>
+ <li>Flattening the view hierarchy.</li>
+ <li>Reducing transparency.</li>
+</ul>
+
+<p>
+This section provides information about each of these approaches.
+</p>
+
+<h3 id="rubil">Removing unneeded backgrounds in layouts</h3>
+
+<p>
+By default, a layout does not have a background, which means it does not render
+anything directly by itself. When layouts do have backgrounds, however, they may
+contribute to overdraw.
+</p>
+
+<p>
+Removing unnecessary backgrounds is a quick way of improving rendering
+performance. An unnecessary background may never be visible because it's
+completely covered by everything else the app is drawing on top of that
+view. For example, the system may entirely cover up a parent's
+background when it draws child views on top of it.
+</p>
+
+<p>
+To find out why you're overdrawing, walk through the hierarchy in
+the <a href="/studio/profile/hierarchy-viewer.html">Hierarchy Viewer</a> tool.
+As you do so, look out for any backgrounds you can eliminate because
+they are not visible to the user. Cases where many containers share a
+common background color offer another opportunity to eliminate unneeded
+backgrounds: You can set the window background to the main background color
+of your app, and leave all of the containers above it with no background values
+defined.
+</p>
+
+<h3 id="fvh">Flattening view hierarchy</h3>
+
+<p>
+Modern layouts make it easy to stack and layer views to produce beautiful
+design. However, doing so can degrade performance by resulting in overdraw,
+especially in scenarios where each stacked view object is opaque, requiring the
+drawing of both seen and unseen pixels to the screen.
+</p>
+
+<p>
+If you encounter this sort of issue, you may be able to improve performance by
+optimizing your view hierarchy to reduce the number of overlapping UI objects.
+For more information about how to accomplish this, see
+<a href="/topic/performance/optimizing-view-hierarchies.html">Optimizing View
+Hierarchies</a>.
+</p>
+
+<h3 id="rt">Reducing transparency</h3>
+
+<p>
+Rendering of transparent pixels on screen, known as alpha rendering, is a key
+contributor to overdraw. Unlike standard overdraw,
+in which the system completely hides existing drawn pixels by drawing
+opaque pixels on top of them, transparent
+objects require existing pixels to be drawn first, so that the right blending
+equation can occur. Visual effects like transparent animations, fade-outs, and
+drop shadows all involve some sort of transparency, and can therefore contribute
+significantly to overdraw. You can improve overdraw in these situations by
+reducing the number of transparent objects you render. For example, you can get
+gray text by drawing black text in a {@link android.widget.TextView} with a
+translucent alpha value set on it. But you can get the same effect with far
+better performance by simply drawing the text in gray.
+</p>
+
+<p>
+To learn more about performance costs that transparency imposes throughout the
+entire drawing pipeline, watch the video
+<a href="https://www.youtube.com/watch?v=wIy8g8yNhNk&index=46&list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE">
+Hidden Costs of Transparency</a>.
+</p>
+
diff --git a/docs/html/topic/performance/rendering/profile-gpu.jd b/docs/html/topic/performance/rendering/profile-gpu.jd
new file mode 100644
index 0000000..11c38e4
--- /dev/null
+++ b/docs/html/topic/performance/rendering/profile-gpu.jd
@@ -0,0 +1,406 @@
+page.title=Analyzing Rendering with Profile GPU
+page.metaDescription=Use the Profile GPU tool to help you optimize your app's rendering performance.
+
+meta.tags="power"
+page.tags="power"
+
+@jd:body
+
+<div id="qv-wrapper">
+<div id="qv">
+
+<h2>In this document</h2>
+ <ol>
+ <li>
+ <a href="#visrep">Visual Representation</a></li>
+ </li>
+
+ <li>
+ <a href="#sam">Stages and Their Meanings</a>
+
+ <ul>
+ <li>
+ <a href="#sv">Input Handling</a>
+ </li>
+ <li>
+ <a href="#asd">Animation</a>
+ </li>
+ <li>
+ <a href="#asd">Measurement/Layout</a>
+ </li>
+ <li>
+ <a href="#asd">Drawing</a>
+ </li>
+ </li>
+ <li>
+ <a href="#asd">Sync/Upload</a>
+ </li>
+ <li>
+ <a href="#asd">Issuing Commands</a>
+ </li>
+ <li>
+ <a href="#asd">Processing/Swapping Buffer</a>
+ </li>
+ <li>
+ <a href="#asd">Miscellaneous</a>
+ </li>
+ </ul>
+ </li>
+ </ol>
+ </div>
+</div>
+
+<p>
+The <a href="/studio/profile/dev-options-rendering.html">
+Profile GPU Rendering</a> tool indicates the relative time that each stage of
+the rendering pipeline takes to render the previous frame. This knowledge
+can help you identify bottlenecks in the pipeline, so that you
+can know what to optimize to improve your app's rendering performance.
+</p>
+
+<p>
+This page briefly explains what happens during each pipeline stage, and
+discusses issues that can cause bottlenecks there. Before reading
+this page, you should be familiar with the information presented in the
+<a href="/studio/profile/dev-options-rendering.html">Profile GPU
+Rendering Walkthrough</a>. In addition, to understand how all of the
+stages fit together, it may be helpful to review
+<a href="https://www.youtube.com/watch?v=we6poP0kw6E&index=64&list=PLWz5rJ2EKKc9CBxr3BVjPTPoDPLdPIFCE">
+how the rendering pipeline works.</a>
+</p>
+
+<h2 id="#visrep">Visual Representation</h2>
+
+<p>
+The Profile GPU Rendering tool displays stages and their relative times in the
+form of a graph: a color-coded histogram. Figure 1 shows an example of
+such a display.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/bars.png">
+ <p class="img-caption">
+<strong>Figure 1.</strong> Profile GPU Rendering Graph
+ </p>
+
+</p>
+
+<p>
+Each segment of each vertical bar displayed in the Profile GPU Rendering
+graph represents a stage of the pipeline and is highlighted using a specific
+color in
+the bar graph. Figure 2 shows a key to the meaning of each displayed color.
+</p>
+
+ <img src="{@docRoot}topic/performance/images/s-profiler-legend.png">
+ <p class="img-caption">
+<strong>Figure 2.</strong> Profile GPU Rendering Graph Legend
+ </p>
+
+<p>
+Once you understand what each color signfiies,
+you can target specific aspects of your
+app to try to optimize its rendering performance.
+</p>
+
+<h2 id="sam">Stages and Their Meanings</a></h2>
+
+<p>
+This section explains what happens during each stage corresponding
+to a color in Figure 2, as well as bottleneck causes to look out for.
+</p>
+
+
+<h3 id="ih">Input Handling</h3>
+
+<p>
+The input handling stage of the pipeline measures how long the app
+spent handling input events. This metric indicates how long the app
+spent executing code called as a result of input event callbacks.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+High values in this area are typically a result of too much work, or
+too-complex work, occurring inside the input-handler event callbacks.
+Since these callbacks always occur on the main thread, solutions to this
+problem focus on optimizing the work directly, or offloading the work to a
+different thread.
+</p>
+
+<p>
+It’s also worth noting that {@link android.support.v7.widget.RecyclerView}
+scrolling can appear in this phase.
+{@link android.support.v7.widget.RecyclerView} scrolls immediately when it
+consumes the touch event. As a result,
+it can inflate or populate new item views. For this reason, it’s important to
+make this operation as fast as possible. Profiling tools like Traceview or
+Systrace can help you investigate further.
+</p>
+
+<h3 id="at">Animation</h3>
+
+<p>
+The Animations phase shows you just how long it took to evaluate all the
+animators that were running in that frame. The most common animators are
+{@link android.animation.ObjectAnimator},
+{@link android.view.ViewPropertyAnimator}, and
+<a href="/training/transitions/overview.html">Transitions</a>.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+High values in this area are typically a result of work that’s executing due
+to some property change of the animation. For example, a fling animation,
+which scrolls your {@link android.widget.ListView} or
+{@link android.support.v7.widget.RecyclerView}, causes large amounts of view
+inflation and population.
+</p>
+
+<h3 id="ml">Measurement/Layout</h3>
+
+<p>
+In order for Android to draw your view items on the screen, it executes
+two specific operations across layouts and views in your view hierarchy.
+</p>
+
+<p>
+First, the system measures the view items. Every view and layout has
+specific data that describes the size of the object on the screen. Some views
+can have a specific size; others have a size that adapts to the size
+of the parent layout container
+</p>
+
+<p>
+Second, the system lays out the view items. Once the system calculates
+the sizes of children views, the system can proceed with layout, sizing
+and positioning the views on the screen.
+</p>
+
+<p>
+The system performs measurement and layout not only for the views to be drawn,
+but also for the parent hierarchies of those views, all the way up to the root
+view.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+If your app spends a lot of time per frame in this area, it is
+usually either because of the sheer volume of views that need to be
+laid out, or problems such as
+<a href="/topic/performance/optimizing-view-hierarchies.html#double">
+double taxation</a> at the wrong spot in your
+hierarchy. In either of these cases, addressing performance involves
+<a href="/topic/performance/optimizing-view-hierarchies.html">improving
+the performance of your view hierarchies</a>.
+</p>
+
+<p>
+Code that you’ve added to
+{@link android.view.View#onLayout(boolean, int, int, int, int)} or
+{@link android.view.View#onMeasure(int, int)}
+can also cause performance
+issues. <a href="/studio/profile/traceview.html">Traceview</a> and
+<a href="/studio/profile/systrace.html">Systrace</a> can help you examine
+the callstacks to identify problems your code may have.
+</p>
+
+<h3 id="draw">Drawing</h3>
+
+<p>
+The draw stage translates a view’s rendering operations, such as drawing
+a background or drawing text, into a sequence of native drawing commands.
+The system captures these commands into a display list.
+</p>
+
+<p>
+The Draw bar records how much time it takes to complete capturing the commands
+into the display list, for all the views that needed to be updated on the screen
+this frame. The measured time applies to any code that you have added to the UI
+objects in your app. Examples of such code may be the
+{@link android.view.View#onDraw(android.graphics.Canvas) onDraw()},
+{@link android.view.View#dispatchDraw(android.graphics.Canvas) dispatchDraw()},
+and the various <code>draw ()methods</code> belonging to the subclasses of the
+{@link android.graphics.drawable.Drawable} class.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+In simplified terms, you can understand this metric as showing how long it took
+to run all of the calls to
+{@link android.view.View#onDraw(android.graphics.Canvas) onDraw()}
+for each invalidated view. This
+measurement includes any time spent dispatching draw commands to children and
+drawables that may be present. For this reason, when you see this bar spike, the
+cause could be that a bunch of views suddenly became invalidated. Invalidation
+makes it necessary to regenerate views' display lists. Alternatively, a
+lengthy time may be the result of a few custom views that have some extremely
+complex logic in their
+{@link android.view.View#onDraw(android.graphics.Canvas) onDraw()} methods.
+</p>
+
+<h3 id="su">Sync/Upload</h3>
+
+<p>
+The Sync & Upload metric represents the time it takes to transfer
+bitmap objects from CPU memory to GPU memory during the current frame.
+</p>
+
+<p>
+As different processors, the CPU and the GPU have different RAM areas
+dedicated to processing. When you draw a bitmap on Android, the system
+transfers the bitmap to GPU memory before the GPU can render it to the
+screen. Then, the GPU caches the bitmap so that the system doesn’t need to
+transfer the data again unless the texture gets evicted from the GPU texture
+cache.
+</p>
+
+<p class="note"><strong>Note:</strong> On Lollipop devices, this stage is
+purple.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+All resources for a frame need to reside in GPU memory before they can be
+used to draw a frame. This means that a high value for this metric could mean
+either a large number of small resource loads or a small number of very large
+resources. A common case is when an app displays a single bitmap that’s
+close to the size of the screen. Another case is when an app displays a
+large number of thumbnails.
+</p>
+
+<p>
+To shrink this bar, you can employ techniques such as:
+</p>
+
+<ul>
+ <li>
+Ensuring your bitmap resolutions are not much larger than the size at which they
+will be displayed. For example, your app should avoid displaying a 1024x1024
+image as a 48x48 image.
+ </li>
+
+ <li>
+Taking advantage of {@link android.graphics.Bitmap#prepareToDraw()}
+to asynchronously pre-upload a bitmap before the next sync phase.
+ </li>
+</ul>
+
+<h3 id="ic">Issuing Commands</h3>
+
+<p>
+The <em>Issue Commands</em> segment represents the time it takes to issue all
+of the commands necessary for drawing display lists to the screen.
+</p>
+
+<p>
+For the system to draw display lists to the screen, it sends the
+necessary commands to the GPU. Typically, it performs this action through the
+<a href="/guide/topics/graphics/opengl.html">OpenGL ES</a> API.
+</p>
+
+<p>
+This process takes some time, as the system performs final transformation
+and clipping for each command before sending the command to the GPU. Additional
+overhead then arises on the GPU side, which computes the final commands. These
+commands include final transformations, and additional clipping.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+The time spent in this stage is a direct measure of the complexity and
+quantity of display lists that the system renders in a given
+frame. For example, having many draw operations, especially in cases where
+there's a small inherent cost to each draw primitive, could inflate this time.
+For example:
+</p>
+
+<pre>
+for (int i = 0; i < 1000; i++)
+canvas.drawPoint()
+</pre>
+
+<p>
+is a lot more expensive to issue than:
+</p>
+
+<pre>
+canvas.drawPoints(mThousandPointArray);
+</pre>
+
+<p>
+There isn’t always a 1:1 correlation between issuing commands and
+actually drawing display lists. Unlike <em>Issue Commands</em>,
+which captures the time it takes to send drawing commands to the GPU,
+the <em>Draw</em> metric represents the time that it took to capture the issued
+commands into the display list.
+</p>
+
+<p>
+This difference arises because the display lists are cached by
+the system wherever possible. As a result, there are situations where a
+scroll, transform, or animation requires the system to re-send a display
+list, but not have to actually rebuild it—recapture the drawing
+commands—from scratch. As a result, you can see a high “Issue
+commands” bar without seeing a high <em>Draw commands</em> bar.
+</p>
+
+<h3 id="psb">Processing/Swapping Buffers</h3>
+
+<p>
+Once Android finishes submitting all its display list to the GPU,
+the system issues one final command to tell the graphics driver that it's
+done with the current frame. At this point, the driver can finally present
+the updated image to the screen.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+It’s important to understand that the GPU executes work in parallel with the
+CPU. The Android system issues draw commands to the GPU, and then moves on to
+the next task. The GPU reads those draw commands from a queue and processes
+them.
+</p>
+
+<p>
+In situations where the CPU issues commands faster than the GPU
+consumes them, the communications queue between the processors can become
+full. When this occurs, the CPU blocks, and waits until there is space in the
+queue to place the next command. This full-queue state arises often during the
+<em>Swap Buffers</em> stage, because at that point, a whole frame’s worth of
+commands have been submitted.
+</p>
+
+</p>
+The key to mitigating this problem is to reduce the complexity of work occurring
+on the GPU, in similar fashion to what you would do for the “Issue Commands”
+phase.
+</p>
+
+
+<h3 id="mt">Miscellaneous</h3>
+
+<p>
+In addition to the time it takes the rendering system to perform its work,
+there’s an additional set of work that occurs on the main thread and has
+nothing to do with rendering. Time that this work consumes is reported as
+<em>misc time</em>. Misc time generally represents work that might be occurring
+on the UI thread between two consecutive frames of rendering.
+</p>
+
+<h4>When this segment is large</h4>
+
+<p>
+If this value is high, it is likely that your app has callbacks, intents, or
+other work that should be happening on another thread. Tools such as
+<a href="/studio/profile/traceview.html">Method
+Tracing</a> or <a href="/studio/profile/systrace.html">Systrace</a> can provide
+visibility into the tasks that are running on
+the main thread. This information can help you target performance improvements.
+</p>
diff --git a/docs/html/training/_book.yaml b/docs/html/training/_book.yaml
index e9635be..fa50aa0 100644
--- a/docs/html/training/_book.yaml
+++ b/docs/html/training/_book.yaml
@@ -1242,15 +1242,9 @@
path: /training/scheduling/wakelock.html
- title: Scheduling Repeating Alarms
path: /training/scheduling/alarms.html
-
- title: Best Practices for Performance
path: /training/best-performance.html
section:
- - title: Managing Your App's Memory
- path: /training/articles/memory.html
- path_attributes:
- - name: description
- value: How to keep your app's memory footprint small in order to improve performance on a variety of mobile devices.
- title: Performance Tips
path: /training/articles/perf-tips.html
path_attributes:
@@ -1282,23 +1276,6 @@
- name: description
value: How to minimize the amount of power your app requires by adapting to current power conditions and performing power-hungry tasks at proper intervals.
section:
- - title: Reducing Network Battery Drain
- path: /training/performance/battery/network/index.html
- section:
- - title: Collecting Network Traffic Data
- path: /training/performance/battery/network/gather-data.html
- - title: Analyzing Network Traffic Data
- path: /training/performance/battery/network/analyze-data.html
- - title: Optimizing User-Initiated Network Use
- path: /training/performance/battery/network/action-user-traffic.html
- - title: Optimizing App-Initiated Network Use
- path: /training/performance/battery/network/action-app-traffic.html
- - title: Optimizing Server-Initiated Network Use
- path: /training/performance/battery/network/action-server-traffic.html
- - title: Optimizing General Network Use
- path: /training/performance/battery/network/action-any-traffic.html
- - title: Optimizing for Doze and App Standby
- path: /training/monitoring-device-state/doze-standby.html
- title: Monitoring the Battery Level and Charging State
path: /training/monitoring-device-state/battery-monitoring.html
path_attributes:
diff --git a/docs/html/training/articles/memory.jd b/docs/html/training/articles/memory.jd
deleted file mode 100644
index de7af58..0000000
--- a/docs/html/training/articles/memory.jd
+++ /dev/null
@@ -1,740 +0,0 @@
-page.title=Managing Your App's Memory
-page.tags=ram,low memory,OutOfMemoryError,onTrimMemory
-page.article=true
-@jd:body
-
-
-<div id="tb-wrapper">
-<div id="tb">
-
-<h2>In this document</h2>
-<ol class="nolist">
- <li><a href="#Android">How Android Manages Memory</a>
- <ol>
- <li><a href="#SharingRAM">Sharing Memory</a></li>
- <li><a href="#AllocatingRAM">Allocating and Reclaiming App Memory</a></li>
- <li><a href="#RestrictingMemory">Restricting App Memory</a></li>
- <li><a href="#SwitchingApps">Switching Apps</a></li>
- </ol>
- </li>
- <li><a href="#YourApp">How Your App Should Manage Memory</a>
- <ol>
- <li><a href="#Services">Use services sparingly</a></li>
- <li><a href="#ReleaseMemoryAsUiGone">Release memory when your user interface becomes hidden</a></li>
- <li><a href="#ReleaseMemoryAsTight">Release memory as memory becomes tight</a></li>
- <li><a href="#CheckHowMuchMemory">Check how much memory you should use</a></li>
- <li><a href="#Bitmaps">Avoid wasting memory with bitmaps</a></li>
- <li><a href="#DataContainers">Use optimized data containers</a></li>
- <li><a href="#Overhead">Be aware of memory overhead</a></li>
- <li><a href="#Abstractions">Be careful with code abstractions</a></li>
- <li><a href="#NanoProto">Use nano protobufs for serialized data</a></li>
- <li><a href="#DependencyInjection">Avoid dependency injection frameworks</a></li>
- <li><a href="#ExternalLibs">Be careful about using external libraries</a></li>
- <li><a href="#OverallPerf">Optimize overall performance</a></li>
- <li><a href="#Proguard">Use ProGuard to strip out any unneeded code</a></li>
- <li><a href="#Zipalign">Use zipalign on your final APK</a></li>
- <li><a href="#AnalyzeRam">Analyze your RAM usage</a></li>
- <li><a href="#MultipleProcesses">Use multiple processes</a></li>
- </ol>
- </li>
-</ol>
-<h2>See Also</h2>
-<ul>
- <li><a href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a>
- </li>
-</ul>
-
-</div>
-</div>
-
-
-<p>Random-access memory (RAM) is a valuable resource in any software development environment, but
-it's even more valuable on a mobile operating system where physical memory is often constrained.
-Although Android's Dalvik virtual machine performs routine garbage collection, this doesn't allow
-you to ignore when and where your app allocates and releases memory.</p>
-
-<p>In order for the garbage collector to reclaim memory from your app, you need to avoid
-introducing memory leaks (usually caused by holding onto object references in global members) and
-release any {@link java.lang.ref.Reference} objects at the appropriate time (as defined by
-lifecycle callbacks discussed further below). For most apps, the Dalvik garbage collector takes
-care of the rest: the system reclaims your memory allocations when the corresponding objects leave
-the scope of your app's active threads.</p>
-
-<p>This document explains how Android manages app processes and memory allocation, and how you can
-proactively reduce memory usage while developing for Android. For more information about general
-practices to clean up your resources when programming in Java, refer to other books or online
-documentation about managing resource references. If you’re looking for information about how to
-analyze your app’s memory once you’ve already built it, read <a
-href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a>.</p>
-
-
-
-
-<h2 id="Android">How Android Manages Memory</h2>
-
-<p>Android does not offer swap space for memory, but it does use <a href=
-"http://en.wikipedia.org/wiki/Paging" class="external-link">paging</a> and <a href=
-"http://en.wikipedia.org/wiki/Memory-mapped_files" class="external-link">memory-mapping</a>
-(mmapping) to manage memory. This means that any memory you modify—whether by allocating
-new objects or touching mmapped pages—remains resident in RAM and cannot be paged out.
-So the only way to completely release memory from your app is to release object references you may
-be holding, making the memory available to the garbage collector. That is with one exception:
-any files mmapped in without modification, such as code, can be paged out of RAM if the system
-wants to use that memory elsewhere.</p>
-
-
-<h3 id="SharingRAM">Sharing Memory</h3>
-
-<p>In order to fit everything it needs in RAM, Android tries to share RAM pages across processes. It
-can do so in the following ways:</p>
-<ul>
-<li>Each app process is forked from an existing process called Zygote.
-The Zygote process starts when the system boots and loads common framework code and resources
-(such as activity themes). To start a new app process, the system forks the Zygote process then
-loads and runs the app's code in the new process. This allows most of the RAM pages allocated for
-framework code and resources to be shared across all app processes.</li>
-
-<li>Most static data is mmapped into a process. This not only allows that same data to be shared
-between processes but also allows it to be paged out when needed. Example static data include:
-Dalvik code (by placing it in a pre-linked {@code .odex} file for direct mmapping), app resources
-(by designing the resource table to be a structure that can be mmapped and by aligning the zip
-entries of the APK), and traditional project elements like native code in {@code .so} files.</li>
-
-<li>In many places, Android shares the same dynamic RAM across processes using explicitly allocated
-shared memory regions (either with ashmem or gralloc). For example, window surfaces use shared
-memory between the app and screen compositor, and cursor buffers use shared memory between the
-content provider and client.</li>
-</ul>
-
-<p>Due to the extensive use of shared memory, determining how much memory your app is using requires
-care. Techniques to properly determine your app's memory use are discussed in <a
-href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a>.</p>
-
-
-<h3 id="AllocatingRAM">Allocating and Reclaiming App Memory</h3>
-
-<p>Here are some facts about how Android allocates then reclaims memory from your app:</p>
-
-<ul>
-<li>The Dalvik heap for each process is constrained to a single virtual memory range. This defines
-the logical heap size, which can grow as it needs to (but only up to a limit that the system defines
-for each app).</li>
-
-<li>The logical size of the heap is not the same as the amount of physical memory used by the heap.
-When inspecting your app's heap, Android computes a value called the Proportional Set Size (PSS),
-which accounts for both dirty and clean pages that are shared with other processes—but only in an
-amount that's proportional to how many apps share that RAM. This (PSS) total is what the system
-considers to be your physical memory footprint. For more information about PSS, see the <a
-href="{@docRoot}tools/debugging/debugging-memory.html#ViewingAllocations">Investigating Your
-RAM Usage</a> guide.</li>
-
-<li>The Dalvik heap does not compact the logical size of the heap, meaning that Android does not
-defragment the heap to close up space. Android can only shrink the logical heap size when there
-is unused space at the end of the heap. But this doesn't mean the physical memory used by the heap
-can't shrink. After garbage collection, Dalvik walks the heap and finds unused pages, then returns
-those pages to the kernel using madvise. So, paired allocations and deallocations of large
-chunks should result in reclaiming all (or nearly all) the physical memory used. However,
-reclaiming memory from small allocations can be much less efficient because the page used
-for a small allocation may still be shared with something else that has not yet been freed.</li>
-</ul>
-
-
-<h3 id="RestrictingMemory">Restricting App Memory</h3>
-
-<p>To maintain a functional multi-tasking environment, Android sets a hard limit on the heap size
-for each app. The exact heap size limit varies between devices based on how much RAM the device
-has available overall. If your app has reached the heap capacity and tries to allocate more
-memory, it will receive an {@link java.lang.OutOfMemoryError}.</p>
-
-<p>In some cases, you might want to query the system to determine exactly how much heap space you
-have available on the current device—for example, to determine how much data is safe to keep in a
-cache. You can query the system for this figure by calling {@link
-android.app.ActivityManager#getMemoryClass()}. This returns an integer indicating the number of
-megabytes available for your app's heap. This is discussed further below, under
-<a href="#CheckHowMuchMemory">Check how much memory you should use</a>.</p>
-
-
-<h3 id="SwitchingApps">Switching Apps</h3>
-
-<p>Instead of using swap space when the user switches between apps, Android keeps processes that
-are not hosting a foreground ("user visible") app component in a least-recently used (LRU) cache.
-For example, when the user first launches an app, a process is created for it, but when the user
-leaves the app, that process does <em>not</em> quit. The system keeps the process cached, so if
-the user later returns to the app, the process is reused for faster app switching.</p>
-
-<p>If your app has a cached process and it retains memory that it currently does not need,
-then your app—even while the user is not using it—is constraining the system's
-overall performance. So, as the system runs low on memory, it may kill processes in the LRU cache
-beginning with the process least recently used, but also giving some consideration toward
-which processes are most memory intensive. To keep your process cached as long as possible, follow
-the advice in the following sections about when to release your references.</p>
-
-<p>More information about how processes are cached while not running in the foreground and how
-Android decides which ones
-can be killed is available in the <a href="{@docRoot}guide/components/processes-and-threads.html"
->Processes and Threads</a> guide.</p>
-
-
-
-
-<h2 id="YourApp">How Your App Should Manage Memory</h2>
-
-<p>You should consider RAM constraints throughout all phases of development, including during app
-design (before you begin development). There are many
-ways you can design and write code that lead to more efficient results, through aggregation of the
-same techniques applied over and over.</p>
-
-<p>You should apply the following techniques while designing and implementing your app to make it
-more memory efficient.</p>
-
-
-<h3 id="Services">Use services sparingly</h3>
-
-<p>If your app needs a <a href="{@docRoot}guide/components/services.html">service</a>
-to perform work in the background, do not keep it running unless
-it's actively performing a job. Also be careful to never leak your service by failing to stop it
-when its work is done.</p>
-
-<p>When you start a service, the system prefers to always keep the process for that service
-running. This makes the process very expensive because the RAM used by the service can’t be used by
-anything else or paged out. This reduces the number of cached processes that the system can keep in
-the LRU cache, making app switching less efficient. It can even lead to thrashing in the system
-when memory is tight and the system can’t maintain enough processes to host all the services
-currently running.</p>
-
-<p>The best way to limit the lifespan of your service is to use an {@link
-android.app.IntentService}, which finishes
-itself as soon as it's done handling the intent that started it. For more information, read
-<a href="{@docRoot}training/run-background-service/index.html">Running in a Background Service</a>
-.</p>
-
-<p>Leaving a service running when it’s not needed is <strong>one of the worst memory-management
-mistakes</strong> an Android app can make. So don’t be greedy by keeping a service for your app
-running. Not only will it increase the risk of your app performing poorly due to RAM constraints,
-but users will discover such misbehaving apps and uninstall them.</p>
-
-
-<h3 id="ReleaseMemoryAsUiGone">Release memory when your user interface becomes hidden</h3>
-
-<p>When the user navigates to a different app and your UI is no longer visible, you should
-release any resources that are used by only your UI. Releasing UI resources at this time can
-significantly increase the system's capacity for cached processes, which has a direct impact on the
-quality of the user experience.</p>
-
-<p>To be notified when the user exits your UI, implement the {@link
-android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()} callback in your {@link
-android.app.Activity} classes. You should use this
-method to listen for the {@link android.content.ComponentCallbacks2#TRIM_MEMORY_UI_HIDDEN} level,
-which indicates your UI is now hidden from view and you should free resources that only your UI
-uses.</p>
-
-
-<p>Notice that your app receives the {@link android.content.ComponentCallbacks2#onTrimMemory
-onTrimMemory()} callback with {@link android.content.ComponentCallbacks2#TRIM_MEMORY_UI_HIDDEN}
-only when <em>all the UI components</em> of your app process become hidden from the user.
-This is distinct
-from the {@link android.app.Activity#onStop onStop()} callback, which is called when an {@link
-android.app.Activity} instance becomes hidden, which occurs even when the user moves to
-another activity in your app. So although you should implement {@link android.app.Activity#onStop
-onStop()} to release activity resources such as a network connection or to unregister broadcast
-receivers, you usually should not release your UI resources until you receive {@link
-android.content.ComponentCallbacks2#onTrimMemory onTrimMemory(TRIM_MEMORY_UI_HIDDEN)}. This ensures
-that if the user navigates <em>back</em> from another activity in your app, your UI resources are
-still available to resume the activity quickly.</p>
-
-
-
-<h3 id="ReleaseMemoryAsTight">Release memory as memory becomes tight</h3>
-
-<p>During any stage of your app's lifecycle, the {@link
-android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()} callback also tells you when
-the overall device memory is getting low. You should respond by further releasing resources based
-on the following memory levels delivered by {@link android.content.ComponentCallbacks2#onTrimMemory
-onTrimMemory()}:</p>
-
-<ul>
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_RUNNING_MODERATE}
-<p>Your app is running and not considered killable, but the device is running low on memory and the
-system is actively killing processes in the LRU cache.</p>
-</li>
-
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_RUNNING_LOW}
-<p>Your app is running and not considered killable, but the device is running much lower on
-memory so you should release unused resources to improve system performance (which directly
-impacts your app's performance).</p>
-</li>
-
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_RUNNING_CRITICAL}
-<p>Your app is still running, but the system has already killed most of the processes in the
-LRU cache, so you should release all non-critical resources now. If the system cannot reclaim
-sufficient amounts of RAM, it will clear all of the LRU cache and begin killing processes that
-the system prefers to keep alive, such as those hosting a running service.</p>
-</li>
-</ul>
-
-<p>Also, when your app process is currently cached, you may receive one of the following
-levels from {@link android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()}:</p>
-<ul>
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_BACKGROUND}
-<p>The system is running low on memory and your process is near the beginning of the LRU list.
-Although your app process is not at a high risk of being killed, the system may already be killing
-processes in the LRU cache. You should release resources that are easy to recover so your process
-will remain in the list and resume quickly when the user returns to your app.</p>
-</li>
-
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_MODERATE}
-<p>The system is running low on memory and your process is near the middle of the LRU list. If the
-system becomes further constrained for memory, there's a chance your process will be killed.</p>
-</li>
-
-<li>{@link android.content.ComponentCallbacks2#TRIM_MEMORY_COMPLETE}
-<p>The system is running low on memory and your process is one of the first to be killed if the
-system does not recover memory now. You should release everything that's not critical to
-resuming your app state.</p>
-
-</li>
-</ul>
-
-<p>Because the {@link android.content.ComponentCallbacks2#onTrimMemory onTrimMemory()} callback was
-added in API level 14, you can use the {@link android.content.ComponentCallbacks#onLowMemory()}
-callback as a fallback for older versions, which is roughly equivalent to the {@link
-android.content.ComponentCallbacks2#TRIM_MEMORY_COMPLETE} event.</p>
-
-<p class="note"><strong>Note:</strong> When the system begins killing processes in the LRU cache,
-although it primarily works bottom-up, it does give some consideration to which processes are
-consuming more memory and will thus provide the system more memory gain if killed.
-So the less memory you consume while in the LRU list overall, the better your chances are
-to remain in the list and be able to quickly resume.</p>
-
-
-
-<h3 id="CheckHowMuchMemory">Check how much memory you should use</h3>
-
-<p>As mentioned earlier, each Android-powered device has a different amount of RAM available to the
-system and thus provides a different heap limit for each app. You can call {@link
-android.app.ActivityManager#getMemoryClass()} to get an estimate of your app's available heap in
-megabytes. If your app tries to allocate more memory than is available here, it will receive an
-{@link java.lang.OutOfMemoryError}.</p>
-
-<p>In very special situations, you can request a larger heap size by setting the <a
-href="{@docRoot}guide/topics/manifest/application-element.html#largeHeap">{@code largeHeap}</a>
-attribute to "true" in the manifest <a
-href="{@docRoot}guide/topics/manifest/application-element.html">{@code <application>}</a>
-tag. If you do so, you can call {@link
-android.app.ActivityManager#getLargeMemoryClass()} to get an estimate of the large heap size.</p>
-
-<p>However, the ability to request a large heap is intended only for a small set of apps that can
-justify the need to consume more RAM (such as a large photo editing app). <strong>Never request a
-large heap simply because you've run out of memory</strong> and you need a quick fix—you
-should use it only when you know exactly where all your memory is being allocated and why it must
-be retained. Yet, even when you're confident your app can justify the large heap, you should avoid
-requesting it to whatever extent possible. Using the extra memory will increasingly be to the
-detriment of the overall user experience because garbage collection will take longer and system
-performance may be slower when task switching or performing other common operations.</p>
-
-<p>Additionally, the large heap size is not the same on all devices and, when running on
-devices that have limited RAM, the large heap size may be exactly the same as the regular heap
-size. So even if you do request the large heap size, you should call {@link
-android.app.ActivityManager#getMemoryClass()} to check the regular heap size and strive to always
-stay below that limit.</p>
-
-
-<h3 id="Bitmaps">Avoid wasting memory with bitmaps</h3>
-
-<p>When you load a bitmap, keep it in RAM only at the resolution you need for the current device's
-screen, scaling it down if the original bitmap is a higher resolution. Keep in mind that an
-increase in bitmap resolution results in a corresponding (increase<sup>2</sup>) in memory needed,
-because both the X and Y dimensions increase.</p>
-
-<p class="note"><strong>Note:</strong> On Android 2.3.x (API level 10) and below, bitmap objects
-always appear as the same size in your app heap regardless of the image resolution (the actual
-pixel data is stored separately in native memory). This makes it more difficult to debug the bitmap
-memory allocation because most heap analysis tools do not see the native allocation. However,
-beginning in Android 3.0 (API level 11), the bitmap pixel data is allocated in your app's Dalvik
-heap, improving garbage collection and debuggability. So if your app uses bitmaps and you're having
-trouble discovering why your app is using some memory on an older device, switch to a device
-running Android 3.0 or higher to debug it.</p>
-
-<p>For more tips about working with bitmaps, read <a
-href="{@docRoot}training/displaying-bitmaps/manage-memory.html">Managing Bitmap Memory</a>.</p>
-
-
-<h3 id="DataContainers">Use optimized data containers</h3>
-
-<p>Take advantage of optimized containers in the Android framework, such as {@link
-android.util.SparseArray}, {@link android.util.SparseBooleanArray}, and {@link
-android.support.v4.util.LongSparseArray}. The generic {@link java.util.HashMap}
-implementation can be quite memory
-inefficient because it needs a separate entry object for every mapping. Additionally, the {@link
-android.util.SparseArray} classes are more efficient because they avoid the system's need
-to <acronym title=
-"Automatic conversion from primitive types to object classes (such as int to Integer)"
->autobox</acronym>
-the key and sometimes value (which creates yet another object or two per entry). And don't be
-afraid of dropping down to raw arrays when that makes sense.</p>
-
-
-
-<h3 id="Overhead">Be aware of memory overhead</h3>
-
-<p>Be knowledgeable about the cost and overhead of the language and libraries you are using, and
-keep this information in mind when you design your app, from start to finish. Often, things on the
-surface that look innocuous may in fact have a large amount of overhead. Examples include:</p>
-<ul>
-<li>Enums often require more than twice as much memory as static constants. You should strictly
-avoid using enums on Android.</li>
-
-<li>Every class in Java (including anonymous inner classes) uses about 500 bytes of code.</li>
-
-<li>Every class instance has 12-16 bytes of RAM overhead.</li>
-
-<li>Putting a single entry into a {@link java.util.HashMap} requires the allocation of an
-additional entry object that takes 32 bytes (see the previous section about <a
-href="#DataContainers">optimized data containers</a>).</li>
-</ul>
-
-<p>A few bytes here and there quickly add up—app designs that are class- or object-heavy will suffer
-from this overhead. That can leave you in the difficult position of looking at a heap analysis and
-realizing your problem is a lot of small objects using up your RAM.</p>
-
-
-<h3 id="Abstractions">Be careful with code abstractions</h3>
-
-<p>Often, developers use abstractions simply as a "good programming practice," because abstractions
-can improve code flexibility and maintenance. However, abstractions come at a significant cost:
-generally they require a fair amount more code that needs to be executed, requiring more time and
-more RAM for that code to be mapped into memory. So if your abstractions aren't supplying a
-significant benefit, you should avoid them.</p>
-
-
-<h3 id="NanoProto">Use nano protobufs for serialized data</h3>
-
-<p><a href="https://developers.google.com/protocol-buffers/docs/overview">Protocol
-buffers</a> are a language-neutral, platform-neutral, extensible mechanism designed by Google for
-serializing structured data—think XML, but smaller, faster, and simpler. If you decide to use
-protobufs for your data, you should always use nano protobufs in your client-side code. Regular
-protobufs generate extremely verbose code, which will cause many kinds of problems in your app:
-increased RAM use, significant APK size increase, slower execution, and quickly hitting the DEX
-symbol limit.</p>
-
-<p>For more information, see the "Nano version" section in the <a
-href="https://android.googlesource.com/platform/external/protobuf/+/master/java/README.txt"
-class="external-link">protobuf readme</a>.</p>
-
-
-
-<h3 id="DependencyInjection">Avoid dependency injection frameworks</h3>
-
-<p>Using a dependency injection framework such as <a
-href="https://code.google.com/p/google-guice/" class="external-link">Guice</a> or
-<a href="https://github.com/roboguice/roboguice" class="external-link">RoboGuice</a> may be
-attractive because they can simplify the code you write and provide an adaptive environment
-that's useful for testing and other configuration changes. However, these frameworks tend to perform
-a lot of process initialization by scanning your code for annotations, which can require significant
-amounts of your code to be mapped into RAM even though you don't need it. These mapped pages are
-allocated into clean memory so Android can drop them, but that won't happen until the pages have
-been left in memory for a long period of time.</p>
-
-
-<h3 id="ExternalLibs">Be careful about using external libraries</h3>
-
-<p>External library code is often not written for mobile environments and can be inefficient when used
-for work on a mobile client. At the very least, when you decide to use an external library, you
-should assume you are taking on a significant porting and maintenance burden to optimize the
-library for mobile. Plan for that work up-front and analyze the library in terms of code size and
-RAM footprint before deciding to use it at all.</p>
-
-<p>Even libraries supposedly designed for use on Android are potentially dangerous because each
-library may do things differently. For example, one library may use nano protobufs while another
-uses micro protobufs. Now you have two different protobuf implementations in your app. This can and
-will also happen with different implementations of logging, analytics, image loading frameworks,
-caching, and all kinds of other things you don't expect. <a
-href="{@docRoot}tools/help/proguard.html">ProGuard</a> won't save you here because these
-will all be lower-level dependencies that are required by the features for which you want the
-library. This becomes especially problematic when you use an {@link android.app.Activity}
-subclass from a library (which
-will tend to have wide swaths of dependencies), when libraries use reflection (which is common and
-means you need to spend a lot of time manually tweaking ProGuard to get it to work), and so on.</p>
-
-<p>Also be careful not to fall into the trap of using a shared library for one or two features out of
-dozens of other things it does; you don't want to pull in a large amount of code and overhead that
-you don't even use. At the end of the day, if there isn't an existing implementation that is a
-strong match for what you need to do, it may be best if you create your own implementation.</p>
-
-
-<h3 id="OverallPerf">Optimize overall performance</h3>
-
-<p>A variety of information about optimizing your app's overall performance is available
-in other documents listed in <a href="{@docRoot}training/best-performance.html">Best Practices
-for Performance</a>. Many of these documents include optimizations tips for CPU performance, but
-many of these tips also help optimize your app's memory use, such as by reducing the number of
-layout objects required by your UI.</p>
-
-<p>You should also read about <a href="{@docRoot}tools/debugging/debugging-ui.html">optimizing
-your UI</a> with the layout debugging tools and take advantage of
-the optimization suggestions provided by the <a
-href="{@docRoot}tools/debugging/improving-w-lint.html">lint tool</a>.</p>
-
-
-<h3 id="Proguard">Use ProGuard to strip out any unneeded code</h3>
-
-<p>The <a href="{@docRoot}tools/help/proguard.html">ProGuard</a> tool shrinks,
-optimizes, and obfuscates your code by removing unused code and renaming classes, fields, and
-methods with semantically obscure names. Using ProGuard can make your code more compact, requiring
-fewer RAM pages to be mapped.</p>
-
-
-<h3 id="Zipalign">Use zipalign on your final APK</h3>
-
-<p>If you do any post-processing of an APK generated by a build system (including signing it
-with your final production certificate), then you must run <a
-href="{@docRoot}tools/help/zipalign.html">zipalign</a> on it to have it re-aligned.
-Failing to do so can cause your app to require significantly more RAM, because things like
-resources can no longer be mmapped from the APK.</p>
-
-<p class="note"><strong>Note:</strong> Google Play Store does not accept APK files that
-are not zipaligned.</p>
-
-
-<h3 id="AnalyzeRam">Analyze your RAM usage</h3>
-
-<p>Once you achieve a relatively stable build, begin analyzing how much RAM your app is using
-throughout all stages of its lifecycle. For information about how to analyze your app, read <a
-href="{@docRoot}tools/debugging/debugging-memory.html">Investigating Your RAM Usage</a>.</p>
-
-
-
-
-<h3 id="MultipleProcesses">Use multiple processes</h3>
-
-<p>If it's appropriate for your app, an advanced technique that may help you manage your app's
-memory is dividing components of your app into multiple processes. This technique must always be
-used carefully and <strong>most apps should not run multiple processes</strong>, as it can easily
-increase—rather than decrease—your RAM footprint if done incorrectly. It is primarily
-useful to apps that may run significant work in the background as well as the foreground and can
-manage those operations separately.</p>
-
-
-<p>An example of when multiple processes may be appropriate is when building a music player that
-plays music from a service for long period of time. If
-the entire app runs in one process, then many of the allocations performed for its activity UI must
-be kept around as long as it is playing music, even if the user is currently in another app and the
-service is controlling the playback. An app like this may be split into two process: one for its
-UI, and the other for the work that continues running in the background service.</p>
-
-<p>You can specify a separate process for each app component by declaring the <a href=
-"{@docRoot}guide/topics/manifest/service-element.html#proc">{@code android:process}</a> attribute
-for each component in the manifest file. For example, you can specify that your service should run
-in a process separate from your app's main process by declaring a new process named "background"
-(but you can name the process anything you like):</p>
-
-<pre>
-<service android:name=".PlaybackService"
- android:process=":background" />
-</pre>
-
-<p>Your process name should begin with a colon (':') to ensure that the process remains private to
-your app.</p>
-
-<p>Before you decide to create a new process, you need to understand the memory implications.
-To illustrate the consequences of each process, consider that an empty process doing basically
-nothing has an extra memory footprint of about 1.4MB, as shown by the memory information
-dump below.</p>
-
-<pre class="no-pretty-print">
-adb shell dumpsys meminfo com.example.android.apis:empty
-
-** MEMINFO in pid 10172 [com.example.android.apis:empty] **
- Pss Pss Shared Private Shared Private Heap Heap Heap
- Total Clean Dirty Dirty Clean Clean Size Alloc Free
- ------ ------ ------ ------ ------ ------ ------ ------ ------
- Native Heap 0 0 0 0 0 0 1864 1800 63
- Dalvik Heap 764 0 5228 316 0 0 5584 5499 85
- Dalvik Other 619 0 3784 448 0 0
- Stack 28 0 8 28 0 0
- Other dev 4 0 12 0 0 4
- .so mmap 287 0 2840 212 972 0
- .apk mmap 54 0 0 0 136 0
- .dex mmap 250 148 0 0 3704 148
- Other mmap 8 0 8 8 20 0
- Unknown 403 0 600 380 0 0
- TOTAL 2417 148 12480 1392 4832 152 7448 7299 148
-</pre>
-
-<p class="note"><strong>Note:</strong> More information about how to read this output is provided
-in <a href="{@docRoot}tools/debugging/debugging-memory.html#ViewingAllocations">Investigating
-Your RAM Usage</a>. The key data here is the <em>Private Dirty</em> and <em>Private
-Clean</em> memory, which shows that this process is using almost 1.4MB of non-pageable RAM
-(distributed across the Dalvik heap, native allocations, book-keeping, and library-loading),
-and another 150K of RAM for code that has been mapped in to execute.</p>
-
-<p>This memory footprint for an empty process is fairly significant and it can quickly
-grow as you start doing work in that process. For
-example, here is the memory use of a process that is created only to show an activity with some
-text in it:</p>
-
-<pre class="no-pretty-print">
-** MEMINFO in pid 10226 [com.example.android.helloactivity] **
- Pss Pss Shared Private Shared Private Heap Heap Heap
- Total Clean Dirty Dirty Clean Clean Size Alloc Free
- ------ ------ ------ ------ ------ ------ ------ ------ ------
- Native Heap 0 0 0 0 0 0 3000 2951 48
- Dalvik Heap 1074 0 4928 776 0 0 5744 5658 86
- Dalvik Other 802 0 3612 664 0 0
- Stack 28 0 8 28 0 0
- Ashmem 6 0 16 0 0 0
- Other dev 108 0 24 104 0 4
- .so mmap 2166 0 2824 1828 3756 0
- .apk mmap 48 0 0 0 632 0
- .ttf mmap 3 0 0 0 24 0
- .dex mmap 292 4 0 0 5672 4
- Other mmap 10 0 8 8 68 0
- Unknown 632 0 412 624 0 0
- TOTAL 5169 4 11832 4032 10152 8 8744 8609 134
-</pre>
-
-<p>The process has now almost tripled in size, to 4MB, simply by showing some text in the UI. This
-leads to an important conclusion: If you are going to split your app into multiple processes, only
-one process should be responsible for UI. Other processes should avoid any UI, as this will quickly
-increase the RAM required by the process (especially once you start loading bitmap assets and other
-resources). It may then be hard or impossible to reduce the memory usage once the UI is drawn.</p>
-
-<p>Additionally, when running more than one process, it's more important than ever that you keep your
-code as lean as possible, because any unnecessary RAM overhead for common implementations are now
-replicated in each process. For example, if you are using enums (though <a
-href="#Overhead">you should not use enums</a>), all of
-the RAM needed to create and initialize those constants is duplicated in each process, and any
-abstractions you have with adapters and temporaries or other overhead will likewise be replicated.</p>
-
-<p>Another concern with multiple processes is the dependencies that exist between them. For example,
-if your app has a content provider that you have running in the default process which also hosts
-your UI, then code in a background process that uses that content provider will also require that
-your UI process remain in RAM. If your goal is to have a background process that can run
-independently of a heavy-weight UI process, it can't have dependencies on content providers or
-services that execute in the UI process.</p>
-
-
-
-
-
-
-
-
-
-
-<!-- THE FOLLOWING IS OVERWHELMING AND NOT NECESSARY FOR MOST APPS, LEAVING OUT FOR NOW
-
-
-<p>You can examine the dependencies between your processes with the command:</p>
-
-<pre class="no-pretty-print">
-adb shell dumpsys activity
-</pre>
-
-<p>This dumps various information about the Activity Manager's state, ending with a list of all
-processes in their memory management order, including the reason each process is at its given
-level. For example, below is a dump with the Music app in the foreground.</p>
-
-<pre class="no-pretty-print">
-ACTIVITY MANAGER RUNNING PROCESSES (dumpsys activity processes)
- Process LRU list (sorted by oom_adj):
- PERS # 4: adj=sys /F trm= 0 20674:system/1000 (fixed)
- PERS #39: adj=pers /F trm= 0 20964:com.android.nfc/1027 (fixed)
- PERS # 2: adj=pers /F trm= 0 20959:com.android.phone/1001 (fixed)
- PERS # 1: adj=pers /F trm= 0 20779:com.android.systemui/u0a10057 (fixed)
- Proc #11: adj=fore /FA trm= 0 8663:com.google.android.music:ui/u0a10043 (top-activity)
- Proc #10: adj=fore /F trm= 0 30881:com.google.android.music:main/u0a10043 (provider)
- com.google.android.music/.store.MusicContentProvider<=Proc{8663:com.google.android.music:ui/u0a10043}
- Proc # 6: adj=fore /F trm= 0 21014:com.google.process.gapps/u0a10023 (provider)
- com.google.android.gsf/.settings.GoogleSettingsProvider<=Proc{20935:com.google.process.location/u0a10023}
- Proc #38: adj=vis /F trm= 0 21028:com.android.nfc:handover/1027 (service)
- com.android.nfc/.handover.HandoverService<=Proc{20964:com.android.nfc/1027}
- Proc # 7: adj=vis /B trm= 0 20935:com.google.process.location/u0a10023 (service)
- com.google.android.location/.GeocodeService<=Proc{20674:system/1000}
- Proc # 3: adj=vis /F trm= 0 21225:com.android.bluetooth/1002 (service)
- com.android.bluetooth/.hfp.HeadsetService<=Proc{20674:system/1000}
- Proc # 0: adj=vis /F trm= 0 20908:com.google.android.inputmethod.latin/u0a10035 (service)
- com.google.android.inputmethod.latin/com.android.inputmethod.latin.LatinIME<=Proc{20674:system/1000}
- Proc #34: adj=svc /B trm= 0 16765:com.google.android.apps.currents/u0a10012 (started-services)
- Proc #14: adj=svc /B trm= 0 21148:com.google.android.gms/u0a10023 (started-services)
- Proc #12: adj=home /B trm= 0 20989:com.android.launcher/u0a10036 (home)
- Proc #37: adj=svcb /B trm= 0 15194:com.google.android.apps.googlevoice/u0a10089 (started-services)
- Proc #17: adj=svcb /B trm= 0 24537:android.process.media/u0a10016 (started-services)
- Proc #35: adj=bak /B trm= 0 16087:com.android.defcontainer/u0a10013 (service)
- com.android.defcontainer/.DefaultContainerService<=Proc{16050:com.android.settings/1000}
- Proc #16: adj=bak /B trm= 0 7334:com.google.android.gm/u0a10022 (bg-act)
- Proc #15: adj=bak /B trm= 0 22499:com.google.android.googlequicksearchbox/u0a10060 (bg-act)
- Proc # 9: adj=bak /B trm= 0 20856:com.google.android.gsf.login/u0a10023 (bg-empty)
- Proc #26: adj=bak+1/B trm= 0 9923:com.android.mms/u0a10042 (bg-act)
- Proc #23: adj=bak+1/B trm= 0 16721:com.android.chrome/u0a10010 (bg-act)
- Proc #22: adj=bak+1/B trm= 0 17596:com.android.chrome:sandboxed_process0/u0a10010i33 (service)
- com.android.chrome/org.chromium.content.app.SandboxedProcessService0<=Proc{16721:com.android.chrome/u0a10010}
- Proc #19: adj=bak+1/B trm= 0 17442:com.google.android.youtube/u0a10067 (bg-services)
- Proc #18: adj=bak+2/B trm= 0 16740:com.google.android.apps.plus/u0a10052 (bg-empty)
- Proc #13: adj=bak+2/B trm= 0 7707:com.android.musicfx/u0a10044 (bg-empty)
- Proc #36: adj=bak+3/B trm= 0 16050:com.android.settings/1000 (bg-act)
- Proc #33: adj=bak+3/B trm= 0 16863:com.android.dialer/u0a10015 (bg-act)
-</pre>
-
-
-<p class="note"><strong>Note:</strong> The exact details of what is shown here will vary across
-platform versions as process management policies are tweaked and improved.</p>
-
-
-<p>Details on the highlighted sections are:</p>
-
-<ol>
-<li>Foreground app: This is the current app running in the foreground -- it is in the "fore" memory
-class because it is the top activity on the activity stack.</li>
-
-<li>Persistent processes: These are processes that are part of the core system that must always be
-running.</li>
-
-<li>Dependent process: This shows how the Music app is using two processes. Its UI process has a
-dependency on the "main" process (through a content provider). So while the UI process is in use,
-the main process must also be kept around. This means the app's memory footprint is actually the
-sum of both processes. You will have this kind of connection on a content provider any time you
-have active calls into it or have unclosed cursors or file streams that came from it.</li>
-
-<li>Visible processes: These are processes that count in some way as "visible" to the user. This
-generally means that it is either something the user can literally see (such as a process hosting a
-paused but visible activity that is behind a non-full-screen dialog) or is something the user might
-notice if the process disappeared (such as a foreground service playing music). You should be
-certain that any process you have running at the "visible" level is indeed critical to the user,
-because they are very expensive to the overall RAM load.</li>
-
-<li>Service processes: These are processes running long-term jobs in a service. This level of the
-list is the start of less-critical processes, which the system has some freedom to kill if RAM is
-needed elsewhere. These services are still quite expensive because they can be killed only
-temporarily and the system tries to keep them running whenever possible.</li>
-
-<li>Home process: A special slot for the process that hosts the current Home activity, to try to
-prevent it from being killed as much as possible. Killing this process is much more damaging to the
-user experience than killing other cached processes, because so much user interaction goes through
-home.</li>
-
-<li>Secondary service processes: These are services that have been running for a relatively long time
-and so should be killed more aggressively when RAM is needed elsewhere.</li>
-
-<li>Cached processes: These are cached processes held in the LRU cache, which allow for fast app
-switching and component launching. These processes are not required and the system will kill them
-as needed to reclaim memory. You will often see a process hosting a running service here—this is
-part of a platform policy of allowing very long-running services to drop down into the LRU list and
-eventually be killed. If the service should continue running (as defined by the {@link
-android.app.Service#onStartCommand onStartCommand()} return value, such as {@link
-android.app.Service#START_STICKY}), the the system eventually restarts it. This avoids issues with
-such services having memory leaks that over time reduce the number of regular cached processes that
-can be kept.</li>
-
-</ol>
-
-<p>This numbered list of processes is essentially the LRU list of processes that the framework
-provides to the kernel to help it determine which processes it should kill as it needs more RAM.
-The kernel's out of memory killer will generally begin from the bottom of this list, killing the
-last process and working its way up. It may not do it in exactly this order, as it can also take
-into consideration other factors such as the relative RAM footprint of processes to some degree.</p>
-
-<p>There are many other options you can use with the activity command to analyze further details of
-your app's state—use <code>adb shell dumpsys activity -h</code> for help on its use.</p>
-
--->
diff --git a/docs/html/training/articles/perf-tips.jd b/docs/html/training/articles/perf-tips.jd
index 82de69a..30cab14 100644
--- a/docs/html/training/articles/perf-tips.jd
+++ b/docs/html/training/articles/perf-tips.jd
@@ -28,7 +28,8 @@
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.</p>
+efficiency.
+</p>
<p>There are two basic rules for writing efficient code:</p>
<ul>
@@ -49,8 +50,7 @@
without.</p>
<p>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.</p>
-
+your code is efficient at all levels and aggressively optimize your performance.</p>
<h2 id="ObjectCreation">Avoid Creating Unnecessary Objects</h2>
diff --git a/docs/html/training/best-performance.jd b/docs/html/training/best-performance.jd
index 8ea6fd5..bb88e99 100644
--- a/docs/html/training/best-performance.jd
+++ b/docs/html/training/best-performance.jd
@@ -5,4 +5,9 @@
<p>These classes and articles help you build an app that's smooth, responsive,
-and uses as little battery as possible.</p>
\ No newline at end of file
+and uses as little battery as possible.</p>
+
+<p>Along with this section, you can find additional information about optimizing
+your app in the <a href="/topic/performance/index.html">Performance and
+Power</a> section.</p>
+
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index d0dccba..39ca6fb 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -1888,6 +1888,12 @@
>Managing Your App's Memory</a>
</li>
<li>
+ <a href="<?cs var:toroot ?>training/articles/memory-overview.html"
+ description=
+ "How Android manages app process and memory allocation."
+ >Overview of Android Memory Management</a>
+ </li>
+ <li>
<a href="<?cs var:toroot ?>training/articles/perf-tips.html"
description=
"How to optimize your app's performance in various ways to improve its
diff --git a/docs/html/wear/preview/downloads.jd b/docs/html/wear/preview/downloads.jd
index 08ed233..83a3f98 100644
--- a/docs/html/wear/preview/downloads.jd
+++ b/docs/html/wear/preview/downloads.jd
@@ -626,7 +626,7 @@
the accounts on the phone.
</li>
- <li>Choose a Google account to add and sync to your watch.
+ <li>Choose a Google Account to add and sync to your watch.
</li>
<li>Confirm the screen lock and enter the password to start the copying of
@@ -647,8 +647,13 @@
</h2>
<p>
- To test with the Android Emulator, create a virtual device in Android
- Studio as follows:
+ To test with the Android Emulator,
+ confirm that you have the latest version of the <strong>Android SDK
+ Platform-tools</strong> from the <a href=
+ "{@docRoot}studio/intro/update.html#sdk-manager">SDK Manager</a>.
+ </p>
+
+ <p>Create a new virtual device in Android Studio as follows:
</p>
<ol>
@@ -659,8 +664,8 @@
<li>Click <strong>Create Virtual Device</strong>.
</li>
- <li>In the <strong>Category</strong> pane, select Wear and
- choose a hardware profile.
+ <li>In the <strong>Category</strong> pane, select <strong>Wear</strong>
+ and choose a hardware profile.
The Android Wear 2.0 Developer Preview
is only optimized for round devices currently, so we recommend not
using the square or chin profiles for now.
@@ -679,16 +684,66 @@
<li>Verify the configuration of the Android Virtual Device (AVD) and
click <strong>Finish</strong>.
</li>
+
+ <li>Start the emulator by selecting the new virtual device, clicking the
+ <strong>Play</strong> button, and waiting until
+ the emulator initializes and shows the Android Wear home screen.
+ </li>
</ol>
<p>
- You can now test an application with a virtual preview device
+ Pair the phone with the emulator, and sync a Google Account, as follows:
+ </p>
+
+ <ol>
+ <li>On the phone, install the Android Wear app from Google Play.
+ </li>
+
+ <li>On the phone, enable Developer Options and USB Debugging.
+ </li>
+
+ <li>Connect the phone to your computer through USB.
+ </li>
+
+ <li>Forward the AVD's communication port to the connected handheld device
+ (each time the phone is connected):<br>
+ <code>adb -d forward tcp:5601 tcp:5601</code>
+ </li>
+
+ <li>On the phone, in the Android Wear app, begin the standard pairing
+ process. For example, on the Welcome screen, tap the
+ <strong>Set It Up</strong> button.
+ Alternatively, if an existing watch already is paired, in the upper-left
+ drop-down, tap <strong>Add a New Watch</strong>.
+ </li>
+
+ <li>On the phone, in the Android Wear app, tap the
+ Overflow button, and then tap
+ <strong>Pair with Emulator</strong>.
+ </li>
+
+ <li>Tap the Settings icon.
+ </li>
+
+ <li>Under Device Settings, tap <strong>Emulator</strong>.
+ </li>
+
+ <li>Tap <strong>Accounts</strong> and select a Google Account,
+ and follow the steps in the wizard to
+ sync the account with the emulator. If necessary, type the screen-lock
+ device password, and Google Account password, to start the account sync.
+ </li>
+ </ol>
+
+ <p>
+ You can now test an app with a virtual preview device
in the <a href=
"{@docRoot}tools/devices/emulator.html">Android Emulator</a>. For more
information about using virtual devices, see <a href=
- "{@docRoot}tools/devices/managing-avds.html">Managing AVDs with the AVD
- Manager</a>.
+ "{@docRoot}tools/devices/managing-avds.html">
+ Create and Manage Virtual Devices</a>.
</p>
+
</div><!-- landing -->
</div><!-- relative wrapper -->
diff --git a/docs/html/wear/preview/support.jd b/docs/html/wear/preview/support.jd
index 7636d86..6006627 100644
--- a/docs/html/wear/preview/support.jd
+++ b/docs/html/wear/preview/support.jd
@@ -319,6 +319,22 @@
</li>
</ul>
+ <h4 id="account">
+ Account sync
+ </h4>
+
+ <ul>
+ <li>Account sync initiated from watch settings may not work reliably.
+ Instead, add accounts from the setup flow of the Android Wear app, or using
+ the Accounts settings for a device from the Android Wear app.
+ </li>
+
+ <li>The list of accounts that can be synced is the same as the list of accounts
+ on the phone. So to add a new account, use the Android settings on the phone,
+ and then proceed to Android Wear app to sync that account.
+ </li>
+ </ul>
+
<h4 id="devices">
Devices
</h4>
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java b/packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java
index 45d51b0..0bc70b5 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/NavigationBarView.java
@@ -59,6 +59,8 @@
// slippery nav bar when everything is disabled, e.g. during setup
final static boolean SLIPPERY_WHEN_DISABLED = true;
+ final static boolean ALTERNATE_CAR_MODE_UI = false;
+
final Display mDisplay;
View mCurrentView = null;
View[] mRotatedViews = new View[4];
@@ -94,7 +96,8 @@
private OnVerticalChangedListener mOnVerticalChangedListener;
private boolean mLayoutTransitionsEnabled = true;
private boolean mWakeAndUnlocking;
- private boolean mCarMode = false;
+ private boolean mUseCarModeUi = false;
+ private boolean mInCarMode = false;
private boolean mDockedStackExists;
private final SparseArray<ButtonDispatcher> mButtonDisatchers = new SparseArray<>();
@@ -290,7 +293,9 @@
mMenuIcon = ctx.getDrawable(R.drawable.ic_sysbar_menu);
mImeIcon = ctx.getDrawable(R.drawable.ic_ime_switcher_default);
- updateCarModeIcons(ctx);
+ if (ALTERNATE_CAR_MODE_UI) {
+ updateCarModeIcons(ctx);
+ }
}
}
@@ -341,14 +346,14 @@
// carmode, respectively. Recents are not available in CarMode in nav bar so change
// to recent icon is not required.
Drawable backIcon = (backAlt)
- ? getBackIconWithAlt(mCarMode, mVertical)
- : getBackIcon(mCarMode, mVertical);
+ ? getBackIconWithAlt(mUseCarModeUi, mVertical)
+ : getBackIcon(mUseCarModeUi, mVertical);
getBackButton().setImageDrawable(backIcon);
updateRecentsIcon();
- if (mCarMode) {
+ if (mUseCarModeUi) {
getHomeButton().setImageDrawable(mHomeCarModeIcon);
} else {
getHomeButton().setImageDrawable(mHomeDefaultIcon);
@@ -376,9 +381,9 @@
final boolean disableHome = ((disabledFlags & View.STATUS_BAR_DISABLE_HOME) != 0);
- // Disable recents always in car mode.
- boolean disableRecent = (
- mCarMode || (disabledFlags & View.STATUS_BAR_DISABLE_RECENT) != 0);
+ // Always disable recents when alternate car mode UI is active.
+ boolean disableRecent = mUseCarModeUi
+ || ((disabledFlags & View.STATUS_BAR_DISABLE_RECENT) != 0);
final boolean disableBack = ((disabledFlags & View.STATUS_BAR_DISABLE_BACK) != 0)
&& ((mNavigationIconHints & StatusBarManager.NAVIGATION_HINT_BACK_ALT) == 0);
final boolean disableSearch = ((disabledFlags & View.STATUS_BAR_DISABLE_SEARCH) != 0);
@@ -623,14 +628,19 @@
boolean uiCarModeChanged = false;
if (newConfig != null) {
int uiMode = newConfig.uiMode & Configuration.UI_MODE_TYPE_MASK;
- if (mCarMode && uiMode != Configuration.UI_MODE_TYPE_CAR) {
- mCarMode = false;
- uiCarModeChanged = true;
- getHomeButton().setCarMode(mCarMode);
- } else if (uiMode == Configuration.UI_MODE_TYPE_CAR) {
- mCarMode = true;
- uiCarModeChanged = true;
- getHomeButton().setCarMode(mCarMode);
+ final boolean isCarMode = (uiMode == Configuration.UI_MODE_TYPE_CAR);
+
+ if (isCarMode != mInCarMode) {
+ mInCarMode = isCarMode;
+ getHomeButton().setCarMode(isCarMode);
+
+ if (ALTERNATE_CAR_MODE_UI) {
+ mUseCarModeUi = isCarMode;
+ uiCarModeChanged = true;
+ } else {
+ // Don't use car mode behavior if ALTERNATE_CAR_MODE_UI not set.
+ mUseCarModeUi = false;
+ }
}
}
return uiCarModeChanged;
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java b/packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
index f4b41bb..ae75229 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
@@ -328,7 +328,7 @@
} else if (!mQsExpanded) {
setQsExpansion(mQsMinExpansionHeight + mLastOverscroll);
}
- updateStackHeight(getExpandedHeight());
+ updateExpandedHeight(getExpandedHeight());
updateHeader();
// If we are running a size change animation, the animation takes care of the height of
@@ -376,10 +376,7 @@
boolean animate = mNotificationStackScroller.isAddOrRemoveAnimationPending();
int stackScrollerPadding;
if (mStatusBarState != StatusBarState.KEYGUARD) {
- int bottom = mQsContainer.getHeader().getHeight();
- stackScrollerPadding = mStatusBarState == StatusBarState.SHADE
- ? bottom + mQsPeekHeight
- : mKeyguardStatusBar.getHeight();
+ stackScrollerPadding = mQsContainer.getHeader().getHeight() + mQsPeekHeight;
mTopPaddingAdjustment = 0;
} else {
mClockPositionAlgorithm.setup(
@@ -1166,6 +1163,7 @@
private void updateQsState() {
mQsContainer.setExpanded(mQsExpanded);
+ mNotificationStackScroller.setQsExpanded(mQsExpanded);
mNotificationStackScroller.setScrollingEnabled(
mStatusBarState != StatusBarState.KEYGUARD && (!mQsExpanded
|| mQsExpansionFromOverscroll));
@@ -1427,7 +1425,7 @@
setQsExpansion(mQsMinExpansionHeight
+ t * (getTempQsMaxExpansion() - mQsMinExpansionHeight));
}
- updateStackHeight(expandedHeight);
+ updateExpandedHeight(expandedHeight);
updateHeader();
updateUnlockIcon();
updateNotificationTranslucency();
@@ -1487,7 +1485,7 @@
maxQsHeight, mStatusBarState == StatusBarState.KEYGUARD
? mClockPositionResult.stackScrollerPadding - mTopPaddingAdjustment
: 0)
- + notificationHeight;
+ + notificationHeight + mNotificationStackScroller.getTopPaddingOverflow();
if (totalHeight > mNotificationStackScroller.getHeight()) {
float fullyCollapsedHeight = maxQsHeight
+ mNotificationStackScroller.getLayoutMinHeight();
@@ -1730,6 +1728,14 @@
if (view == null && mQsExpanded) {
return;
}
+ ExpandableView firstChildNotGone = mNotificationStackScroller.getFirstChildNotGone();
+ ExpandableNotificationRow firstRow = firstChildNotGone instanceof ExpandableNotificationRow
+ ? (ExpandableNotificationRow) firstChildNotGone
+ : null;
+ if (firstRow != null
+ && (view == firstRow || (firstRow.getNotificationParent() == firstRow))) {
+ requestScrollerTopPaddingUpdate(false);
+ }
requestPanelHeightUpdate();
}
@@ -2249,8 +2255,8 @@
mQsAutoReinflateContainer.setTranslationX(translation);
}
- protected void updateStackHeight(float stackHeight) {
- mNotificationStackScroller.setStackHeight(stackHeight);
+ protected void updateExpandedHeight(float expandedHeight) {
+ mNotificationStackScroller.setExpandedHeight(expandedHeight);
updateKeyguardBottomAreaAlpha();
}
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/stack/AmbientState.java b/packages/SystemUI/src/com/android/systemui/statusbar/stack/AmbientState.java
index 50e5b88..81da672 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/stack/AmbientState.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/stack/AmbientState.java
@@ -43,6 +43,7 @@
private boolean mShadeExpanded;
private float mMaxHeadsUpTranslation;
private boolean mDismissAllInProgress;
+ private int mLayoutMinHeight;
public int getScrollY() {
return mScrollY;
@@ -137,10 +138,6 @@
mStackTranslation = stackTranslation;
}
- public int getLayoutHeight() {
- return mLayoutHeight;
- }
-
public void setLayoutHeight(int layoutHeight) {
mLayoutHeight = layoutHeight;
}
@@ -154,7 +151,7 @@
}
public int getInnerHeight() {
- return mLayoutHeight - mTopPadding;
+ return Math.max(mLayoutHeight - mTopPadding, mLayoutMinHeight);
}
public boolean isShadeExpanded() {
@@ -180,4 +177,8 @@
public boolean isDismissAllInProgress() {
return mDismissAllInProgress;
}
+
+ public void setLayoutMinHeight(int layoutMinHeight) {
+ mLayoutMinHeight = layoutMinHeight;
+ }
}
diff --git a/packages/SystemUI/src/com/android/systemui/statusbar/stack/NotificationStackScrollLayout.java b/packages/SystemUI/src/com/android/systemui/statusbar/stack/NotificationStackScrollLayout.java
index 3e339d8..e87adae 100644
--- a/packages/SystemUI/src/com/android/systemui/statusbar/stack/NotificationStackScrollLayout.java
+++ b/packages/SystemUI/src/com/android/systemui/statusbar/stack/NotificationStackScrollLayout.java
@@ -111,11 +111,7 @@
private int mCurrentStackHeight = Integer.MAX_VALUE;
private final Paint mBackgroundPaint = new Paint();
- /**
- * mCurrentStackHeight is the actual stack height, mLastSetStackHeight is the stack height set
- * externally from {@link #setStackHeight}
- */
- private float mLastSetStackHeight;
+ private float mExpandedHeight;
private int mOwnScrollY;
private int mMaxLayoutHeight;
@@ -354,6 +350,7 @@
return object.getBackgroundFadeAmount();
}
};
+ private boolean mQsExpanded;
public NotificationStackScrollLayout(Context context) {
this(context, null);
@@ -519,6 +516,7 @@
clampScrollPosition();
requestChildrenUpdate();
updateFirstAndLastBackgroundViews();
+ updateAlgorithmLayoutMinHeight();
}
private void requestAnimationOnViewResize(ExpandableNotificationRow row) {
@@ -560,9 +558,14 @@
private void updateAlgorithmHeightAndPadding() {
mAmbientState.setLayoutHeight(getLayoutHeight());
+ updateAlgorithmLayoutMinHeight();
mAmbientState.setTopPadding(mTopPadding);
}
+ private void updateAlgorithmLayoutMinHeight() {
+ mAmbientState.setLayoutMinHeight(mQsExpanded && !onKeyguard() ? getLayoutMinHeight() : 0);
+ }
+
/**
* Updates the children views according to the stack scroll algorithm. Call this whenever
* modifications to {@link #mOwnScrollY} are performed to reflect it in the view layout.
@@ -659,19 +662,19 @@
}
/**
- * Update the height of the stack to a new height.
+ * Update the height of the panel.
*
- * @param height the new height of the stack
+ * @param height the expanded height of the panel
*/
- public void setStackHeight(float height) {
- mLastSetStackHeight = height;
+ public void setExpandedHeight(float height) {
+ mExpandedHeight = height;
setIsExpanded(height > 0.0f);
int stackHeight;
float translationY;
float appearEndPosition = getAppearEndPosition();
float appearStartPosition = getAppearStartPosition();
if (height >= appearEndPosition) {
- translationY = mTopPaddingOverflow;
+ translationY = 0;
stackHeight = (int) height;
} else {
float appearFraction = getAppearFraction(height);
@@ -698,8 +701,12 @@
* Measured relative to the resting position.
*/
private float getExpandTranslationStart() {
- int startPosition = mTrackingHeadsUp || mHeadsUpManager.hasPinnedHeadsUp()
- ? 0 : -getFirstChildIntrinsicHeight();
+ int startPosition = 0;
+ if (!mTrackingHeadsUp && !mHeadsUpManager.hasPinnedHeadsUp()) {
+ startPosition = - Math.min(getFirstChildIntrinsicHeight(),
+ mMaxLayoutHeight - mIntrinsicPadding - mBottomStackSlowDownHeight
+ - mBottomStackPeekSize);
+ }
return startPosition - mTopPadding;
}
@@ -722,7 +729,7 @@
? mHeadsUpManager.getTopHeadsUpPinnedHeight() + mBottomStackPeekSize
+ mBottomStackSlowDownHeight
: getLayoutMinHeight();
- return firstItemHeight + mTopPadding + mTopPaddingOverflow;
+ return firstItemHeight + (onKeyguard() ? mTopPadding : mIntrinsicPadding);
}
/**
@@ -1152,6 +1159,10 @@
@Override
public boolean isAntiFalsingNeeded() {
+ return onKeyguard();
+ }
+
+ private boolean onKeyguard() {
return mPhoneStatusBar.getBarState() == StatusBarState.KEYGUARD;
}
@@ -1228,7 +1239,7 @@
if (!isScrollingEnabled()) {
return false;
}
- if (ev.getY() < mQsContainer.getBottom()) {
+ if (ev.getY() < mQsContainer.getBottom() && !mIsBeingDragged) {
return false;
}
mForcedScroll = null;
@@ -2122,26 +2133,22 @@
*/
public void updateTopPadding(float qsHeight, boolean animate,
boolean ignoreIntrinsicPadding) {
- float start = qsHeight;
- float stackHeight = getHeight() - start;
+ int topPadding = (int) qsHeight;
int minStackHeight = getLayoutMinHeight();
- if (stackHeight <= minStackHeight) {
- float overflow = minStackHeight - stackHeight;
- stackHeight = minStackHeight;
- start = getHeight() - stackHeight;
- mTopPaddingOverflow = overflow;
+ if (topPadding + minStackHeight > getHeight()) {
+ mTopPaddingOverflow = topPadding + minStackHeight - getHeight();
} else {
mTopPaddingOverflow = 0;
}
- setTopPadding(ignoreIntrinsicPadding ? (int) start : clampPadding((int) start),
+ setTopPadding(ignoreIntrinsicPadding ? topPadding : clampPadding(topPadding),
animate);
- setStackHeight(mLastSetStackHeight);
+ setExpandedHeight(mExpandedHeight);
}
public int getLayoutMinHeight() {
int firstChildMinHeight = getFirstChildIntrinsicHeight();
return Math.min(firstChildMinHeight + mBottomStackPeekSize + mBottomStackSlowDownHeight,
- mMaxLayoutHeight - mTopPadding);
+ mMaxLayoutHeight - mIntrinsicPadding);
}
public int getFirstChildIntrinsicHeight() {
@@ -3088,10 +3095,14 @@
updateScrollPositionOnExpandInBottom(view);
clampScrollPosition();
notifyHeightChangeListener(view);
+ ExpandableNotificationRow row = view instanceof ExpandableNotificationRow
+ ? (ExpandableNotificationRow) view
+ : null;
+ if (row != null && (row == mFirstVisibleBackgroundChild
+ || row.getNotificationParent() == mFirstVisibleBackgroundChild)) {
+ updateAlgorithmLayoutMinHeight();
+ }
if (needsAnimation) {
- ExpandableNotificationRow row = view instanceof ExpandableNotificationRow
- ? (ExpandableNotificationRow) view
- : null;
requestAnimationOnViewResize(row);
}
requestChildrenUpdate();
@@ -3374,7 +3385,7 @@
}
private int findDarkAnimationOriginIndex(@Nullable PointF screenLocation) {
- if (screenLocation == null || screenLocation.y < mTopPadding + mTopPaddingOverflow) {
+ if (screenLocation == null || screenLocation.y < mTopPadding) {
return AnimationEvent.DARK_ANIMATION_ORIGIN_INDEX_ABOVE;
}
if (screenLocation.y > getBottomMostNotificationBottom()) {
@@ -3858,6 +3869,11 @@
mCurrentStackScrollState.removeViewStateForView(view);
}
+ public void setQsExpanded(boolean qsExpanded) {
+ mQsExpanded = qsExpanded;
+ updateAlgorithmLayoutMinHeight();
+ }
+
/**
* A listener that is notified when some child locations might have changed.
*/
@@ -4081,7 +4097,7 @@
onDragCancelled(animView);
// If we're on the lockscreen we want to false this.
- if (mPhoneStatusBar.getBarState() == StatusBarState.KEYGUARD) {
+ if (isAntiFalsingNeeded()) {
mHandler.removeCallbacks(mFalsingCheck);
mHandler.postDelayed(mFalsingCheck, COVER_GEAR_DELAY);
}
diff --git a/services/core/java/com/android/server/am/ActivityManagerService.java b/services/core/java/com/android/server/am/ActivityManagerService.java
index b623bc7..85d2981 100644
--- a/services/core/java/com/android/server/am/ActivityManagerService.java
+++ b/services/core/java/com/android/server/am/ActivityManagerService.java
@@ -20669,8 +20669,11 @@
final long now = SystemClock.elapsedRealtime();
Long lastReported = userState.mProviderLastReportedFg.get(authority);
if (lastReported == null || lastReported < now - 60 * 1000L) {
- mUsageStatsService.reportContentProviderUsage(
- authority, providerPkgName, app.userId);
+ if (mSystemReady) {
+ // Cannot touch the user stats if not system ready
+ mUsageStatsService.reportContentProviderUsage(
+ authority, providerPkgName, app.userId);
+ }
userState.mProviderLastReportedFg.put(authority, now);
}
}
diff --git a/services/core/java/com/android/server/fingerprint/FingerprintService.java b/services/core/java/com/android/server/fingerprint/FingerprintService.java
index 73c8469..9e132f7 100644
--- a/services/core/java/com/android/server/fingerprint/FingerprintService.java
+++ b/services/core/java/com/android/server/fingerprint/FingerprintService.java
@@ -195,6 +195,7 @@
public void binderDied() {
Slog.v(TAG, "fingerprintd died");
mDaemon = null;
+ mCurrentUserId = UserHandle.USER_CURRENT;
handleError(mHalDeviceId, FingerprintManager.FINGERPRINT_ERROR_HW_UNAVAILABLE);
}
diff --git a/services/core/java/com/android/server/policy/PhoneWindowManager.java b/services/core/java/com/android/server/policy/PhoneWindowManager.java
index 7162b94..3ec3cea 100644
--- a/services/core/java/com/android/server/policy/PhoneWindowManager.java
+++ b/services/core/java/com/android/server/policy/PhoneWindowManager.java
@@ -182,6 +182,8 @@
// No longer recommended for desk docks;
static final boolean ENABLE_DESK_DOCK_HOME_CAPTURE = false;
+ static final boolean ALTERNATE_CAR_MODE_NAV_SIZE = false;
+
static final int SHORT_PRESS_POWER_NOTHING = 0;
static final int SHORT_PRESS_POWER_GO_TO_SLEEP = 1;
static final int SHORT_PRESS_POWER_REALLY_GO_TO_SLEEP = 2;
@@ -2336,22 +2338,24 @@
mNavigationBarWidthForRotationDefault[mSeascapeRotation] =
res.getDimensionPixelSize(com.android.internal.R.dimen.navigation_bar_width);
- // Height of the navigation bar when presented horizontally at bottom
- mNavigationBarHeightForRotationInCarMode[mPortraitRotation] =
- mNavigationBarHeightForRotationInCarMode[mUpsideDownRotation] =
- res.getDimensionPixelSize(
- com.android.internal.R.dimen.navigation_bar_height_car_mode);
- mNavigationBarHeightForRotationInCarMode[mLandscapeRotation] =
- mNavigationBarHeightForRotationInCarMode[mSeascapeRotation] = res.getDimensionPixelSize(
- com.android.internal.R.dimen.navigation_bar_height_landscape_car_mode);
+ if (ALTERNATE_CAR_MODE_NAV_SIZE) {
+ // Height of the navigation bar when presented horizontally at bottom
+ mNavigationBarHeightForRotationInCarMode[mPortraitRotation] =
+ mNavigationBarHeightForRotationInCarMode[mUpsideDownRotation] =
+ res.getDimensionPixelSize(
+ com.android.internal.R.dimen.navigation_bar_height_car_mode);
+ mNavigationBarHeightForRotationInCarMode[mLandscapeRotation] =
+ mNavigationBarHeightForRotationInCarMode[mSeascapeRotation] = res.getDimensionPixelSize(
+ com.android.internal.R.dimen.navigation_bar_height_landscape_car_mode);
- // Width of the navigation bar when presented vertically along one side
- mNavigationBarWidthForRotationInCarMode[mPortraitRotation] =
- mNavigationBarWidthForRotationInCarMode[mUpsideDownRotation] =
- mNavigationBarWidthForRotationInCarMode[mLandscapeRotation] =
- mNavigationBarWidthForRotationInCarMode[mSeascapeRotation] =
- res.getDimensionPixelSize(
- com.android.internal.R.dimen.navigation_bar_width_car_mode);
+ // Width of the navigation bar when presented vertically along one side
+ mNavigationBarWidthForRotationInCarMode[mPortraitRotation] =
+ mNavigationBarWidthForRotationInCarMode[mUpsideDownRotation] =
+ mNavigationBarWidthForRotationInCarMode[mLandscapeRotation] =
+ mNavigationBarWidthForRotationInCarMode[mSeascapeRotation] =
+ res.getDimensionPixelSize(
+ com.android.internal.R.dimen.navigation_bar_width_car_mode);
+ }
}
/** {@inheritDoc} */
@@ -2483,7 +2487,7 @@
}
private int getNavigationBarWidth(int rotation, int uiMode) {
- if ((uiMode & UI_MODE_TYPE_MASK) == UI_MODE_TYPE_CAR) {
+ if (ALTERNATE_CAR_MODE_NAV_SIZE && (uiMode & UI_MODE_TYPE_MASK) == UI_MODE_TYPE_CAR) {
return mNavigationBarWidthForRotationInCarMode[rotation];
} else {
return mNavigationBarWidthForRotationDefault[rotation];
@@ -2504,7 +2508,7 @@
}
private int getNavigationBarHeight(int rotation, int uiMode) {
- if ((uiMode & UI_MODE_TYPE_MASK) == UI_MODE_TYPE_CAR) {
+ if (ALTERNATE_CAR_MODE_NAV_SIZE && (uiMode & UI_MODE_TYPE_MASK) == UI_MODE_TYPE_CAR) {
return mNavigationBarHeightForRotationInCarMode[rotation];
} else {
return mNavigationBarHeightForRotationDefault[rotation];
diff --git a/services/core/java/com/android/server/power/ShutdownThread.java b/services/core/java/com/android/server/power/ShutdownThread.java
index 8ce2fd9..44894ed 100644
--- a/services/core/java/com/android/server/power/ShutdownThread.java
+++ b/services/core/java/com/android/server/power/ShutdownThread.java
@@ -717,6 +717,14 @@
}
if (!done[0]) {
Log.w(TAG, "Timed out waiting for uncrypt.");
+ final int uncryptTimeoutError = 100;
+ String timeoutMessage = String.format("uncrypt_time: %d\n" + "uncrypt_error: %d\n",
+ MAX_UNCRYPT_WAIT_TIME / 1000, uncryptTimeoutError);
+ try {
+ FileUtils.stringToFile(RecoverySystem.UNCRYPT_STATUS_FILE, timeoutMessage);
+ } catch (IOException e) {
+ Log.e(TAG, "Failed to write timeout message to uncrypt status", e);
+ }
}
}
}
diff --git a/services/core/java/com/android/server/wm/AppTransition.java b/services/core/java/com/android/server/wm/AppTransition.java
index e4ec295..cd46165 100644
--- a/services/core/java/com/android/server/wm/AppTransition.java
+++ b/services/core/java/com/android/server/wm/AppTransition.java
@@ -374,6 +374,7 @@
void goodToGo(AppWindowAnimator topOpeningAppAnimator, AppWindowAnimator topClosingAppAnimator,
ArraySet<AppWindowToken> openingApps, ArraySet<AppWindowToken> closingApps) {
+ int appTransition = mNextAppTransition;
mNextAppTransition = TRANSIT_UNSET;
mAppTransitionState = APP_STATE_RUNNING;
notifyAppTransitionStartingLocked(
@@ -382,7 +383,7 @@
topOpeningAppAnimator != null ? topOpeningAppAnimator.animation : null,
topClosingAppAnimator != null ? topClosingAppAnimator.animation : null);
mService.getDefaultDisplayContentLocked().getDockedDividerController()
- .notifyAppTransitionStarting(openingApps);
+ .notifyAppTransitionStarting(openingApps, appTransition);
// Prolong the start for the transition when docking a task from recents, unless recents
// ended it already then we don't need to wait.
diff --git a/services/core/java/com/android/server/wm/AppWindowToken.java b/services/core/java/com/android/server/wm/AppWindowToken.java
index a8a0b0e..b1d2edf 100644
--- a/services/core/java/com/android/server/wm/AppWindowToken.java
+++ b/services/core/java/com/android/server/wm/AppWindowToken.java
@@ -846,6 +846,9 @@
void overridePlayingAppAnimations(Animation a) {
if (mAppAnimator.isAnimating()) {
final WindowState win = findMainWindow();
+ if (win == null) {
+ return;
+ }
final int width = win.mContainingFrame.width();
final int height = win.mContainingFrame.height();
mAppAnimator.setAnimation(a, width, height, false, STACK_CLIP_NONE);
diff --git a/services/core/java/com/android/server/wm/DisplayContent.java b/services/core/java/com/android/server/wm/DisplayContent.java
index b90b864..12399bd 100644
--- a/services/core/java/com/android/server/wm/DisplayContent.java
+++ b/services/core/java/com/android/server/wm/DisplayContent.java
@@ -697,7 +697,8 @@
for (int i = 0; i < windowCount; i++) {
WindowState window = windows.get(i);
if (window.mAttrs.type == TYPE_TOAST && window.mOwnerUid == uid
- && !window.mPermanentlyHidden && !window.mAnimatingExit) {
+ && !window.mPermanentlyHidden && !window.mAnimatingExit
+ && !window.mRemoveOnExit) {
return false;
}
}
diff --git a/services/core/java/com/android/server/wm/DockedStackDividerController.java b/services/core/java/com/android/server/wm/DockedStackDividerController.java
index f8d2ee9..6f0a43a 100644
--- a/services/core/java/com/android/server/wm/DockedStackDividerController.java
+++ b/services/core/java/com/android/server/wm/DockedStackDividerController.java
@@ -29,6 +29,7 @@
import static android.view.WindowManager.DOCKED_TOP;
import static com.android.server.wm.AppTransition.DEFAULT_APP_TRANSITION_DURATION;
import static com.android.server.wm.AppTransition.TOUCH_RESPONSE_INTERPOLATOR;
+import static com.android.server.wm.AppTransition.TRANSIT_NONE;
import static com.android.server.wm.WindowManagerDebugConfig.TAG_WITH_CLASS_NAME;
import static com.android.server.wm.WindowManagerDebugConfig.TAG_WM;
import static com.android.server.wm.WindowManagerService.H.NOTIFY_DOCKED_STACK_MINIMIZED_CHANGED;
@@ -493,7 +494,7 @@
checkMinimizeChanged(false /* animate */);
}
- void notifyAppTransitionStarting(ArraySet<AppWindowToken> openingApps) {
+ void notifyAppTransitionStarting(ArraySet<AppWindowToken> openingApps, int appTransition) {
final boolean wasMinimized = mMinimizedDock;
checkMinimizeChanged(true /* animate */);
@@ -502,7 +503,8 @@
// any case that was missed in ActivityStarter.postStartActivityUncheckedProcessing because
// we couldn't retrace the launch of the app in the docked stack to the launch from
// homescreen.
- if (wasMinimized && mMinimizedDock && containsAppInDockedStack(openingApps)) {
+ if (wasMinimized && mMinimizedDock && containsAppInDockedStack(openingApps)
+ && appTransition != TRANSIT_NONE) {
mService.showRecentApps(true /* fromHome */);
}
}
