Merge "docs: Add weekly subscriptions and grace period information to IAB docs" into lmp-mr1-ub-docs
diff --git a/docs/html/guide/topics/renderscript/compute.jd b/docs/html/guide/topics/renderscript/compute.jd
index 2e7ce56..eef8cda 100644
--- a/docs/html/guide/topics/renderscript/compute.jd
+++ b/docs/html/guide/topics/renderscript/compute.jd
@@ -185,50 +185,101 @@
<p>You can check and update the installed version of these tools in the
<a href="{@docRoot}tools/help/sdk-manager.html">Android SDK Manager</a>.</p>
-<p class="note">
- <strong>Note:</strong> Use of Support Library RenderScript APIs is not currently supported with
- Android Studio or Gradle-based builds.
-</p>
-<p>To use the Support Library RenderScript APIs in Eclipse:</p>
+<p>To use the Support Library RenderScript APIs:</p>
<ol>
<li>Make sure you have the required Android SDK version and Build Tools version installed.</li>
- <li>Open the {@code project.properties} file in the root folder of your application project.</li>
- <li>Add the following lines to the file:
+ <li> Update the settings for the Android build process to include the RenderScript settings:
+
+ <p><strong>For Android Studio or Gradle-based builds</strong></p>
+ <ul>
+ <li>Open the {@code build.gradle} file in the app folder of your application module. </li>
+ <li>Add the following RenderScript settings to the file:
+
+<pre>
+android {
+ compileSdkVersion 19
+ buildToolsVersion "19.0.3"
+
+ defaultConfig {
+ minSdkVersion 8
+ targetSdkVersion 16
+<strong>
+ renderscriptTargetApi 18
+ renderscriptSupportModeEnabled true
+</strong>
+ }
+}
+</pre>
+
+
+ <p>The settings listed above control specific behavior in the Android build process:</p>
+
+ <ul>
+ <li>{@code renderscriptTargetApi} - Specifies the bytecode version to be generated. We
+ recommend you set this value to the highest available API level and set
+ {@code renderscriptSupportModeEnabled}
+ to {@code true}. Valid values for this setting are any integer value
+ from 11 to the most recently released API level. If your minimum SDK version specified in your
+ application manifest is set to a different value, that value is ignored and the target value
+ in the build file is used to set the minimum SDK version.</li>
+ <li>{@code renderscriptSupportModeEnabled} - Specifies that the generated bytecode should fall
+ back to a compatible version if the device it is running on does not support the target
+ version.
+ </li>
+ <li>{@code buildToolsVersion} - The version of the Android SDK build tools to use. This value
+ should be set to {@code 18.1.0} or higher. If this option is not specified, the highest
+ installed build tools version is used. You should always set this value to ensure the
+ consistency of builds across development machines with different configurations.</li>
+ </ul>
+
+ </li>
+
+ <p><strong>For Eclipse</strong></p>
+ <ul>
+ <li>Open the {@code project.properties} file in the root folder of your application project.</li>
+ <li>Add the following lines to the file:
+
<pre>
renderscript.target=18
renderscript.support.mode=true
sdk.buildtools=18.1.0
</pre>
- </li>
+
+ <p>The settings listed above control specific behavior in the Android build process:</p>
+
+ <ul>
+ <li>{@code renderscript.target} - Specifies the bytecode version to be generated. We
+ recommend you set this value to the highest available API level and set
+ {@code renderscript.support.mode} to {@code true}. Valid values for this setting are any
+ integer value from 11 to the most recently released API level. If your minimum SDK version
+ specified in your application manifest is set to a higher value, this value is ignored and
+ the target value is set to the minimum SDK version.</li>
+ <li>{@code renderscript.support.mode} - Specifies that the generated bytecode should fall
+ back to a compatible version if the device it is running on does not support the target version.
+ </li>
+ <li>{@code sdk.buildtools} - The version of the Android SDK build tools to use. This value
+ should be set to {@code 18.1.0} or higher. If this option is not specified, the highest
+ installed build tools version is used. You should always set this value to ensure the
+ consistency of builds across development machines with different configurations.</li>
+ </ul>
+ </li>
+
+ </ul>
+
+ </ul>
+
<li>In your application classes that use RenderScript, add an import for the Support Library
classes:
+
<pre>
import android.support.v8.renderscript.*;
</pre>
+
</li>
-</ol>
-<p>The {@code project.properties} settings listed above control specific behavior in the Android
- build process:</p>
-
-<ul>
- <li>{@code renderscript.target} - Specifies the bytecode version to be generated. We
- recommend you set this value the highest available API level and set {@code
- renderscript.support.mode} to {@code true}. Valid values for this setting are any integer value
- from 11 to the most recently released API level. If your minimum SDK version specified in your
- application manifest is set to a higher value, this value is ignored and the target value is set
- to the minimum SDK version.</li>
- <li>{@code renderscript.support.mode} - Specifies that the generated bytecode should fall
- back to a compatible version if the device it is running on does not support the target version.
- </li>
- <li>{@code sdk.buildtools} - The version of the Android SDK build tools to use. This value
- should be set to {@code 18.1.0} or higher. If this option is not specified, the highest
- installed build tools version is used. You should always set this value to ensure the
- consistency of builds across development machines with different configurations.</li>
-</ul>
-
+ </0l>
<h2 id="using-rs-from-java">Using RenderScript from Java Code</h2>
diff --git a/docs/html/sdk/index.jd b/docs/html/sdk/index.jd
index 5a03197..cc1796e 100644
--- a/docs/html/sdk/index.jd
+++ b/docs/html/sdk/index.jd
@@ -4,29 +4,28 @@
header.hide=1
page.metaDescription=Download the official Android IDE and developer tools to build apps for Android phones, tablets, wearables, TVs, and more.
-studio.version=1.2.0.12
+studio.version=1.2.1.1
-studio.linux_bundle_download=android-studio-ide-141.1890965-linux.zip
-studio.linux_bundle_bytes=259139652
-studio.linux_bundle_checksum=72149f65911ca18d8f0d360e6b7a1e2dc57e9935
+studio.linux_bundle_download=android-studio-ide-141.1903250-linux.zip
+studio.linux_bundle_bytes=258634089
+studio.linux_bundle_checksum=61f576a24ac9aa00d498bb62942c028ef4a8905b
-studio.mac_bundle_download=android-studio-ide-141.1890965-mac.dmg
+studio.mac_bundle_download=android-studio-ide-141.1903250-mac.dmg
studio.mac_bundle_bytes=260877150
-studio.mac_bundle_checksum=06fe5a2d9ab6c99bf42fb2014e519a073fc7e90d
+studio.mac_bundle_checksum=a5a6ba50e3590de0973230a238d17726a1d9395c
-studio.win_bundle_download=android-studio-ide-141.1890965-windows.zip
-studio.win_bundle_bytes=261548058
-studio.win_bundle_checksum=29416e54ad074881a1e668e61e3d0c2316108dbe
+studio.win_bundle_download=android-studio-ide-141.1903250-windows.zip
+studio.win_bundle_bytes=261042465
+studio.win_bundle_checksum=ce924e0e4cff4b7f24df3f7ce0c1ce2379347d72
-studio.win_bundle_exe_download=android-studio-bundle-141.1890965-windows.exe
-studio.win_bundle_exe_bytes=928285584
-studio.win_bundle_exe_checksum=47be67749409f0d710c05b9a8f22d9191c47a9d0
+studio.win_bundle_exe_download=android-studio-bundle-141.1903250-windows.exe
+studio.win_bundle_exe_bytes=930462136
+studio.win_bundle_exe_checksum=680668b6b4a51c519efda814b96c2b61541a50f2
-studio.win_notools_exe_download=android-studio-ide-141.1890965-windows.exe
-studio.win_notools_exe_bytes=243621072
-studio.win_notools_exe_checksum=760d45212bea42f52adb1cbeab2390156d49c74d
-
+studio.win_notools_exe_download=android-studio-ide-141.1903250-windows.exe
+studio.win_notools_exe_bytes=243747312
+studio.win_notools_exe_checksum=d89917dd044e0559c87d6a05d49780ab110269f7
diff --git a/docs/html/tools/debugging/ddms.jd b/docs/html/tools/debugging/ddms.jd
index 1b59875..5822e27 100644
--- a/docs/html/tools/debugging/ddms.jd
+++ b/docs/html/tools/debugging/ddms.jd
@@ -204,6 +204,10 @@
<li>Click the <strong>Start Method Profiling</strong> button.</li>
+ <li>In Android 4.4 and later, choose either trace-based profiling or sample-based profiling
+ with a specified sampling interval. For earlier versions of Android, only trace-based profiling
+ is available.</li>
+
<li>Interact with your application to start the methods that you want to profile.</li>
<li>Click the <strong>Stop Method Profiling</strong> button. DDMS stops profiling your
diff --git a/docs/html/tools/debugging/debugging-tracing.jd b/docs/html/tools/debugging/debugging-tracing.jd
index bd4afbc..fa5b4e1 100644
--- a/docs/html/tools/debugging/debugging-tracing.jd
+++ b/docs/html/tools/debugging/debugging-tracing.jd
@@ -127,7 +127,7 @@
{@link android.os.Debug#startMethodTracing() startMethodTracing()} methods. In the call, you
specify a base name for the trace files that the system generates. To stop tracing, call {@link
android.os.Debug#stopMethodTracing() stopMethodTracing()}. These methods start and stop method
- tracing across the entire virtual machine. For example, you could call
+ tracing across the entire virtual machine. For example, you could call
{@link android.os.Debug#startMethodTracing() startMethodTracing()} in
your activity's {@link android.app.Activity#onCreate onCreate()} method, and call
{@link android.os.Debug#stopMethodTracing() stopMethodTracing()} in that activity's
@@ -157,6 +157,13 @@
times are only useful in relation to other profile output, so you can see if changes have made
the code faster or slower relative to a previous profiling run.</p>
+ <p>In Android 4.4 and later, you can use sample-based profiling to profile with less runtime
+ performance impact. To enable sample profiling, call {@link
+ android.os.Debug#startMethodTracingSampling(java.lang.String, int, int)
+ startMethodTracingSampling()} with a specified sampling interval. The system will then gather
+ samples periodically until tracing is stopped via {@link android.os.Debug#stopMethodTracing()
+ stopMethodTracing()}.</p>
+
<h2 id="copyingfiles">Copying Trace Files to a Host Machine</h2>
<p>After your application has run and the system has created your trace files
@@ -277,7 +284,8 @@
Traceview logging does not handle threads well, resulting in these two problems:
<ol>
- <li>If a thread exits during profiling, the thread name is not emitted;</li>
+ <li>If a thread exits during profiling, the thread name is not emitted (fixed in Android 5.1
+ and later);</li>
<li>The VM reuses thread IDs. If a thread stops and another starts, they may get the same
ID.</li>
diff --git a/docs/html/tools/revisions/studio.jd b/docs/html/tools/revisions/studio.jd
index f530a5f2..7138efe 100644
--- a/docs/html/tools/revisions/studio.jd
+++ b/docs/html/tools/revisions/studio.jd
@@ -43,6 +43,21 @@
<div class="toggle-content opened">
<p><a href="#" onclick="return toggleContent(this)">
<img src="{@docRoot}assets/images/triangle-opened.png" class="toggle-content-img"
+ alt=""/>Android Studio v1.2.1</a> <em>(May 2015)</em>
+ </p>
+ <div class="toggle-content-toggleme">
+ <p>Various fixes and enhancements:</p>
+ <ul>
+ <li>Fixed minor performance and feature issues. </li>
+ </ul>
+ </div>
+</div>
+
+
+
+<div class="toggle-content closed">
+ <p><a href="#" onclick="return toggleContent(this)">
+ <img src="{@docRoot}assets/images/triangle-closed.png" class="toggle-content-img"
alt=""/>Android Studio v1.2.0</a> <em>(April 2015)</em>
</p>
diff --git a/docs/html/tools/sdk/ndk/index.jd b/docs/html/tools/sdk/ndk/index.jd
index 520fe67..ae15bc1 100644
--- a/docs/html/tools/sdk/ndk/index.jd
+++ b/docs/html/tools/sdk/ndk/index.jd
@@ -2,29 +2,25 @@
page.template=sdk
-ndk.mac64_download=android-ndk-r10d-darwin-x86_64.bin
-ndk.mac64_bytes=442691567
-ndk.mac64_checksum=cb101e1e62d56ea75b215f6bc6c27fae
+ndk.mac64_download=android-ndk-r10e-darwin-x86_64.bin
+ndk.mac64_bytes=388937326
+ndk.mac64_checksum=2cb8893a5701603519d38a7e04c50e81
-ndk.mac32_download=android-ndk-r10d-darwin-x86.bin
-ndk.mac32_bytes=441545213
-ndk.mac32_checksum=0aeb3dc062dc457a4cd01e72eadb2379
+ndk.linux64_download=android-ndk-r10e-linux-x86_64.bin
+ndk.linux64_bytes=401522849
+ndk.linux64_checksum=19af543b068bdb7f27787c2bc69aba7f
-ndk.linux64_download=android-ndk-r10d-linux-x86_64.bin
-ndk.linux64_bytes=459151600
-ndk.linux64_checksum=263b83071e6bca15f67898548d8d236e
+ndk.linux32_download=android-ndk-r10e-linux-x86.bin
+ndk.linux32_bytes=394281908
+ndk.linux32_checksum=c3edd3273029da1cbd2f62c48249e978
-ndk.linux32_download=android-ndk-r10d-linux-x86.bin
-ndk.linux32_bytes=449997190
-ndk.linux32_checksum=70ed6d8c34e7e620c145b791e8eeef89
+ndk.win64_download=android-ndk-r10e-windows-x86_64.exe
+ndk.win64_bytes=419616132
+ndk.win64_checksum=8412bb4991a95e08fda50b5a44d95df7
-ndk.win64_download=android-ndk-r10d-windows-x86_64.exe
-ndk.win64_bytes=472613732
-ndk.win64_checksum=9a33f96da58a7e0b70e47d27b4a880b4
-
-ndk.win32_download=android-ndk-r10d-windows-x86.exe
-ndk.win32_bytes=455427281
-ndk.win32_checksum=c0930abfae0c990c4d191cc4ebd46b68
+ndk.win32_download=android-ndk-r10e-windows-x86.exe
+ndk.win32_bytes=396563176
+ndk.win32_checksum=1a82445baaf62aec3a46386ab1e5772c
@@ -382,11 +378,174 @@
<p>The following sections provide information about releases of the NDK.</p>
-
<div class="toggle-content opened">
<p>
<a href="#" onclick="return toggleContent(this)"> <img
src="/assets/images/triangle-opened.png" class="toggle-content-img" alt=""
+ >Android NDK, Revision 10e</a> <em>(May 2015)</em>
+ </p>
+ <div class="toggle-content-toggleme">
+ <dl>
+ <dt>Important changes:</dt>
+ <dd>
+ <ul>
+ <li>Integrated the workaround for Cortex-A53 Erratum 843419 into the
+ {@code aarch64-linux-android-4.9} linker. For more information on this workaround, see
+ <a href="https://sourceware.org/ml/binutils/2015-03/msg00446.html">Workaround for cortex-a53
+ erratum 843419.</a></li>
+
+ <li>Added Clang 3.6; {@code NDK_TOOLCHAIN_VERSION=clang} now picks that version
+ of Clang by default.</li>
+
+ <li>Removed Clang 3.4.</li>
+
+ <li>Removed GCC 4.6.</li>
+
+ <li>Implemented multithreading support in {@code ld.gold} for all architectures. It can
+ now link with or without support for multithreading; the default is to do it without.
+ <ul>
+ <li>To compile with multithreading, use the {@code --threads} option.</li>
+ <li>To compile without multithreading, use the {@code --no-threads} option.</li>
+ </ul>
+ </li>
+
+ <li>Upgraded GDB/gdbserver to 7.7 for all architectures.</li>
+
+ <li>Removed the NDK package for 32-bit Darwin.</li>
+ </ul>
+ </dd>
+ <dl>
+
+
+ <dt>Important bug fixes:</dt>
+ <dd>
+ <ul>
+ <li>Fixed a crash that occurred when there were OpenMP loops outside of the main thread.</li>
+
+ <li>Fixed a GCC 4.9 internal compiler error (<i>ICE</i>) that occured when the user declared
+ {@code #pragma GCC optimize ("O0")}, but had a different level of optimization specified
+ on the command line. The {@code pragma} takes precedence.</li>
+
+ <li>Fixed an error that used to produce a crash with the following error message:
+<pre>
+in add_stores, at var-tracking.c:6000
+</pre>
+ </li>
+
+ <li>Implemented a workaround for a Clang 3.5 issue in which LLVM auto-vectorization
+ generates {@code llvm.cttz.v2i64()}, an instruction with no counterpart in the ARM
+ instruction set.</li>
+ </ul>
+ </dd>
+
+ <dt>Other bug fixes:</dt>
+ <dd>
+ <ul>
+ <li>Made the following header and library fixes:</li>
+ <ul>
+ <li>Fixed {@code PROPERTY_*} in {@code media/NdkMediaDrm.h}.</li>
+ <li>Fixed {@code sys/ucontext.h} for {@code mips64}.</li>
+ <li>Dropped the Clang version check for {@code __builtin_isnan} and
+ {@code __builtin_isinf}.</li>
+ <li>Added {@code android-21/arch-mips/usr/include/asm/reg.h}
+ and {@code android-21/arch-mips64/usr/include/asm/reg.h}.</li>
+ </ul>
+ </li>
+
+ <li>Fixed a spurious array-bounds warning that GCC 4.9 produced for x86, and reenabled the
+ array bounds warning that GCC 4.9 had produced for ARM. The warning for ARM had
+ previously been unconditionally disabled.</li>
+
+ <li>Fixed Clang 3.5 for {@code mips} and {@code mips64} to create a writable
+ {@code .gcc_except_table} section, thus matching GCC behavior. This change allows you
+ to avoid the following linker warning:
+
+<pre>
+.../ld: warning: creating a DT_TEXTREL in a shared object
+</pre>
+ </li>
+
+ <li>Backported a fix for {@code compiler-rt} issues that were causing crashes when Clang
+ compiled for {@code mips64}. For more information, see LLVM Issue
+ <a href="http://llvm.org/bugs/show_bug.cgi?id=20098">20098</a>.</li>
+
+ <li>Fixed Clang 3.5 crashes that occurred on non-ASCII comments. (Issue
+ <a href="https://code.google.com/p/android/issues/detail?id=81440">81440</a>)</li>
+
+ <li>Fixed {@code stlport collate::compare} to return {@code -1} and {@code 1}. Previously,
+ it had returned arbitrary signed numbers.</li>
+
+ <li>Fixed {@code ndk-gdb} for 64-bit ABIs. (Issue
+ <a href="https://code.google.com/p/android/issues/detail?id=118300">118300</a>)</li>
+
+ <li>Fixed the crash that the HelloComputeNDK sample for RenderScript was producing on
+ Android 4.4 (Android API level 19). For more information, see
+ <a href="http://stackoverflow.com/questions/28057049/targeting-pre-lollipop-devices-using-renderscript-from-ndk-c">this page</a>.</li>
+
+ <li>Fixed {@code libc++ __wrap_iter} for GCC. For more information, see LLVM Issue
+ <a href="http://llvm.org/bugs/show_bug.cgi?id=22355">22355</a>.</li>
+
+ <li>Fixed {@code .asm} support for ABI {@code x86_64}.</li>
+
+ <li>Implemented a workaround for the GCC 4.8 {@code stlport} issue. (Issue
+ <a href="https://android-review.googlesource.com/#/c/127773">127773</a>)</li>
+
+ <li>Removed the trailing directory separator {@code \\} from the project path in Windows.
+ (Issue <a href="https://code.google.com/p/android/issues/detail?id=160584">160584</a>)
+ </li>
+
+ <li>Fixed a {@code no rule to make target} error that occurred when compiling a single
+ {@code .c} file by executing the {@code ndk-build.cmd} command from {@code gradle}. (Issue
+ <a href="https://code.google.com/p/android/issues/detail?id=66937">66937</a>)</li>
+
+ <li>Added the {@code libatomic.a} and {@code libgomp.a} libraries that had been missing from
+ the following host toolchains:
+ <ul>
+ <li>{@code aarch64-linux-android-4.9}</li>
+ <li>{@code mips64el-linux-android-4.9}</li>
+ <li>{@code mipsel-linux-android-4.9}</li>
+ <li>{@code x86_64-4.9}</li>
+ </ul>
+ </ul>
+ </dd>
+
+ <dt>Other changes:</dt>
+ <dd>
+ <ul>
+ <li>Added {@code ld.gold} for {@code aarch64}. The default linker remains {@code ld.bfd}.
+ To explicitly enable {@code ld.gold}, add {@code -fuse-ld=gold} to the
+ {@code LOCAL_LDFLAGS} or {@code APP_LDFLAGS} variable.</li>
+
+ <li>Built the MIPS and MIPS64 toolchains with {@code binutils-2.25}, which provides improved
+ R6 support.</li>
+
+ <li>Made {@code -fstandalone-debug} (full debug info) a default option for Clang.</li>
+
+ <li>Replaced {@code -fstack-protector} with {@code -fstack-protector-strong} for
+ the ARM, AArch64, X86, and X86_64 toolchains for GCC 4.9, Clang 3.5, and
+ Clang 3.6.</li>
+
+ <li>Added the {@code --package} command-line switch to {@code ndk-gdb} to allow the build
+ system to override the package name. (Issue
+ <a href="https://code.google.com/p/android/issues/detail?id=56189">56189</a>)</li>
+
+ <li> Deprecated {@code -mno-ldc1-stc1} for MIPS. This option may not work with the new
+ {@code -fpxx} and {@code -mno-odd-spreg} options, or with the FPXX ABI.</li>
+
+ <li>Added MIPS MSA and R6 detection to {@code cpu-features}.</li>
+
+ </ul>
+ </dd>
+
+ </dl>
+ </div>
+</div>
+
+
+<div class="toggle-content closed">
+ <p>
+ <a href="#" onclick="return toggleContent(this)"> <img
+ src="/assets/images/triangle-closed.png" class="toggle-content-img" alt=""
>Android NDK, Revision 10d</a> <em>(December 2014)</em>
</p>
<div class="toggle-content-toggleme">
diff --git a/docs/html/tools/support-library/features.jd b/docs/html/tools/support-library/features.jd
index ee1ed72..573baad 100644
--- a/docs/html/tools/support-library/features.jd
+++ b/docs/html/tools/support-library/features.jd
@@ -373,9 +373,8 @@
developer guide.</p>
<p class="note">
- <strong>Note:</strong> Use of RenderScript with the support library is supported with the Android
- Eclipse plugin and Ant build tools. It is <em>not currently</em> supported with Android Studio or
- Gradle-based builds.
+ <strong>Note:</strong> Use of RenderScript with the support library is supported with Android
+ Studio and Gradle-based builds, as well as the Eclipse plugin and Ant build tools.
</p>
diff --git a/docs/html/training/testing/ui-testing/index.jd b/docs/html/training/testing/ui-testing/index.jd
index 20422f7..d660c60 100644
--- a/docs/html/training/testing/ui-testing/index.jd
+++ b/docs/html/training/testing/ui-testing/index.jd
@@ -72,5 +72,5 @@
<dd>Learn how to test UI in a single app by using the Espresso testing framework.</dd>
<dt><strong><a href="uiautomator-testing.html">
Testing UI for Multiple Apps</a></strong></dt>
- <dd>Learn how to test UI in multiple apps by using the UI Automator testing framework</dd>
+ <dd>Learn how to test UI in multiple apps by using the UI Automator testing framework.</dd>
</dl>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/index.jd b/docs/html/training/testing/unit-testing/index.jd
new file mode 100644
index 0000000..a35ba80
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/index.jd
@@ -0,0 +1,63 @@
+page.title=Building Effective Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test
+
+trainingnavtop=true
+startpage=true
+
+@jd:body
+
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>
+ You should also read
+ </h2>
+ <ul>
+ <li>
+ <a href="{@docRoot}tools/testing-support-library/index.html">Testing Support Library</a>
+ </li>
+ </ul>
+</div>
+</div>
+
+<p>Unit tests are the fundamental tests in your app testing strategy. By creating and running unit
+tests against your code, you can easily verify that the logic of individual units is correct.
+Running unit tests after every build helps you to
+quickly catch and fix software regressions introduced by code changes to your app.
+</p>
+
+<p>A unit test generally exercises the functionality of the smallest possible unit of code (which
+could be a method, class, or component) in a repeatable way. You should build unit tests when you
+need to verify the logic of specific code in your app. For example, if you are unit testing a
+class, your test might check that the class is in the right state. Typically, the unit of code
+is tested in isolation; your test affects and monitors changes to that unit only. A
+<a href="http://en.wikipedia.org/wiki/Mock_object" class="external-link">mocking framework</a>
+can be used to isolate your unit from its dependencies.</p>
+
+<p class="note"><strong>Note:</strong> Unit tests are not suitable for testing
+complex UI interaction events. Instead, you should use the UI testing frameworks, as described in
+<a href="{@docRoot}training/testing/ui-testing/index.html">Automating UI Tests</a>.</p>
+
+<p>For testing Android apps, you typically create these types of automated unit tests:</p>
+
+<ul>
+<li><strong>Local tests:</strong> Unit tests that run on your local machine only. These tests are
+compiled to run locally on the Java Virtual Machine (JVM) to minimize execution time. Use this
+approach to run unit tests that have no dependencies on the Android framework or have dependencies
+that can be filled by using mock objects.</li>
+<li><strong>Instrumented tests:</strong> Unit tests that run on an Android device or emulator.
+These tests have access to instrumentation information, such as the
+{@link android.content.Context} for the app under test. Use this approach to run unit tests that
+have Android dependencies which cannot be easily filled by using mock objects.</li>
+</ul>
+
+<p>The lessons in this class teach you how to build these types of automated unit tests.</p>
+
+<h2>Lessons</h2>
+<dl>
+ <dt><strong><a href="local-unit-tests.html">
+Building Local Unit Tests</a></strong></dt>
+ <dd>Learn how to build unit tests that run on your local machine.</dd>
+ <dt><strong><a href="instrumented-unit-tests.html">
+Building Instrumented Unit Tests</a></strong></dt>
+ <dd>Learn how to build unit tests that run on an Android device or emulator.</dd>
+</dl>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
new file mode 100644
index 0000000..07f0f739
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/instrumented-unit-tests.jd
@@ -0,0 +1,250 @@
+page.title=Building Instrumented Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test,mock,instrumentation
+trainingnavtop=true
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>Dependencies and Prerequisites</h2>
+
+ <ul>
+ <li>Android 2.2 (API level 8) or higher</li>
+ <li><a href="{@docRoot}tools/testing-support-library/index.html">
+ Android Testing Support Library</a></li>
+ </ul>
+
+ <h2>This lesson teaches you to</h2>
+
+ <ol>
+ <li><a href="#setup">Set Up Your Testing Environment</a></li>
+ <li><a href="#build">Create a Instrumented Unit Test Class</a></li>
+ <li><a href="#run">Run Instrumented Unit Tests</a></li>
+ </ol>
+
+ <h2>Try it out</h2>
+
+ <ul>
+ <li>
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicUnitAndroidTest"
+class="external-link">Instrumented Unit Tests Code Samples</a></li>
+ </ul>
+</div>
+</div>
+
+<p>
+Instrumented unit tests are unit tests that run on physical devices and emulators, instead of
+the Java Virtual Machine (JVM) on your local machine. You should create instrumented unit tests
+if your tests need access to instrumentation information (such as the target app's
+{@link android.content.Context}) or if they require the real implementation of an Android framework
+component (such as a {@link android.os.Parcelable} or {@link android.content.SharedPreferences}
+object). Using instrumented unit tests also helps to reduce the effort required to write and
+maintain mock code. You are still free to use a mocking framework, if you choose, to simulate any
+dependency relationships. Instrumented unit tests can take advantage of the Android framework APIs
+and supporting APIs, such as the Android Testing Support Library.
+</p>
+
+<h2 id="setup">Set Up Your Testing Environment</h2>
+<p>Before building instrumented unit tests, you must:</p>
+
+ <ul>
+ <li>
+ <strong>Install the Android Testing Support Library</strong>. The
+ <a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+ {@code AndroidJUnitRunner}</a> API, located under the
+ {@code com.android.support.test.runner} package, allows you to
+ create and run instrumented unit tests. To learn how to install the
+ library, see <a href="{@docRoot}tools/testing-support-library/index.html#setup">
+ Testing Support Library Setup</a>.
+ </li>
+
+ <li>
+ <strong>Set up your project structure.</strong> In your Gradle project, the source code for
+ the target app that you want to test is typically placed under the {@code app/src/main/java}
+ folder. The source code for instrumentatation tests, including your unit tests, must be
+ placed under the <code>app/src/androidTest/java</code> folder.
+ To learn more about setting up your project directory, see
+ <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
+ </li>
+
+ <li>
+ <strong>Specify your Android testing dependencies</strong>. In order for the
+ <a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a> to
+ correctly build and run your instrumented unit tests, you must specify the following
+ libraries in the {@code build.gradle} file of your Android app module:
+
+ <pre>
+dependencies {
+ androidTestCompile 'com.android.support.test:runner:0.2'
+ androidTestCompile 'com.android.support.test:rules:0.2'
+ // Set this dependency if you want to use Hamcrest matching
+ androidTestCompile 'org.hamcrest:hamcrest-library:1.1'
+}
+</pre>
+ </li>
+ </ul>
+
+<h2 id="build">Create an Instrumented Unit Test Class</h2>
+<p>
+Your instrumented unit test class should be written as a JUnit 4 test class. To learn more about
+creating JUnit 4 test classes and using JUnit 4 assertions and annotations, see
+<a href="local-unit-tests.html#build">Create a Local Unit Test Class</a>.
+</p>
+<p>To create an instrumented JUnit 4 test class, add the {@code @RunWith(AndroidJUnit4.class)}
+annotation at the beginning of your test class definition. You also need to specify the
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> class
+provided in the Android Testing Support Library as your default test runner. This step is described
+in more detail in <a href="#run">Run Instrumented Unit Tests</a>.
+</p>
+
+<p>The following example shows how you might write an instrumented unit test to test that
+the {@link android.os.Parcelable} interface is implemented correctly for the
+{@code LogHistory} class:</p>
+
+<pre>
+import android.os.Parcel;
+import android.support.test.runner.AndroidJUnit4;
+import android.util.Pair;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import java.util.List;
+import static org.hamcrest.Matchers.is;
+import static org.junit.Assert.assertThat;
+
+@RunWith(AndroidJUnit4.class)
+public class LogHistoryAndroidUnitTest {
+
+ public static final String TEST_STRING = "This is a string";
+ public static final long TEST_LONG = 12345678L;
+ private LogHistory mLogHistory;
+
+ @Before
+ public void createLogHistory() {
+ mLogHistory = new LogHistory();
+ }
+
+ @Test
+ public void logHistory_ParcelableWriteRead() {
+ // Set up the Parcelable object to send and receive.
+ mLogHistory.addEntry(TEST_STRING, TEST_LONG);
+
+ // Write the data.
+ Parcel parcel = Parcel.obtain();
+ mLogHistory.writeToParcel(parcel, mLogHistory.describeContents());
+
+ // After you're done with writing, you need to reset the parcel for reading.
+ parcel.setDataPosition(0);
+
+ // Read the data.
+ LogHistory createdFromParcel = LogHistory.CREATOR.createFromParcel(parcel);
+ List<Pair<String, Long>> createdFromParcelData = createdFromParcel.getData();
+
+ // Verify that the received data is correct.
+ assertThat(createdFromParcelData.size(), is(1));
+ assertThat(createdFromParcelData.get(0).first, is(TEST_STRING));
+ assertThat(createdFromParcelData.get(0).second, is(TEST_LONG));
+ }
+}
+</pre>
+
+<h3 id="test-suites">Creating a test suite</h3>
+<p>
+To organize the execution of your instrumented unit tests, you can group a collection of test
+classes in a <em>test suite</em> class and run these tests together. Test suites can be nested;
+your test suite can group other test suites and run all their component test classes together.
+</p>
+
+<p>
+A test suite is contained in a test package, similar to the main application package. By
+convention, the test suite package name usually ends with the {@code .suite} suffix (for example,
+{@code com.example.android.testing.mysample.suite}).
+</p>
+
+<p>
+To create a test suite for your unit tests, import the JUnit
+<a href="http://junit.sourceforge.net/javadoc/org/junit/runner/RunWith.html"
+class="external-link">{@code RunWith}</a> and
+<a href="http://junit.sourceforge.net/javadoc/org/junit/runners/Suite.html"
+class="external-link">{@code Suite}</a> classes. In your test suite, add the
+{@code @RunWith(Suite.class)} and the {@code @Suite.SuitClasses()} annotations. In
+the {@code @Suite.SuiteClasses()} annotation, list the individual test classes or test
+suites as arguments.
+</p>
+
+<p>
+The following example shows how you might implement a test suite called {@code UnitTestSuite}
+that groups and runs the {@code CalculatorInstrumentationTest} and
+{@code CalculatorAddParameterizedTest} test classes together.
+</p>
+
+<pre>
+import com.example.android.testing.mysample.CalculatorAddParameterizedTest;
+import com.example.android.testing.mysample.CalculatorInstrumentationTest;
+import org.junit.runner.RunWith;
+import org.junit.runners.Suite;
+
+// Runs all unit tests.
+@RunWith(Suite.class)
+@Suite.SuiteClasses({CalculatorInstrumentationTest.class,
+ CalculatorAddParameterizedTest.class})
+public class UnitTestSuite {}
+</pre>
+
+<h2 id="run">Run Instrumented Unit Tests</h2>
+<p>
+The
+<a href="https://developer.android.com/tools/building/plugin-for-gradle.html">
+ Android Plug-in for Gradle</a>
+provides a default directory ({@code src/androidTest/java}) for you to store the instrumented unit
+and integration test classes and test suites that you want to run on a device. The plug-in compiles
+the test code in that directory and then executes the test app using a test runner class. You must
+set the
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> class provided in the
+<a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>
+as your default test runner.</p>
+</p>
+
+<p>To specify
+<a href="{@docRoot}reference/android/support/test/runner/AndroidJUnitRunner.html">
+{@code AndroidJUnitRunner}</a> as the default test instrumentation runner, add the following
+setting in your {@code build.gradle} file:</p>
+<pre>
+android {
+ defaultConfig {
+ testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
+ }
+}
+</pre>
+
+<h3 id="run-from-Android-Studio">Running instrumented unit tests from Android Studio</h3>
+<p>
+To run instrumented unit tests in your Gradle project from Android Studio:
+</p>
+<ol>
+<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then set the
+test artifact to <em>Android Instrumentation Tests</em>.
+</li>
+<li>In the <strong>Project</strong> window, drill down to your unit test class or method, then
+ right-click and run it using the Android Test configuration.
+</li>
+</ol>
+
+<p>Android Studio displays the results of the unit test execution in the <strong>Run</strong>
+window.</p>
+
+<h3 id="run-from-commandline">Running instrumented unit tests from the command-line</h3>
+
+<p>To run instrumented unit tests in your Gradle project from the command-line, call the
+ {@code connectedCheck} (or {@code cC}) task:</p>
+
+<pre>
+./gradlew cC
+</pre>
+
+<p>You can find the generated HTML test result reports in the
+{@code <path_to_your_project>/app/build/outputs/reports/androidTests/connected/} directory,
+and the corresponding XML files in the
+{@code <path_to_your_project>/app/build/outputs/androidTest-results/connected/} directory.</p>
\ No newline at end of file
diff --git a/docs/html/training/testing/unit-testing/local-unit-tests.jd b/docs/html/training/testing/unit-testing/local-unit-tests.jd
new file mode 100644
index 0000000..421709b
--- /dev/null
+++ b/docs/html/training/testing/unit-testing/local-unit-tests.jd
@@ -0,0 +1,302 @@
+page.title=Building Local Unit Tests
+page.tags=testing,androidjunitrunner,junit,unit test,mock
+trainingnavtop=true
+
+@jd:body
+
+<!-- This is the training bar -->
+<div id="tb-wrapper">
+<div id="tb">
+ <h2>Dependencies and Prerequisites</h2>
+
+ <ul>
+ <li>Android Plug-in for Gradle 1.1.0 or higher</li>
+ </ul>
+
+ <h2>This lesson teaches you to</h2>
+
+ <ol>
+ <li><a href="#setup">Set Up Your Testing Environment</a></li>
+ <li><a href="#build">Create a Local Unit Test Class</a></li>
+ <li><a href="#run">Run Local Unit Tests</a></li>
+ </ol>
+
+ <h2>Try it out</h2>
+
+ <ul>
+ <li>
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicSample"
+class="external-link">Local Unit Tests Code Samples</a></li>
+ </ul>
+</div>
+</div>
+
+<p>If your unit test has no dependencies or only has simple dependencies on Android, you should run
+your test on a local development machine. This testing approach is efficient because it helps
+you avoid the overhead of loading the target app and unit test code onto a physical device or
+emulator every time your test is run. Consequently, the execution time for running your unit
+test is greatly reduced. With this approach, you normally use a mocking framework, like
+<a href="https://code.google.com/p/mockito/" class="external-link">Mockito</a>, to fulfill any
+dependency relationships.</p>
+
+<p><a href="{@docRoot}tools/building/plugin-for-gradle.html">Android Plug-in for Gradle</a>
+version 1.1.0 and higher allows you to create a source directory ({@code src/test/java}) in your
+project to store JUnit tests that you want to run on a local machine. This feature improves your
+project organization by letting you group your unit tests together into a single source set. You
+can run the tests from Android Studio or the command-line, and the plugin executes them on the
+local Java Virtual Machine (JVM) on your development machine. </p>
+
+<h2 id="setup">Set Up Your Testing Environment</h2>
+<p>Before building local unit tests, you must:</p>
+
+ <ul>
+ <li>
+ <strong>Set up your project structure.</strong> In your Gradle project, the source code for
+ the target app that you want to test is typically placed under the {@code app/src/main/java}
+ folder. The source code for your local unit tests must be placed under the
+ <code>app/src/test/java</code> folder.
+ To learn more about setting up your project directory, see
+ <a href="#run">Run Local Unit Tests</a> and
+ <a href="{@docRoot}tools/projects/index.html">Managing Projects</a>.
+ </li>
+
+ <li>
+ <strong>Specify your Android testing dependencies</strong>. In order to use JUnit 4 and
+ Mockito with your local unit tests, specify the following libraries in
+ the {@code build.gradle} file of your Android app module:
+
+ <pre>
+dependencies {
+ // Unit testing dependencies
+ testCompile 'junit:junit:4.12'
+ // Set this dependency if you want to use Mockito
+ testCompile 'org.mockito:mockito-core:1.10.19'
+ // Set this dependency if you want to use Hamcrest matching
+ androidTestCompile 'org.hamcrest:hamcrest-library:1.1'
+}
+</pre>
+ </li>
+ </ul>
+
+<h2 id="build">Create a Local Unit Test Class</h2>
+<p>Your local unit test class should be written as a JUnit 4 test class.
+<a href="http://junit.org/" class="external-link">JUnit</a> is the most popular
+and widely-used unit testing framework for Java. The latest version of this framework, JUnit 4,
+allows you to write tests in a cleaner and more flexible way than its predecessor versions. Unlike
+the previous approach to Android unit testing based on JUnit 3, with JUnit 4, you do not need to
+extend the {@code junit.framework.TestCase} class. You also do not need to prefix your test method
+name with the {@code ‘test’} keyword, or use any classes in the {@code junit.framework} or
+{@code junit.extensions} package.</p>
+
+<p>To create a basic JUnit 4 test class, create a Java class that contains one or more test methods.
+A test method begins with the {@code @Test} annotation and contains the code to exercise
+and verify a single functionality in the component that you want to test.</p>
+
+<p>The following example shows how you might implement a local unit test class. The test method
+{@code emailValidator_CorrectEmailSimple_ReturnsTrue} verifies that the {@code isValidEmail()}
+method in the app under test returns the correct result.</p>
+
+<pre>
+import org.junit.Test;
+import java.util.regex.Pattern;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
+
+public class EmailValidatorTest {
+
+ @Test
+ public void emailValidator_CorrectEmailSimple_ReturnsTrue() {
+ assertThat(EmailValidator.isValidEmail("name@email.com"), is(true));
+ }
+ ...
+}
+</pre>
+
+<p>To test that components in your app return the expected results, use the
+<a href="http://junit.org/javadoc/latest/org/junit/Assert.html" class="external-link">
+junit.Assert</a> methods to perform validation checks (or <em>assertions</em>) to compare the state
+of the component under test against some expected value. To make tests more readable, you
+can use <a href="https://code.google.com/p/hamcrest/wiki/Tutorial" class="external-link">
+Hamcrest matchers</a> (such as the {@code is()} and {@code equalTo()} methods) to match the
+returned result against the expected result.</p>
+
+<p>In your JUnit 4 test class, you can use annotations to call out sections in your test code for
+special processing, such as:</p>
+
+<ul>
+<li>
+{@code @Before}: Use this annotation to specify a block of code with test setup operations. This
+code block will be invoked before each test. You can have multiple {@code @Before} methods but
+the order which these methods are called is not fixed.
+</li>
+<li>
+{@code @After}: This annotation specifies a block of code with test tear-down operations. This
+code block will be called after every test method. You can define multiple {@code @After}
+operations in your test code. Use this annotation to release any resources from memory.
+</li>
+<li>
+{@code @Test}: Use this annotation to mark a test method. A single test class can contain
+multiple test methods, each prefixed with this annotation.
+</li>
+<li>
+{@code @BeforeClass}: Use this annotation to specify static methods to be invoked only once per
+test class. This testing step is useful for expensive operations such as connecting to a database.
+</li>
+<li>
+{@code @AfterClass}: Use this annotation to specify static methods to be invoked only after all
+tests in the class have been run. This testing step is useful for releasing any resources allocated
+in the {@code @BeforeClass} block.
+</li>
+<li>
+{@code @Test(timeout=<milliseconds>)}: Specifies a timeout period for the test. If the
+test starts but does not complete within the given timeout period, it automatically fails. You must
+specify the timeout period in milliseconds, for example: {@code @Test(timeout=5000)}.
+</li>
+</ul>
+
+<h3 id="mocking-dependencies">Mocking Android dependencies</h3>
+<p>
+By default, the <a href="{@docRoot}tools/building/plugin-for-gradle.html">
+Android Plug-in for Gradle</a> executes your local unit tests against a modified
+version of the {@code android.jar} library, which does not contain any actual code. Instead, method
+calls to Android classes from your unit test throw an exception.
+</p>
+<p>
+You can use a mocking framework to stub out external dependencies in your code, to easily test that
+your component interacts with a dependency in an expected way. By substituting Android dependencies
+with mock objects, you can isolate your unit test from the rest of the Android system while
+verifying that the correct methods in those dependencies are called. The
+<a href="https://code.google.com/p/mockito/" class="external-link">Mockito</a> mocking framework
+for Java (version 1.9.5 and higher) offers compatibility with Android unit testing.
+With Mockito, you can configure mock objects to return some specific value when invoked.</p>
+
+<p>To add a mock object to your local unit test using this framework, follow this programming model:
+</p>
+
+<ol>
+<li>
+Include the Mockito library dependency in your {@code build.gradle} file, as described in
+<a href="#setup">Set Up Your Testing Environment</a>.
+</li>
+<li>At the beginning of your unit test class definition, add the
+{@code @RunWith(MockitoJUnitRunner.class)} annotation. This annotation tells the Mockito test
+runner to validate that your usage of the framework is correct and simplifies the initialization of
+your mock objects.
+</li>
+<li>To create a mock object for an Android dependency, add the {@code @Mock} annotation before
+the field declaration.</li>
+<li>To stub the behavior of the dependency, you can specify a condition and return
+value when the condition is met by using the {@code when()} and {@code thenReturn()} methods.
+</li>
+</ol>
+
+<p>
+The following example shows how you might create a unit test that uses a mock
+{@link android.content.Context} object.
+</p>
+
+<pre>
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.CoreMatchers.*;
+import static org.mockito.Mockito.*;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.mockito.Mock;
+import org.mockito.runners.MockitoJUnitRunner;
+import android.content.SharedPreferences;
+
+@RunWith(MockitoJUnitRunner.class)
+public class UnitTestSample {
+
+ private static final String FAKE_STRING = "HELLO WORLD";
+
+ @Mock
+ Context mMockContext;
+
+ @Test
+ public void readStringFromContext_LocalizedString() {
+ // Given a mocked Context injected into the object under test...
+ when(mMockContext.getString(R.string.hello_word))
+ .thenReturn(FAKE_STRING);
+ ClassUnderTest myObjectUnderTest = new ClassUnderTest(mMockContext);
+
+ // ...when the string is returned from the object under test...
+ String result = myObjectUnderTest.getHelloWorldString();
+
+ // ...then the result should be the expected one.
+ assertThat(result, is(FAKE_STRING));
+ }
+}
+</pre>
+
+<p>
+To learn more about using the Mockito framework, see the
+<a href="http://site.mockito.org/mockito/docs/current/org/mockito/Mockito.html"
+class="external-link">Mockito API reference</a> and the
+{@code SharedPreferencesHelperTest} class in the
+<a href="https://github.com/googlesamples/android-testing/tree/master/unittesting/BasicSample"
+class="external-link">sample code</a>.
+</p>
+
+<h2 id="run">Run Local Unit Tests</h2>
+<p>
+The Android Plug-in for Gradle provides a default directory ({@code src/test/java}) for you to
+store unit test classes that you want to run on a local JVM. The plug-in compiles the test code in
+that directory and then executes the test app locally using the default test runner class.
+</p>
+<p>
+As with production code, you can create unit tests for a
+<a href="http://developer.android.com/tools/building/configuring-gradle.html#workBuildVariants"
+class="external-link">specific flavor or build type</a>. You should keep unit tests in a test
+source tree location that corresponds to your production source tree, such as:
+
+<table>
+<tr>
+<th>Path to Production Class</th>
+<th>Path to Local Unit Test Class</th>
+</tr>
+<tr>
+<td>{@code src/main/java/Foo.java}</td>
+<td>{@code src/test/java/FooTest.java}</td>
+</tr>
+<tr>
+<td>{@code src/debug/java/Foo.java}</td>
+<td>{@code src/testDebug/java/FooTest.java}</td>
+</tr>
+<tr>
+<td>{@code src/myFlavor/java/Foo.java}</td>
+<td>{@code src/testMyFlavor/java/FooTest.java}</td>
+</tr>
+</table>
+
+<h3 id="run-from-Android-Studio">Running local unit tests from Android Studio</h3>
+<p>
+To run local unit tests in your Gradle project from Android Studio:
+</p>
+<ol>
+<li>In the <strong>Project</strong> window, right click on the project and synchronize your project.
+</li>
+<li>Open the <strong>Build Variants</strong> window by clicking the left-hand tab, then change the
+test artifact to <em>Unit Tests</em>.
+</li>
+<li>In the <strong>Project</strong> window, drill down to your unit test class or method, then
+right-click and run it.
+</li>
+</ol>
+
+<p>Android Studio displays the results of the unit test execution in the <strong>Run</strong>
+window.</p>
+
+<h3 id="run-from-commandline">Running local unit tests from the command-line</h3>
+
+<p>To run local unit tests in your Gradle project from the command-line, call the {@code test} task
+command with the {@code --continue} option.</p>
+
+<pre>
+./gradlew test --continue
+</pre>
+
+<p>If there are failing tests, the command will display links to HTML reports (one per build
+variant). You can find the generated HTML test result reports in the
+{@code <path_to_your_project>/app/build/reports/tests/} directory, and the corresponding XML
+files in the {@code <path_to_your_project>/app/build/test-results/} directory.</p>
\ No newline at end of file
diff --git a/docs/html/training/training_toc.cs b/docs/html/training/training_toc.cs
index 862663e..089739b 100644
--- a/docs/html/training/training_toc.cs
+++ b/docs/html/training/training_toc.cs
@@ -1875,6 +1875,24 @@
</ul>
</li>
</ul>
+ <ul>
+ <li class="nav-section">
+ <div class="nav-section-header"><a href="<?cs var:toroot ?>training/testing/unit-testing/index.html"
+ description="How to build effective unit tests for Android apps.">
+ Building Effective Unit Tests
+ </a></div>
+ <ul>
+ <li><a href="<?cs var:toroot ?>training/testing/unit-testing/local-unit-tests.html">
+ <span class="en">Building Local Unit Tests</span>
+ </a>
+ </li>
+ <li><a href="<?cs var:toroot ?>training/testing/unit-testing/instrumented-unit-tests.html">
+ <span class="en">Building Instrumented Unit Tests</span>
+ </a>
+ </li>
+ </ul>
+ </li>
+ </ul>
</li>
<!-- End best Testing -->