Merge from http://go/wvgerrit/105767
To avoid conflict with metrics.proto in
frameworks/av/drm/libmediadrm/proto.
This is in preparation of moving metrics_dump tool
to build under Android.
bug: 161783052
Test: unit test
Test: Play Movies & Tv and Netflix streaming
Change-Id: I2406b66db4d61cca7c6260ea8847a555d96c8d42
[ Merge of http://go/wvgerrit/105025 ]
Clang and GCC allow for warnings against the arguments for printf-like
functions (e.i. LOGx). These validate that the format type specified
in the format string match the corresponding argument type.
Most of the time, format specifer errors are benign; hence why they
haven't been seen as an error so far. However, with the enabling of
specifier warnings and the enabling of warnings as errors on certain
platforms, these existing errors need to be addressed.
This CL enables format specifier warnings for most of the Widevine
code, with the OEMCrypto L3 implementation which has a single error
which requires a fix in the haystack code before being fixed in the
Widevine branch.
Strict format string warnings are not enabled for non-LP64 systems.
Bug: 137583127
Test: Compiled for Linux and Android
Change-Id: I051398332d31a20457b86563a90ad8f6d428445f
[ Merge of http://go/wvgerrit/105624 ]
Temporary licenses do not allow for license information to be stored
in any form, whether it is usage information or persisting license
information. Information should not be stored even if can_persist is
set to true and a PST is specified as those are suggestions rather than
a requirement.
Bug: 167684104
Test: WV unit/integration tests
Change-Id: I141a2bd5de4d86f0e5f31fc8f0ea9e20710d6469
[ Merge of http://go/wvgerrit/105343 ]
If a device only supports local display (eliminating the need for an
SRM version), then the CDM should treat this as no SRM version.
Bug: 166009716
Test: License request integration test
Change-Id: I2d9c3f98735563df6d7c7a287abab41bf0a8c513
The Blueprint file doesn't seem to be compatible with some 64-bit
targets (namely bertha_x86_64) - remove for now to stop build breakage.
Test: make -j32 libwvdrmdrmplugin_test
Bug: 165933287
Change-Id: I36d8238cc1a78eefef2ba2a06a4360ea46080349
This CL builds the Widevine drm services and libraries.
Soong makefile conversion for unit and integration
tests will be in a different CL.
This doc may help with the review:
https://docs.google.com/document/d/1lK3X9RFPwbbwewLNlS4TfSMhxIlPuAkHRnGcgwWpChU/edit?usp=sharing
Test: build
Test: Play Movies and Netflix streaming
Test: unit tests
build_and_run_all_tests.sh
Test: gts
ANDROID_BUILD_TOP= ./android-gts/tools/gts-tradefed run gts -m GtsMediaTestCases -t com.google.android.media.gts.MediaDrmTest
atest GtsExoPlayerTestCases:com.google.android.exoplayer.gts.DashTest
Test: vts
ANDROID_BUILD_TOP= PATH="$PWD/android-vts/tools:$PATH" vts-tradefed run commandAndExit vts --module VtsHalDrmV1_3Target
Bug: 162321744
Change-Id: I50c0fb2e8f28dfe7901587e3d3203542943e23b1
Merge from Widevine repo of http://go/wvgerrit/102843
The test WvCdmEngineTest.LicenseRenewal is split into two tests. One
test verifies that the renewal may be fetched from the server
specified in the license. The second test verifies that the renewal
may be fetched from the same server that the license was fetched from.
These might be the same server, but when we run against an
experimental server, a staging server, or UAT Nightly, these
will be different.
Test: ran the tests
Bug: 141438127
Change-Id: Ia11441bd2ba0c6ddb264ee38bfcb5060b9ddb476
(This is a cherry-pick of http://go/wvgerrit/104184.)
UBSan has detected several places where our code tripped over what is
technically Undefined Behavior when handling enums, although in practice
any compiler would still generate safe code.
Some of these were places a variable was not being initialized and thus
was filled with garbage data. These have been fixed.
Understanding the rest depends on a bit of C++ trivia I had certainly
never heard before: An enum that doesn't specify its backing type will
frequently have a gap between the range of values the compiler will let
it take (which is limited only by the size of the backing type assigned
by the C++ standard) and the range of values for which the C++ standard
defines the behavior. (which is limited by the minimum number of bits
needed to hold the largest valid enumeration entry) So, for example, an
enum containing ten entries numbered 0 through 9 would be stored in
memory as an int and could thus take any value in the range of an int.
But it only takes 4 bits to represent the numbers 0 through 9. The
largest number that can be represented in 4 bits is 15. So reading the
value of a variable of this enum type when its stored value is outside
the range 0 to 15 is undefined behavior.
An enum that specifies its backing type is not subject to this because
it is defined behavior to access any value representable in the backing
type if one was explicitly specified.
If you think this sounds a bit silly, you'll be happy to know it doesn't
apply from C++17 onwards and most compilers generate code that handles
the undefined behavior values correctly.
Nonetheless, to appease UBSan and protect us from any compilers that
actually rely on this undefined behavior for optimizations, I have
defined backing types for all our enums. I have defaulted to the type
the compiler was already using (int32) and have deviated only where an
enum exists to be compared to or filled from a protobuf field and that
field in the protobuf is unsigned, in which case I used a uint32.
In the case of the CE CDM exported API, this also required changing our
enums from C-style to C++-style.
Bug: 163080356
Test: CE CDM Build & Unit Tests Pass even with UBSan
Test: Android Build & Tests
Change-Id: Id7e0064129e7c4d2827bb4a94825d144eeaacec8
