Currently a native APEX can get and use a VINTF AIDL. However, this
can't be passed over JNI to be used by Java code.
This does not open VINTF AIDLs to any type of apps, where AIDL as an API
is completely disallowed. Also, no Java ServiceManager APIs are
available, and they couldn't be until b/139325468 is fixed.
Bug: 161501127
Test: atest binderVendorDoubleLoadTest
Change-Id: I1ab977248b1c39a7d08e0ca34389a7ba168c05b0
Currently a native APEX can get and use a VINTF AIDL. However, this
can't be passed over JNI to be used by Java code.
This does not open VINTF AIDLs to any type of apps, where AIDL as an API
is completely disallowed. Also, no Java ServiceManager APIs are
available, and they couldn't be until b/139325468 is fixed.
Bug: 161501127
Test: atest binderVendorDoubleLoadTest
Change-Id: I1ab977248b1c39a7d08e0ca34389a7ba168c05b0
Merged-In: I1ab977248b1c39a7d08e0ca34389a7ba168c05b0
This change includes the following commits that are related to
CertInstaller and KeyChain:
7a5c8fe4afd KeyChain: Unify manual and programmatic key installation flows
a894225c7da Added functionality to select type of certificate to be installed from the Settings app
a9131939a35 Add KeyChain.KEY_ALIAS_SELECTION_DENIED constant.
485be505f19 Fix KeyChain.KEY_ALIAS_SELECTION_DENIED
Bug: 161347472
Test: builds & manual testing
Change-Id: I560bade479b41a5b88f81ea6dfdecba689c2f4ad
When config_remoteInsetsControllerControlsSystemBars is true,
DisplaySystemBarsController provides its own policy of how system
bars are displayed for specific packages. Currently limited to
only auto versions of Android.
Bug: 149585273
Test: Manual, atest BarControlPolicyTest, atest InsetsPolicyTest,
atest DisplaySystemBarsControllerTest
Change-Id: Ie6b1cc3e2760cbc9e48d62dfbd8bc3e23ffca20c
Merged-In: Ie6b1cc3e2760cbc9e48d62dfbd8bc3e23ffca20c
Remove this method, which is undesirable, has unfortunate
side effects, and which is a worse way of getting the current
location than other methods such as TelephonyManager#getAllCellInfo()
(since KK) and TelephonyManager#requestCellInfoUpdate() (since QT/11).
Bug: 152648516
Test: make update-api && make (docstring-only change)
Change-Id: I3c7d345abcdd8c35cf539d33166ddf76ba987b1c
Creating a new Throwable (and filling in the stack trace) can take
up to 150us. Since we do this on the critical path when sending
over SurfaceControl via binder multiple times, this is too much.
Instead, add an option to pass in callsite manually.
Bug: 159056748
Change-Id: I46c339c15a07192d61c4c546e46f260684a47120
Merged-In: I46c339c15a07192d61c4c546e46f260684a47120
Exempt-From-Owner-Approval: Large scale refactor
When an inline content view is reparented its surface is
getting offset and not being under the view itelf. This is
because the surface views manage the postion of their
surface and are assuming a location based off the window's
surface position. However after a reparenting the inline
content view's surface position becomes relative to that
of the new parent surface view. For example, two surface
views at position (10, 10) being reparented would reslut
in the surface of the parent being at (10, 10) while the
surface of the child being at (20, 20) while both views
would still be at (10, 10).
To address this we are intecepting when an inline content
view's surface is reparented and get a weak reference to
the view that owns the new parent surface. We then position
the inline content view's surface relative to the view that
owns the new parent surface, i.e. we position the surface
such that its location would not change because of the
fact it is being reparented.
While at this make sure the inline content view is marked
as not important for a11y to ernsure the a11y plugins don't
try to click on the view tree in the app's process but
insted on the views in the remote proccess, i.e. on the
embedded view tree.
bug:153826463
Test: atest android.widget.cts.inline.InlineContentViewTest#testReparenting
Change-Id: I2cff4b88d404a740bc447668e948eabccad084d2
We add new test in stage-aosp-rvc-ts-dev for R2, we need make this API
testable.
Bug: 156408900
Test: atest android.autofillservice.cts.inline.\
InlineAugmentedWebViewActivityTest
Change-Id: I27d1227f858aac83b3de1cb8ef719edf177524dc
Merged-In: I27d1227f858aac83b3de1cb8ef719edf177524dc
A11y service cannot get focus of bubbles because it's not a
System owned display. This patch makes System UI owned display
a trusted display. Moreover, this patch refactors the logic to
identify a trusted display by introducing FLAG_TRUSTED and
removes the trusted display check along with supportsSystemDecorations()
because the check has been included in supportsSystemDecorations().
fixes: 155823002
Bug: 152416787
Test: atest DisplayContentTests
Test: atest WindowFocusTests
Test: atest TaskDisplayAreaTests
Test: atest MultiDisplaySystemDecorationTests
Test: atest DisplayTest
Change-Id: Ie684c6488904e5aa8cae166a455c6d55455e5f55
The offset was computed based off the offset represented by
the most recent historical file while we have to use the time
this file was written.
Also now we persist the history on reboot and shutdown,
significantly minimizing the possibility of data loss.
Added test API to emulate reboot of the history to allow for
precise and tightly controlled test to prevent flakes due to
boot time deviations.
Test: atest android.app.appops.cts.HistoricalAppopsTest#testRebootHistory
Fixes:156853195
Change-Id: I4142371f8bc2b1d710cc8c300e7e79cb03764c04
