... on "current" compat mat level. They are kept optional
on upgrading devices.
Test: builds (assemble_vintf passes)
Bug: 63702641
Change-Id: Iafe64c4ffa7df8aa7f80a1b6cf599d56e7854f33
framework & storaged talks to health@2.0 HAL prior to healthd.
If the vendor service for health@2.0 is missing, framework / storaged
falls back and talks to healthd. Hence health@2.0 HAL is optional.
A follow-up change is needed to require launch devices to launch
with health@2.0 (i.e. current.xml says optional=false).
Bug: 62229583
Test: builds (assemble_vintf passes)
Change-Id: I49caca2b683e928f25e6f3cac2e2a8396b50f46a
BatteryService does not use these fields for posting
sticky intents.
This is a partial revert of commit
cbfb15e0b8.
Bug: 63702641
Test: boots
Change-Id: Id6596b04daaa19ae97d783c7a8bc111a43725334
FB (framebuffer) HAL has been replaced by HWC HAL for 5+ years, but
we still support the legacy path in SurfaceFlinger. Devices using
the legacy path cannot be Treblized.
This change allows such devices to use HIDL IComposer, by adding
support for FB HAL in the default implementation.
Test: boots hikey960
Change-Id: Ie9050bbcaac0fd5b134786f4f9f0f5075f4ebd0c
After initialization or onRefresh, we want to make sure
validateDisplay is called before presentDisplay.
Bug: 67505273
Test: manual
Change-Id: Id876d9251586aaaf552ca82c52f8f902af364251
The hardware composer service has a rule that only one client can be
connected at a time. The surface flinger process, when transitioning
composer ownership from surface flinger to vr flinger, will destroy the
current client on one thread and create a new client on another
thread. Although surface flinger ensures that these events happen in the
expected sequence (delete then create), the requests sometimes land in
the hardware composer service in inverted order, causing the creation
request to fail with an error.
Instead of failing with an error, block for a brief period (1 second)
until the existing client is removed, then proceed to initialize the new
client. This gives us enough time to ensure an inverted
creation/destruction order doesn't cause client creation to fail, while
avoiding a deadlock if the existing client is never destroyed.
Bug: 62925812
Test: - Transitioned to/from vr flinger hundreds of times, and confirmed
I no longer see sporadic composer client creation failure due to an
already existing client.
- Ran the vts graphics composer tests and confirmed they all pass.
Change-Id: I40be1fb0cb3d42ddb5a9fc159188886e9f5b6267
Register a death recipient to remove the callback if
the framework side died.
BUG: 67913697
Test: VTS
Change-Id: I51ce5c85c9ec5d1bc90cac72f314647e1075d657
Automatic mk -> bp conversion for all modules here
which can be converted and built automatically.
Test: Soong resolves all dependencies
Bug: 37512442
Change-Id: Ib789212cb88d55731397c600d132e7c672c0d8be
AesCtrDecryptor::decrypt() doesn't check whether the size of "key" is
equal to 16 bytes, which may lead to an OOB read problem in the context
of mediadrmserver. The fix is in clearkey plugin. Add tests to validate
the fix.
Test: VTS test
adb shell /data/nativetest/VtsHalDrmV1_0TargetTest/VtsHalDrmV1_0TargetTest
bug: 63982768
Merged-In: Ife2da17e7f39d8031bc36b83c3b27ba5e9d83eb7
Change-Id: Ife2da17e7f39d8031bc36b83c3b27ba5e9d83eb7
This version of configstore was removed internally.
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I589addff6aec7bb7a8a7938d75c51dcc56116a42
