- Brings by old deleted APIs and hides them
- Except parceling and hidden APIs that won't have been called anyway
- Option holds a reference to the Request object so we don't have to
rebuild it
Bug: 77523413
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextSelectionTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextLinksTest
Change-Id: I4277c48a950c3334439649373885ed7fe54f898e
* changes:
Reparent recents animation task leash to app animation layer
Allow recents animation to override divider minimized state
Prevent unnecessary reordering of the home stack
This is what A11yService#getWindows promises in the javadoc.
Fixes: 71581072
Test: using testback ensure the order is correct
Change-Id: I5038c4de29c60e235b65751f7bd7771ef35eb339
(cherry picked from commit f40da1a884)
Was bindering into WM service pretty often due to this which was
causing some jank
Bug: 72236832
Test: Related touchmode/focus CTS tests still pass
Change-Id: Ia0f89429b67464beea07c702d8fe2d8b813f8d38
Cannot find class when registering Usb connection broadcast receiver
in AndroidManifest, causing system process to crash. Switch to
register receiver at runtime when boot complete.
Fixes: 77274266
Test: Manually plug & unplug usb cable, and reboot device
Test: Verify usb_data appears in batterystats dump
Test: Verify there is no crash log
Change-Id: If4a9e85aa81173ad6d8cb6ce28cc030814c520a5
certificates with lower version. Earlier, the code just returned
silently, giving no indication that updating certs failed.
Change-Id: I3eb1b9f423791a655b47b3e76c20a170e2b632c0
Bug: 77533356
Test: runtest frameworks-services -p
com.android.server.locksettings.recoverablekeystore
It fails to read exception from Parcel using
Parcel#readException(int, String) because this method doesn't take into
account the remote stack trace info added in writeException().
Test: Manual
Bug: 77495513
Change-Id: I7b646b4a591306832897a42c4ed205d00019cc2b
Adds support for a new AppOp to permit services to
use IpSec tunnel mode. The IpSecService now needs
a context so change the service mode to a cached
service rather than a static service.
Bug: 66955045
Test: runtest frameworks-net
Change-Id: I17a4a286225b432c3e15ea1587d946189931b4f4
In the KillApplicationHandler for uncaught exceptions ensure that the
LoggingHandler has been run. This ensures logging when code directly
calls getUncaughtExceptionHandler().uncaughtException().
(cherry picked from commit 50fa122cff)
Bug: 29624607
Bug: 73380984
Test: m
Test: manual
Merged-In: I9c9216714b4cf029d7ed21e29313c0e802345337
Change-Id: I9c9216714b4cf029d7ed21e29313c0e802345337
RecoveryController and related Parcelables were moved to a different package long time ago. Only very old recvoery controller implementations used it.
Bug: 74944591
Test: atest RecoveryControllerHostTest
Change-Id: I803b7d8a813f7e6c3606dc77afb2e0a3d916ec3f
Add a new capability that may be granted to past signing certificates
after changing to a new signing certificate that will allow applications
to go back to a previous signing certificate. This capability is
intended to not be granted, but may be added later in the event that
a signing certificate change caused undesirable behavior.
Bug: 73927694
Test: PkgInstallSignatureVerificationTest
Change-Id: I7453a2da00e740a55de45e7b144f308a9bc33772
(cherry picked from commit a1d0cf74f9)
A deadlock between the UI and render threads caused by magnifier is
currently making the running app to become not responding. The deadlock
could happen in the following scenario:
1. The UI thread sets a frame callback and asks mRenderer to sync and
draw the current frame. A draw task is enqueued by RenderProxy in the
C++ code
2. The UI thread starts an InternalPopupWindow#destroy() on the UI
thread and acquires mLock
3. mRenderer#destroy() is called on the UI thread, which enqueues a
destroy task in the C++ code. However, this is implemented
synchronously, so the UI thread will wait until the destroy task is
dequeued and executed
4. Since the draw task was enqueued before the destroy task, this will
be executed and the frame callback will be called on the render thread
5. The frame callback tries to acquire mLock. However, this is held by
the UI thread, so the render thread has to wait for it. At the same
time, the UI thread cannot progress either as it is waiting for its
destroy task to execute.
The CL adds a new lock which is used by the UI thread to mark its
intention to #destroy(), such that the render thread will know about
this before trying to acquire mLock and starving.
Bug: 75276625
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iedf2948350fcf8dd9c819c085b31b7ccaf2db7c5
If you put values into the Builder, you should be able to observe
those values on the built object.
Test: atest android.net.cts.NetworkRequestTest
Bug: 74945408
Bug: 72828388
Change-Id: Ib4026b8d7370d570f1b606f0d221d00fed6e787d
