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/tools/support-library/features.jd b/docs/html/tools/support-library/features.jd
index 0f0a0c0..119d74a 100644
--- a/docs/html/tools/support-library/features.jd
+++ b/docs/html/tools/support-library/features.jd
@@ -370,9 +370,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 &#64;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;
+
+&#64;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;
+
+    &#64;Before
+    public void createLogHistory() {
+        mLogHistory = new LogHistory();
+    }
+
+    &#64;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&lt;Pair&lt;String, Long&gt;&gt; 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 &#64;RunWith(Suite.class)} and the {@code &#64;Suite.SuitClasses()} annotations. In
+the {@code &#64;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.
+&#64;RunWith(Suite.class)
+&#64;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 &lt;path_to_your_project&gt;/app/build/outputs/reports/androidTests/connected/} directory,
+and the corresponding XML files in the
+{@code &lt;path_to_your_project&gt;/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 &#64;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 {
+
+    &#64;Test
+    public void emailValidator_CorrectEmailSimple_ReturnsTrue() {
+        assertThat(EmailValidator.isValidEmail("name&#64;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 &#64;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 &#64;Before} methods but
+the order which these methods are called is not fixed.
+</li>
+<li>
+{@code &#64;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 &#64;After}
+operations in your test code. Use this annotation to release any resources from memory.
+</li>
+<li>
+{@code &#64;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 &#64;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 &#64;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 &#64;BeforeClass} block.
+</li>
+<li>
+{@code &#64;Test(timeout=&lt;milliseconds&gt;)}: 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 &#64;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 &#64;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 &#64;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;
+
+&#64;RunWith(MockitoJUnitRunner.class)
+public class UnitTestSample {
+
+    private static final String FAKE_STRING = "HELLO WORLD";
+
+    &#64;Mock
+    Context mMockContext;
+
+    &#64;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 &lt;path_to_your_project&gt;/app/build/reports/tests/} directory, and the corresponding XML
+files in the {@code &lt;path_to_your_project&gt;/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 -->