| tag | 0e6af0c3a52e7821ad6be27c98b3f5acd2137b3c | |
|---|---|---|
| tagger | The Android Open Source Project <initial-contribution@android.com> | Wed Feb 14 15:13:53 2018 -0800 |
| object | f1c590a8e5b13d85d7d92cdd675b47f6ed38003d |
Android CTS 8.0 Release 6 (4591581)
| commit | f1c590a8e5b13d85d7d92cdd675b47f6ed38003d | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Fri Apr 07 14:11:05 2017 -0700 |
| committer | Steven Moreland <smoreland@google.com> | Tue Apr 11 18:31:14 2017 +0000 |
| tree | 27654a3a42e8292d780fae503c55d43c9ed4ab28 | |
| parent | eac02f91b43006b8b9a38fb98d4bc417b1933c98 [diff] |
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
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.
Google test has been used on a variety of platforms:
In addition to many internal projects at Google, Google Test is also used by the following notable 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.
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!
These are the base requirements to build and use Google Test from a source package (as described below):
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:
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.
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!