diff --git a/CMakeLists.txt b/CMakeLists.txt
index 8d2b552e..5754992e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -1,4 +1,4 @@
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 2.6.4)
 
 project( googletest-distribution )
 
diff --git a/googlemock/CMakeLists.txt b/googlemock/CMakeLists.txt
index beb259a2..9fb96a4b 100644
--- a/googlemock/CMakeLists.txt
+++ b/googlemock/CMakeLists.txt
@@ -38,7 +38,7 @@ endif()
 # ${gmock_BINARY_DIR}.
 # Language "C" is required for find_package(Threads).
 project(gmock CXX C)
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 2.6.4)
 
 if (COMMAND set_up_hermetic_build)
   set_up_hermetic_build()
diff --git a/googlemock/README.md b/googlemock/README.md
index 191df69f..3eb10cbb 100644
--- a/googlemock/README.md
+++ b/googlemock/README.md
@@ -125,6 +125,14 @@ build Google Mock and its tests, which has further requirements:
 
 ### Building Google Mock ###
 
+If you have CMake available, it is recommended that you follow the
+[build instructions][gtest_cmakebuild]
+as described for Google Test. If are using Google Mock with an
+existing CMake project, the section
+[Incorporating Into An Existing CMake Project][gtest_incorpcmake]
+may be of particular interest. Otherwise, the following sections
+detail how to build Google Mock without CMake.
+
 #### Preparing to Build (Unix only) ####
 
 If you are using a Unix system and plan to use the GNU Autotools build
@@ -331,3 +339,5 @@ patch.
 Happy testing!
 
 [gtest_readme]: ../googletest/README.md "googletest"
+[gtest_cmakebuild]:  ../googletest/README.md#using-cmake "Using CMake"
+[gtest_incorpcmake]: ../googletest/README.md#incorporating-into-an-existing-cmake-project "Incorporating Into An Existing CMake Project"
diff --git a/googlemock/docs/CookBook.md b/googlemock/docs/CookBook.md
index c52f1009..0460d357 100644
--- a/googlemock/docs/CookBook.md
+++ b/googlemock/docs/CookBook.md
@@ -218,7 +218,7 @@ per-function syntactic overhead will be much lower.
 
 If you are concerned about the performance overhead incurred by
 virtual functions, and profiling confirms your concern, you can
-combine this with the recipe for [mocking non-virtual methods](#Mocking_Nonvirtual_Methods.md).
+combine this with the recipe for [mocking non-virtual methods](#mocking-nonvirtual-methods).
 
 ## The Nice, the Strict, and the Naggy ##
 
diff --git a/googletest/CMakeLists.txt b/googletest/CMakeLists.txt
index 621d0f04..36d0a9ec 100644
--- a/googletest/CMakeLists.txt
+++ b/googletest/CMakeLists.txt
@@ -45,7 +45,7 @@ endif()
 # ${gtest_BINARY_DIR}.
 # Language "C" is required for find_package(Threads).
 project(gtest CXX C)
-cmake_minimum_required(VERSION 2.6.2)
+cmake_minimum_required(VERSION 2.6.4)
 
 if (COMMAND set_up_hermetic_build)
   set_up_hermetic_build()
diff --git a/googletest/README.md b/googletest/README.md
index edd44080..0a3474c0 100644
--- a/googletest/README.md
+++ b/googletest/README.md
@@ -59,7 +59,13 @@ cross-platform.). If you don't have CMake installed already, you can
 download it for free from <http://www.cmake.org/>.
 
 CMake works by generating native makefiles or build projects that can
-be used in the compiler environment of your choice.  The typical
+be used in the compiler environment of your choice.  You can either
+build Google Test as a standalone project or it can be incorporated
+into an existing CMake build for another project.
+
+#### Standalone CMake Project ####
+
+When building Google Test as a standalone project, the typical
 workflow starts with:
 
     mkdir mybuild       # Create a directory to hold the build output.
@@ -80,13 +86,110 @@ using Visual Studio.
 
 On Mac OS X with Xcode installed, a `.xcodeproj` file will be generated.
 
+#### Incorporating Into An Existing CMake Project ####
+
+If you want to use gtest in a project which already uses CMake, then a
+more robust and flexible approach is to build gtest as part of that
+project directly. This is done by making the GoogleTest source code
+available to the main build and adding it using CMake's
+`add_subdirectory()` command. This has the significant advantage that
+the same compiler and linker settings are used between gtest and the
+rest of your project, so issues associated with using incompatible
+libraries (eg debug/release), etc. are avoided. This is particularly
+useful on Windows. Making GoogleTest's source code available to the
+main build can be done a few different ways:
+
+* Download the GoogleTest source code manually and place it at a
+  known location. This is the least flexible approach and can make
+  it more difficult to use with continuous integration systems, etc.
+* Embed the GoogleTest source code as a direct copy in the main
+  project's source tree. This is often the simplest approach, but is
+  also the hardest to keep up to date. Some organizations may not
+  permit this method.
+* Add GoogleTest as a git submodule or equivalent. This may not
+  always be possible or appropriate. Git submodules, for example,
+  have their own set of advantages and drawbacks.
+* Use CMake to download GoogleTest as part of the build's configure
+  step. This is just a little more complex, but doesn't have the
+  limitations of the other methods.
+
+The last of the above methods is implemented with a small piece
+of CMake code in a separate file (e.g. `CMakeLists.txt.in`) which
+is copied to the build area and then invoked as a sub-build
+_during the CMake stage_. That directory is then pulled into the
+main build with `add_subdirectory()`. For example:
+
+New file `CMakeLists.txt.in`:
+
+    cmake_minimum_required(VERSION 2.8.2)
+ 
+    project(googletest-download NONE)
+ 
+    include(ExternalProject)
+    ExternalProject_Add(googletest
+      GIT_REPOSITORY    https://github.com/google/googletest.git
+      GIT_TAG           master
+      SOURCE_DIR        "${CMAKE_BINARY_DIR}/googletest-src"
+      BINARY_DIR        "${CMAKE_BINARY_DIR}/googletest-build"
+      CONFIGURE_COMMAND ""
+      BUILD_COMMAND     ""
+      INSTALL_COMMAND   ""
+      TEST_COMMAND      ""
+    )
+    
+Existing build's `CMakeLists.txt`:
+
+    # Download and unpack googletest at configure time
+    configure_file(CMakeLists.txt.in googletest-download/CMakeLists.txt)
+    execute_process(COMMAND ${CMAKE_COMMAND} -G "${CMAKE_GENERATOR}" .
+      RESULT_VARIABLE result
+      WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download )
+    if(result)
+      message(FATAL_ERROR "CMake step for googletest failed: ${result}")
+    endif()
+    execute_process(COMMAND ${CMAKE_COMMAND} --build .
+      RESULT_VARIABLE result
+      WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/googletest-download )
+    if(result)
+      message(FATAL_ERROR "Build step for googletest failed: ${result}")
+    endif()
+
+    # Prevent overriding the parent project's compiler/linker
+    # settings on Windows
+    set(gtest_force_shared_crt ON CACHE BOOL "" FORCE)
+    
+    # Add googletest directly to our build. This defines
+    # the gtest and gtest_main targets.
+    add_subdirectory(${CMAKE_BINARY_DIR}/googletest-src
+                     ${CMAKE_BINARY_DIR}/googletest-build)
+
+    # The gtest/gtest_main targets carry header search path
+    # dependencies automatically when using CMake 2.8.11 or
+    # later. Otherwise we have to add them here ourselves.
+    if (CMAKE_VERSION VERSION_LESS 2.8.11)
+      include_directories("${gtest_SOURCE_DIR}/include")
+    endif()
+
+    # Now simply link against gtest or gtest_main as needed. Eg
+    add_executable(example example.cpp)
+    target_link_libraries(example gtest_main)
+    add_test(NAME example_test COMMAND example)
+
+Note that this approach requires CMake 2.8.2 or later due to
+its use of the `ExternalProject_Add()` command. The above
+technique is discussed in more detail in 
+[this separate article](http://crascit.com/2015/07/25/cmake-gtest/)
+which also contains a link to a fully generalized implementation
+of the technique.
+
+
 ### Legacy Build Scripts ###
 
 Before settling on CMake, we have been providing hand-maintained build
 projects/scripts for Visual Studio, Xcode, and Autotools.  While we
 continue to provide them for convenience, they are not actively
 maintained any more.  We highly recommend that you follow the
-instructions in the previous two sections to integrate Google Test
+instructions in the above sections to integrate Google Test
 with your existing build system.
 
 If you still need to use the legacy build scripts, here's how:
diff --git a/googletest/include/gtest/internal/gtest-port.h b/googletest/include/gtest/internal/gtest-port.h
index 860aaaf5..0d53ad27 100644
--- a/googletest/include/gtest/internal/gtest-port.h
+++ b/googletest/include/gtest/internal/gtest-port.h
@@ -760,8 +760,12 @@ using ::std::tuple_size;
 
 # if GTEST_OS_LINUX && !defined(__ia64__)
 #  if GTEST_OS_LINUX_ANDROID
-// On Android, clone() is only available on ARM starting with Gingerbread.
-#    if defined(__arm__) && __ANDROID_API__ >= 9
+// On Android, clone() became available at different API levels for each 32-bit
+// architecture.
+#    if defined(__LP64__) || \
+        (defined(__arm__) && __ANDROID_API__ >= 9) || \
+        (defined(__mips__) && __ANDROID_API__ >= 12) || \
+        (defined(__i386__) && __ANDROID_API__ >= 17)
 #     define GTEST_HAS_CLONE 1
 #    else
 #     define GTEST_HAS_CLONE 0
diff --git a/googletest/test/gtest-printers_test.cc b/googletest/test/gtest-printers_test.cc
index 3e97cc24..af69f282 100644
--- a/googletest/test/gtest-printers_test.cc
+++ b/googletest/test/gtest-printers_test.cc
@@ -211,7 +211,9 @@ using ::testing::internal::Strings;
 using ::testing::internal::UniversalPrint;
 using ::testing::internal::UniversalPrinter;
 using ::testing::internal::UniversalTersePrint;
+#if GTEST_HAS_TR1_TUPLE || GTEST_HAS_STD_TUPLE_
 using ::testing::internal::UniversalTersePrintTupleFieldsToStrings;
+#endif
 using ::testing::internal::string;
 
 // The hash_* classes are not part of the C++ standard.  STLport