[ Merge of http://go/wvgerrit/102108 ]
Several tests that make parallel license requests were disabled due
to a flaky server failure unrelated to CDM code. Most of these tests
are now re-enabled to ensure the multi-threaded license requests is
functional on V16.
These tests remains disabled for L3 due to continued flakiness.
Added a lock around the initialization of the SSL library to prevent
issues with license requests getting garbled.
Bug: 137619348
Test: Linux and Android unit tests
Change-Id: Idffaa6039b2bde12613bb5033af32d1af6704c76
(This is a merge of http://go/wvgerrit/102084.)
No one was claiming ownership of the metrics object in
CertificateProvisioningTest, resulting in a leak. This patch makes the
test hold onto ownership.
Bug: 159486086
Test: CE CDM Unit Tests
Test: Android Unit Tests
Change-Id: I84710782b7a60d6bd3a7eda981de4f0af877fc39
(This is a merge of http://go/wvgerrit/102104)
The device file unit tests use some custom matchers that were written
back when we didn't have C++11. Because gMock requires std::tuple to
pass a pointer AND a length to a matcher, these matchers had to estimate
the length of the file. This technically meant they were causing a
benign buffer overrun sometimes.
Since we have C++11 now, we can fix this by using a matcher over a
std::pair of the pointer and length. I also took the opportunity to
refactor the matchers a little. The old matchers had many very specific
overloads and also collided with the names of some standard gMock
matchers. Now there are just two more-general matchers with unique
names.
Test: CE CDM Unit Tests
Test: Android Unit Tests
Bug: 159463905
Change-Id: I758b140226bfe2bae6962ee5c64fd6af186b5819
[ Merge of http://go/wvgerrit/102109 ]
The CDM was using unique CDM error codes for the various cases
where OEMCrypto would return INSUFFICIENT_RESOURCE. However, these
error codes were being incorrectly mapped at the Android level,
resulting in incorrect errors in the MediaDRM layer.
At no point does the CDM handle different INSUFFICIENT_RESOURCE_x
within the same case, as such the use of unique codes are limited.
This CL removes the unique codes, and unifies them under the same
CDM error code.
This CL also extends SelectKey to handle error codes returned by
LoadEntitledContentKeys.
Bug: 154682842
Test: Unit tests
Change-Id: I319fabf6cac60b0dc19ea891609689daeeaeb435
[ Merge of http://go/wvgerrit/102068 ]
CDM sessions should not be able to load multiple usage entries.
OEMCrypto already prevents multiple entries from being loaded by the
same OEMCrypto session; however, restoring a key typically creates a
new OEMCrypto session, which should not be allowed twice within the
same CDM session.
This test verifies that CDM returns an error if restore key is called
multiple times within the same session.
Bug: 136143733
Test: Android integration test
Change-Id: I594c91250217fd958837328162f909bc931d373f
[ Merge of http://go/wvgerrit/101443 ]
The WVDrmPlugin has a single CdmIdentifier. The CdmIdentifier contains
a SPOID that is calculated from the device ID (keybox or OEM cert),
an application reverse domain name and possibly an origin.
The CdmIdentifier is set and SPOID calculated on certain calls into
WVDrmPlugin. Once it is set, it will not be recalculated. We prevent
certain operations such as modifying the origin once the CdmIdentifier
has been set as this will require recalculating the SPOID.
Recalculating the SPOID may affect open sessions or calls in progress.
In a similar way, modifying the security level, will affect the
Device ID value and in turn the SPOID. The security level cannot be modified
if any sessions are open. This does leave open the possibility that the
SPOID may be calculated at one security level, sessions are then closed,
and the security level is then changed without an error being flagged.
The provisioning certificate file name is based on the SPOID. When
the SPOID does not match the security level, either the provisioning
information may not be found even though that security level has
been provisionined or the provisioning information may be stored
in an incorrect location if provisioning occurs.
The correct solution is to prevent modifications to the security level
once the CdmIdentifier is set. This is a behavior change and might
impact apps. We will reevaluate this for the next release.
For now, we will work around this. When the CdmIdentifier is set for L3,
we will calculate SPOIDs with both L1 and L3 device IDs and check if
provisioning previously occurred with SPOIDs calculated for that level.
If so, use that level, otherwise use L3.
Bug: 147703382
Test: Android unit/integration tests, GtsMediaDrmTests
Change-Id: Ia64adfc5848e431ee3876af03eebdb4b6eb83116
