This avoids a NullPointerException when trying to call the callback
and gives a more readable error message.
(cherry picked from commit 5f277e1667)
(cherry picked from commit c8e4cc8e99)
Change-Id: Ia5f328c4b25aa6624dc3c8493eb0c7bbab99904c
The GraphicsEnvironment class is given information during application
start, and makes it available to EGL/GLES/Vulkan loaders that don't
have easy access to the VM or to the application Context. Currently
only the driver path is handled, but the existing support for setting
library paths (for Vulkan extensions) and cache directory information
should move here.
Bug: 33531483
Test: various apps w/ and w/o driver package installed
Change-Id: I5820d3d1301d5461e10706f551b268c54d4f8926
(cherry picked from commit b12249b671)
The GraphicsEnvironment class is given information during application
start, and makes it available to EGL/GLES/Vulkan loaders that don't
have easy access to the VM or to the application Context. Currently
only the driver path is handled, but the existing support for setting
library paths (for Vulkan extensions) and cache directory information
should move here.
Bug: 33531483
Change-Id: I4e4e7fb21f1bcc67122e9173514af5f18c063991
Merged-In: I5820d3d1301d5461e10706f551b268c54d4f8926
It's not clear this actually makes much difference on modern
devices/drivers. With updatable graphics drivers, we'd have to be able
to unload the preloaded driver from processes that don't use the
system driver, which is additional complexity and risk.
On bullhead and sailfish, meminfo actually showed slightly more memory
available while sitting at launcher just after boot with this change
than previously. Looking at detailed stats, the differences appeared
to mostly within run-to-run variation, but there wasn't evidence of a
regression.
Bug: 33531483
Test: boot through lockscreen/launcher
Change-Id: I1892302c1750cdbeaf5b9979f8da4dc6bd7b3e75
Merged-In: I1892302c1750cdbeaf5b9979f8da4dc6bd7b3e75
Commit 794c8b0b3f fixed the race condition
when requesting data wipes via uncrypt. We have similar issue with
RecoverySystem.installPackage(). It first requests to set up the BCB,
then triggers a reboot. These two steps should finish atomically.
This CL switches to calling
RecoverySystemService.rebootRecoveryWithCommand(), which guards the two
steps with synchronized blocks.
Bug: 34239871
Test: Having two apps: one calls RecoverySystem.cancelScheduledUpdate()
continuously, and the other calls RecoverySystem.installPackage()
just once. The install request should not be cancelled by the
other.
Change-Id: I5ec56fcaa70eae7c33e3cc8e6cfc7472b935ce4e
To support reading embedded buffers that can be
nullptr (currently only in empty hidl_vec).
Bug: 34255213
Test: hidl_test_java
Change-Id: I72028f580b7863b6bfeb31a5c0f43deed36dfd64
If multiple async shared preferences writes are queued, all but the
last one can be ignored as they will be overwritten by the last one
anyway.
For commit() we need to make sure that we have at least persisted the
state of the commit.
Generation counts are 64 bit, hence they never overflow.
Test: Produced a lot of SharedPreferences.Editor.apply and did not see
excessive writes anymore, ran SharedPreferences CTS tests
Bug: 33385963
Change-Id: I3968ed4b71befee6eeb90bea1666a0bb646544f6
(cherry picked from commit 31d6889f4c)
On FBE devices, don't save the metrics to disk but compute them when the
password is first entered and only store them in RAM.
Merged-in: 5daf273b7e
Bug: 32793550
Change-Id: Icee7f615167761177b224b342970a36c7d90f6ba
