The toolchains that built the previous x86 libraries are no longer available.
Attempt to patch the tools was unsuccessful and the output will be greatly different
from previous build, and we do not have any jb-dev x86 devices in house for testing.
The x86 libraries were a special build for specific vendors. Therefore, the x86
libraries will not be updated in this CL.
The arm libraries were built using the same toolchains and svn revision as the previous
version, with updated Jam files pointing to openssl-0.9.8za.
Add reference to openssl-0.9.8za submodule.
https://widevine-internal-review.googlesource.com/#/c/10863/
Update openssl lib to 0.9.8za.
https://widevine-internal-review.googlesource.com/#/c/10864/
bug: 15932110
Change-Id: I72ef476d8900418aae76e05eb9cb30154c911ede
To make the information readily accessible for vendors who have signed the IDA
and to better sync the doc to our code base.
Access to /vendor/widevine is controlled and vendors need to sign the IDA.
bug: 14228621
Change-Id: I3aaa2574d99c0123cb5e0fe0f093763a973aefaf
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
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
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 change updates the Widevine binary libraries.
It includes the change:
Corrected error returned on timeout
https://widevine-internal-review.googlesource.com/1617
b/6758866
Change-Id: I81ac5d14823499b83a237406e7c5d345a15f6434
Reintroduces the play/pause rebuffering logic we eliminated
in JB zero day to fix double spins and slow startup - but
activates that logic only based on a comparison of the
current bandwidth measurement and the lowest bitrate track
in the movie.
Needs to be submitted with related changes in /frameworks/av
bug: 7230071
Change-Id: Ib3859a961bd3901a9c4df01eeab2b8b75f49aefe
This change updates the Widevine binary libraries.
It includes the change:
https://widevine-internal-review.googlesource.com/1400
Cleaned Up Locks and Removed Pause/Resume
bug: 6799914
Change-Id: I5e266e4d8bdc92e88e488d90aa5312ac740303b0
The FATAL EXCEPTION is caused by the decrypt function returning -EINVAL
when OEMCrypto decrypt returns an error. The fix is not to call
OEMCrypto decrypt when eos is reached.
related-to-bug: 7216928
related-to-bug: 7217609
Change-Id: I8f006905386e2cdfb907d4ab15c766ae69f20f00
Signed-off-by: Iliyan Malchev <malchev@google.com>
This allows a DRM client to open a locally-cached file on behalf of the
DRM server so the DRM server no longer requires the sdcard_r permission
to access the file's metadata. Specifically, this adds an optional
attribute FileDescriptorKey to the DrmInfoRequest.
This change is dependent on this Widevine CL:
https://widevine-internal-review.googlesource.com/#/c/1330/
Relevant bug reports:
bug: 6426185
Change-Id: Ia7bcb2455c7a55fa4c7c7061de4d672957c7ac0a
There was a subtle interaction between Widevine's libraries and MediaCodec
mode. Widevine's code assumed (erroneously) that video seeks would always
happen before audio seeks, and because we can't seek audio and video
independently from each other, we would ignore audio seeks but respect video
seeks. This led to a problem since MediaCodec mode calls seeks in arbitrary
order.
Fix is to always respect the first request we get to seek and ignore the
second.
Bug: 6793514
Change-Id: Ic9ec60e0e0f606c7a0de6283dd4c30318eebdbad
In order to test the MediaPlayer info events, an OnInfoListener was added to
the VideoPlayerView class. It is set to listen to events coming from the
videoView. This allows testers to verify that events are occuring.
Note: This change was made by Alexander Oliphant who does not have write
permission to commit to the Android tree.
Change-Id: Ia2faa927b4fe2850e15644bd332e50601a424c4a
Error code from the plugin is not propagated from WVMExtractorImpl.cpp to the MediaPlayer.
The two APIs addresses this issue and provide a path for the player to retrieve the last error.
Change-Id: I60040eaf2d396379eecca46bfe333c44a39c35ec
related-to-bug: 7073630
