Android 8.0.0 release 28
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEABECAAYFAloAq9EACgkQ6K0/gZqxDngN9ACeOQPV8mUKAvP1xvB0LOq3pUaF
BxoAn1sS2/N5gDtOv4AbTVPfldf486s1
=HjKs
-----END PGP SIGNATURE-----
Mark as vendor_available

By setting vendor_available, the following may become true:

* a prebuilt library from this release may be used at runtime by
  in a later releasse (by vendor code compiled against this release).
  so this library shouldn't depend on runtime state that may change
  in the future.
* this library may be loaded twice into a single process (potentially
  an old version and a newer version). The symbols will be isolated
  using linker namespaces, but this may break assumptions about 1
  library in 1 process (your singletons will run twice).

Background:

This means that these modules may be built and installed twice --
once for the system partition and once for the vendor partition. The
system version will build just like today, and will be used by the
framework components on /system. The vendor version will build
against a reduced set of exports and libraries -- similar to, but
separate from, the NDK. This means that all your dependencies must
also mark vendor_available.

At runtime, /system binaries will load libraries from /system/lib*,
while /vendor binaries will load libraries from /vendor/lib*. There
are some exceptions in both directions -- bionic(libc,etc) and liblog
are always loaded from /system. And SP-HALs (OpenGL, etc) may load
/vendor code into /system processes, but the dependencies of those
libraries will load from /vendor until it reaches a library that's
always on /system. In the SP-HAL case, if both framework and vendor
libraries depend on a library of the same name, both versions will be
loaded, but they will be isolated from each other.

It's possible to compile differently -- reducing your source files,
exporting different include directories, etc. For details see:

https://android-review.googlesource.com/368372

None of this is enabled unless the device opts into the system/vendor
split with BOARD_VNDK_VERSION := current.

Bug: 36426473
Bug: 36079834
Test: Android-aosp_arm.mk is the same before/after
Test: build.ninja is the same before/after
Test: build-aosp_arm.ninja is the same before/after
Test: attempt to compile with BOARD_VNDK_VERSION := current
Merged-In: I9722ac3b803d9dab8c01a714d72904fa4dd40196
Change-Id: I9722ac3b803d9dab8c01a714d72904fa4dd40196
2 files changed
tree: 27654a3a42e8292d780fae503c55d43c9ed4ab28
  1. .travis.yml
  2. Android.bp
  3. Android.mk
  4. CMakeLists.txt
  5. README.md
  6. README.version
  7. googlemock/
  8. googletest/
  9. run_tests.py
  10. travis.sh
README.md

Google Test

Build Status

Welcome to Google Test, Google's C++ test framework!

This repository is a merger of the formerly separate GoogleTest and GoogleMock projects. These were so closely related that it makes sense to maintain and release them together.

Please see the project page above for more information as well as the mailing list for questions, discussions, and development. There is also an IRC channel on OFTC (irc.oftc.net) #gtest available. Please join us!

Getting started information for Google Test is available in the Google Test Primer documentation.

Google Mock is an extension to Google Test for writing and using C++ mock classes. See the separate Google Mock documentation.

More detailed documentation for googletest (including build instructions) are in its interior googletest/README.md file.

Features

  • An XUnit test framework.
  • Test discovery.
  • A rich set of assertions.
  • User-defined assertions.
  • Death tests.
  • Fatal and non-fatal failures.
  • Value-parameterized tests.
  • Type-parameterized tests.
  • Various options for running the tests.
  • XML test report generation.

Platforms

Google test has been used on a variety of platforms:

  • Linux
  • Mac OS X
  • Windows
  • Cygwin
  • MinGW
  • Windows Mobile
  • Symbian

Who Is Using Google Test?

In addition to many internal projects at Google, Google Test is also used by the following notable projects:

Related Open Source Projects

Google Test UI is test runner that runs your test binary, allows you to track its progress via a progress bar, and displays a list of test failures. Clicking on one shows failure text. Google Test UI is written in C#.

GTest TAP Listener is an event listener for Google Test that implements the TAP protocol for test result output. If your test runner understands TAP, you may find it useful.

Requirements

Google Test is designed to have fairly minimal requirements to build and use with your projects, but there are some. Currently, we support Linux, Windows, Mac OS X, and Cygwin. We will also make our best effort to support other platforms (e.g. Solaris, AIX, and z/OS). However, since core members of the Google Test project have no access to these platforms, Google Test may have outstanding issues there. If you notice any problems on your platform, please notify googletestframework@googlegroups.com. Patches for fixing them are even more welcome!

Linux Requirements

These are the base requirements to build and use Google Test from a source package (as described below):

  • GNU-compatible Make or gmake
  • POSIX-standard shell
  • POSIX(-2) Regular Expressions (regex.h)
  • A C++98-standard-compliant compiler

Windows Requirements

  • Microsoft Visual C++ v7.1 or newer

Cygwin Requirements

  • Cygwin v1.5.25-14 or newer

Mac OS X Requirements

  • Mac OS X v10.4 Tiger or newer
  • XCode Developer Tools

Requirements for Contributors

We welcome patches. If you plan to contribute a patch, you need to build Google Test and its own tests from a git checkout (described below), which has further requirements:

  • Python v2.3 or newer (for running some of the tests and re-generating certain source files from templates)
  • CMake v2.6.4 or newer

Regenerating Source Files

Some of Google Test's source files are generated from templates (not in the C++ sense) using a script. For example, the file include/gtest/internal/gtest-type-util.h.pump is used to generate gtest-type-util.h in the same directory.

You don't need to worry about regenerating the source files unless you need to modify them. You would then modify the corresponding .pump files and run the ‘pump.py’ generator script. See the Pump Manual.

Contributing Code

We welcome patches. Please read the Developer's Guide for how you can contribute. In particular, make sure you have signed the Contributor License Agreement, or we won't be able to accept the patch.

Happy testing!