Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: I6e6a6462ab8343299dc5e0145b87dc28b16b0bc1
So it doesn't leak when gc is delayed in service process.
Update HintManagerService to allow multiple sessions tied to the same
token.
Bug: 218129784
Test: chrome no longer gets killed
Change-Id: I67a66041cc67d01e4cfcd3ded303a1bed6050f60
Users of the API will see in the "Actual Timeline" the actual start time
rather than expected start time.
Bug: 210043506
Test: perfetto log of with & w/o CL, using Chromium apk, bug 198192946
Change-Id: I013bf6e28de32c82c9d645cc4cacf0cc01e0dd9f
Added new methods for getActionButton and getClassification in input.h.
In this CL we are adding implementations for the corresponding functions
Test: atest android.view.cts.MotionEventTest
Bug: 213266814
Change-Id: Ia7c7b83fe19bac7d5e5c7c107e86328e160ba2b5
Bug: 217890463
Test: Used uhid-sample to add a dynamic sensor and verified it can be
used with sensor_test.
Change-Id: Ia930c6993c97527381d30e33f817f37632cb8396
These functions were already exposed as part of libandroid_net,
but that is not really part of the NDK.
Expose them in libandroid as well, so apps can actually use them.
This is consistent with all the other native networking APIs,
which are exposed in both libandroid_net and libandroid.
Test: atest CtsNativeNetPlatformTestCases
Test: strings out/target/product/bramble/system/lib64/libandroid.so | grep android_tag
Change-Id: I2273cdd48b30a88b82eb3af838031d9fe8897442
When latching unsignaled buffers, the acquire fence is
not signaled by the time BLAST callback is invoked. In
that case pass a fence instead. For latch signaled, we still
pass the acquire time itself to avoid sending file descriptors
over binder.
Bug: 198190384
Test: TBD
Change-Id: I949fd396ec36ee759327a952239509d10259be1b
Instead of assuming a JNIEnv*, the method should have the env passed
into it, which is the standard practice for native APIs.
Bug: 210727635
Test: atest InputQueueTest
Change-Id: Iae5fc5bd39c758c530185694751d6d79715ce31b
Transaction.setAcquireFence is removed and instead the fence can be sent
directly in the setBuffer call.
Test: Chrome works
Fixes: 200065015
Change-Id: I248f07d7ce5a3faa0d7482fe4e0e7b33f3cfea55
Avoid getting the wrong frame info when duplicate frame numbers are found in the ring buffer. Will ensure there isn't a mismatch in the metrics data reported.
Test: Existing tests
Bug: 197515602
Change-Id: Iff9ba01f575f94e5a9872ee48c0dd1e5067880c3
The original java implementation just passed along whatever the server
returns which is -1 on unsupported devices. So do that here as well.
Test: PerformanceHintManagerTest passes on unsupported device
Bug: 194691581
Change-Id: I8ac07737e6ce52debf55478880d71f038f258056
isDataspaceValid is problematic in that it prevents
applications from being able to pass-through dataspaces
they receive from other APIs, and it also assumes that
the display's capabilities are the only things that are supported.
Although it's recommended that applications stick to dataspaces
that the display can handle, it's not strictly required. RenderEngine
can handle more dataspaces than the display can, applying appropriate
color conversion. Similarly this could be going to a virtual display
instead, in which case the physical display's capabilities are not
necessarily relevant.
Bug: 149931223
Test: make
Change-Id: I475f4e4dcbcdb4765670f6a8eb4cc047a9babb43
In order to simplify some of the geometry logic in BufferStateLayer,
and unify with the rest of the layer in SurfaceFlinger we translate the
concept of source and dest frame into crop, scale and position. This is
currently done on the client side.
But if there is buffer rotation transform, we will generate an
additional scale, to scale the buffer size to the new orientation. This
causes issues with rounded corners because the additional scale
stretches the rounded corner incorrectly. And translating the buffer
rotation into a rotation matrix affects child layers.
This solution only adjusts the buffer size based on the rotation
matrix and the scale is generated based on the rotated buffer.
This cannot be done in the client side because we do not have
the current display orientation to unflip the buffer if the client
sets the transformToDisplayInverse flag.
In the future the plan is to drive the transform hint and the
display orientation down from WM so this calculation can go
back to the client.
Also fixes incorrect additional scaling from source frame to dest frame
in ASurfaceTransaction_setGeometry.
Test: atest SurfaceControlTest ASurfaceControlTest libgui_test SurfaceFlinger_test
Test: go/wm-smoke
Bug: 185597146
Change-Id: I38adbc72c7567510c953cfd362a94b2b38d7fda7
