Builds libwvmdrmengine.so, which is loaded by the new
MediaDrm APIs to support playback of Widevine/CENC
protected content.
Change-Id: I6f57dd37083dfd96c402cb9dd137c7d74edc8f1c
Remove the clear key drm engine as it is no longer needed and
would need to be reworked to be compatible with the new MediaDrm APIs.
Change-Id: Ie33c00345876fcd75f7c9cb0c65bd12bb4152f20
In order to match the other implementations of CDM, we are going
to replace the android OEMCrypto mockup with the one in the cdm
repository.
This would be disruptive to the clear key library because it
relies on the current implementation of the mockup. In order to
prevent that, I am moving the current mockup into the same directory
as the clear key library. Then, we can put the new mockup under
the directory libwvdrmengine.
This mockup will then be deleted when the clear key library is deleted.
Change-Id: I89ee23f249dacd18241ae5ca499329e620bf5a2c
Because the Widevine Sample Play is frequently used to report bugs, it is
helpful to have users' actions logged. This change prints to the android log
whenever the user changes settings, clicks play, full screen, acquire rights,
etc.
This code does not change the build and is not delivered to customers. It is
delivered to vendors.
Change-Id: I62c34c2f1683af881a3c326a48f039b463ca3e8e
This is a software only implementation of the OEMCrypto library for
testing the rest of the DRM code. It currently implements the
OEMCrypto_DecrtyptCTR function using a clear key.
I've included the license request code so the rest of the group can
play with it, but I have only tested part of it.
This patch also has some makefiles and an integration testing. You
should be able to generate the shared library libclearkeydrmengine.so with
cd vendor/widevine/libclearkeydrmengine; mm
You can create some unit test and integration test programs from the
directories:
vendor/widevine/libwvdrmengine/oemcrypto/test
vendor/widevine/libclearkeydrmengine/test
vendor/widevine/libclearkeydrmengine/inttest
vendor/widevine/libclearkeydrmengine/crypto/test
This change also addresses some comments about comments in OEMCryptoDASH.h
which were made in https://googleplex-android-review.googlesource.com/257323
Change-Id: Id6899b9f8d2f09e09be2ea493baa83a6b929073b
Adds the initial pieces of a sample DRM Engine that accepts keys in the clear
through the decrypt call instead of using the DrmClientPlugin and its key
ladder. This is to help unblock teams writing code that consumes DRM Engines
while Widevine continues working their real DRM engine. This is based on the
in-progress Widevine DRM Engine.
This change contains the DRM Engine glue pieces (.so entry point,
DrmPluginFactory, etc.) and a CryptoPlugin implementation. However, said
CryptoPlugin will not work until an implementation of OEMCrypto is provided
in a future checkin and the CryptoPlugin is hooked up to it.
For ease of loading, this library also implements the old CryptoFactory
interface and entry point.
If asked to create a CryptoPlugin with no data, it will defer to the old
Widevine Crypto Plugin.
Change-Id: I0bfbec7e32439a50a2956488dd970284f0075e61
I added a few error codes for out-of-resource type conditions.
I added comments explain which functions may be called simultaneously.
Basically, info only functions, like getDeviceId, may be called anytime after
initialization. Functions that have a session parameter may be called at the
same time as other functions for a different session, but not for the same session.
Functions that create or delete sessions may not be called as the same time as any
each other, or at the same time as any session functions. The CDM is required to
honor these conventions.
If the OEM can only decrypt for one session at a time, it is the OEM's
responsibility to hold a lock.
Change-Id: If4b11afd70b5b2e67d78802ea0057fb25271ae90
The file OEMCrypto.h was renamed to OEMCryptoDASH.h and all
functions that are only needed for legacy support were removed.
Change-Id: I3a7a6f8cbb3ee415b4a313416a25ed78785ecdd7
This header file documents the interface of the ContentDecryptionModule
and the CDM client.
b7615806
Change-Id: I9a036ec5539f7e5b66adb8a6a4326120624d1b30
I added a Mock OEMCrypto implementation with stubs only.
I corrected the "extern C" location in OEMCrypto.h. (Thanks, Jerry!)
I added some Android.mk files that allows us to compile and
run a few simple unit tests.
Unit Test 1: The library compiles. (passes)
Unit Test 2: The test program links and runs. (passes)
Change-Id: Ib4c9554553de49645b5841b0bae889728cbfc8b1
This change updates the Widevine binary libraries.
It includes the change:
Turn on IPv6 Compatibility.
https://widevine-internal-review.googlesource.com/2242
bug: 7471810
Change-Id: I09beacb7853435f21c263e226a3dcaff74afbd2b
This change updates the Widevine binary libraries.
It includes the change:
Correct error returned by ProcessDrmInfo
https://widevine-internal-review.googlesource.com/#/c/1870/
bug:7320744
Change-Id: Ic73a5dfa70140093224e9ce651947b224bdeccb9
The solution previously checked in as 2e0e3 is re-introduced here. However,
the MediaCodec-compatible heuristic is not used unless WVM is in Crypto Plugin
(i.e. Media Codec) mode.
To repeat from last time: The problem here is that WVM cannot independently
seek the audio and video read heads, but the API assumes it can. WVM does the
right thing for AwesomePlayer-based playback (essentially ignoring audio
seeks) but the wrong thing for MediaCodec-based playback. For MediaCodec
mode, we should respect the first seek we get for a given destination and
ignore the second.
In this part, the new heuristic is reintroduced, but the old heuristic is
maintained for use in non-Crypto Plugin mode.
Bug: 6793514
Change-Id: I7ced2bf20af117a57eec27490b0920d906a8a684
Change 14f0d to read the maximum buffer size from a device property did not
work correctly on Mako and Prime devices, as they did not have the property
set, and the code to fall back to a default value was not working. An empty
string would be read instead of the default value, resulting in a maximum of
zero. Because Widevine Media Kit would then subtract a few megabytes from this,
it would underflow, giving a maximum buffer size of several gigabytes. This
would lead to the download code trying to pre-buffer the entire, many-gigabyte
movie. As the media server's memory usage grew and grew, other programs would
become starved for memory, leading to most other processes on the phone being
forced to close. Eventually, the playback app, the media server, or some other
crucial piece of functionality would be starved, resulting in a crash.
The fix is to fix how we get the default, so that when the property is not
available, we get a sensible result. We check the return value of property_get.
If it is greater than zero, the property was read successfully, and we parse
the answer. If it is equal to (or less than) zero, we fall back to the default
value.
Bug: 7222769
Change-Id: Ie6186a0533036ab8fa45b1e467611d55f7c345ac
This reverts commit 4bdfcc990b
This change was causing some deadlock problems.
bug: 7144860
bug: 7132419
Change-Id: I6a45459b0be024c8c36ccca3b2e2d304ddd94ee9
