In Q, these APIs were either:
- removed from the greylist entirely without good reason
- Moved to the restricted greylist without any public alternative
information added
So they are being moved back to the greylist for Q.
Test: Treehugger
Bug: 136102585
Change-Id: Ie3dd15c8e17d530d853473a013717e6175383080
... as throwing an exception in there somehow will mess up the
hwui task queue.
Test: Have a crashy app, swipe up while the app is crashing
Fixes: 134583193
Change-Id: Ie3ba5f991759f807b154f55f9fc816e7efe2fdfe
As discussed in https://r.android.com/973723
This makes any camera key event wake up the device.
Handling of the camera key apart from waking up the device might follow
in a later commit.
Signed-off-by: Felix <google@ix5.org>
Change-Id: I44dbc3f9ac465f664b6d740cb6a056b7f6e118fb
When the configuration changes between landscape and reverse
landscape, the app will not receive onConfigurationChanged as
orientation is not part of the public portion of the configuration.
However, when the ViewRootImpl receives such a configuration back from
relayout, it will force a layout of the client views
(see updatedConfiguration in performTraversals), this is because
Configuration#equals compares the non public part of the configuration
as well. This CL changes MSG_REPORT_RESIZED to handle the configuration
changing the same way performTraversals does, so that the app consistently
receives a configuration change.
Bug: 134643273
Test: Manual
Change-Id: If016bcd9a5b8d2a7efc5e1ab3c82a88a608caf8b
Annotates InputMethodSystemProperty#MULTI_CLIENT_IME_ENABLED as @TestApi
to let cts can verify if multi-client IME enabled.
Bug: 135217809
Test: build and passes
Change-Id: Id7b4dceb2dbfaf3d7ed1084957dd14b04cad0cdf
... as opposed to strong references.
In case the calls between register and unregister aren't matched, we don't want to be leaking views.
I haven't seen any real eveidence of there being leaks, just a report. But this is preventative.
Created a "WeakSparseArray", which wraps SparseArray, and passes in a kind of WeakReference that has an id.
The references become unreachable, we use the id to remove the the entry from the SparseArray.
Test: Used the device for a bit with talkback on. CTSAccessibility*
Change-Id: I8d11727428f56fc06007232ae341d1409a11991f
Fix: 134506015
failed to launch app resolver when there are more than one app handlers.
What happened:
1. TextClassifier constructs an implicit intent to fulfill a task
like opening a link, making a phone call, etc.
2. TextClassifier calls resolveActivity against the implicit intent to
resolve the intent. The resolve component name will be used to create
an explicit intent. In this case, the intent is resolved to the
app resolver activity.
3. wouldLaunchResolverActivity in SysUI returns false for an explicit
intent with component name android/ResolverActivity.
4. SysUI does not trigger the "start the activity after the keyguard
is gone" logic because wouldLaunchResolverActivity returns false.
5. When user clicks on the action on keyguard, ResolveActivity.onStop
is triggered because it is shown (and thus moved to the background)
under the keyguard. So, finish() is called in onStop, and thus the bug.
IMHO, wouldLaunchResolverActivity should not return false
for an explicit intent with component name android/ResolverActivity.
But since we are late at this point, the safest option is to not setting
component name when the intent is resolved to package "android". Note that
this is what we are doing for P, so it should be pretty safe.
Test: 1. Install two browsers. Send myself a link. Tap on the Open Link
chip on keyguard. App resolver is shown.
2. atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
BUG: 129220155
Change-Id: I6d4d67c2233a2fec950887ea274825bf1cbc1ae2
Currently, updateBoundsSurface was getting called when the surface
changed, not just when the size changed. This meant it could be calling
setWindowCrop and deferTransaction when no size had changed. If size
hadn't changed, there was a high possibility that no new frames would be
submitted by the client, causing the deferTransaction to wait forever.
Since the deferTransaction was still waiting, SurfaceFlinger would wake
up every vsync to check if it should call doTransaction for the deferred
transaction. This caused 60Hz composition even when frames were rendered
slower.
Fixes: 132110524
Test: SF doesn't compose 30fps app at 60Hz
Change-Id: Icf3a99b34c288575438bfcd05e9077ea7919b4ca
Fixes an issue where we would measure WRAP_CONTENT windows inconsistently
in the measure passes before and after relayoutWindow.
Fixes: 119839070
Bug: 73813813
Change-Id: I376e416d648f31a0dedecd6a70b476c3bf82b8b0
Test: Install test case app from 119839070, verify dialog is correctly laid out.
for logging in the default TC.
TCEvents for selection and links are not currently being written to
default TC logs. This changelist writes these events as SelEvents.
Bug: 131228248
Test: atest android.view.textclassifier.TextClassifierEventTest
Change-Id: I191f2f9281eab1b8a427ef21717fff283a304a22
Changes to view.mtransformationInfo.mAlpha outside of View.java weren't triggering subtree AccessibilityEvents.
This is a problem, because that property helps determine a views visibility in accessibility, and AccessibilityServices wouldn't be informed of this change in visibility.
This results in UIs with certain animations not being accessible at all.
This seems like an oversight to begin with, so it's a pretty low risk change.
Test: Tested the reported instance of this bug in Permission Manager, CTSAccessibility*
Change-Id: I02526e5659cf95f1373811008e74954a73addd21
Fix: 127589394
Bug: 132354626
Bug: 129117085
Test: skia unit tests and test cases described in the bug
Change-Id: Ieaa7c831dd6298ac0565e6f1837b1c1dbd4545da
(cherry picked from commit ac33a48751)
If application process handles motion events late, it requests to start
moving task after MotionEvent.ACTION_UP is already fired. In that case,
system will wait for event that is not comming and cannot end drag state.
It's expected that the system finishes moving task when system receives
ACTION_UP by transfering touch focus. In a problem case, ACTION_UP event
is already sent to the application process before transfering touch focus.
If application receives ACTION_UP event after requesting moving task,
notify the system of finishing previous request.
Test: Quickly try to resize freeform windowing app repeatedly.
Test: atest WmTests:TaskPositioningControllerTests
Bug: 129507487
Change-Id: Ifa457ddc55524cae6da455e770472781a7805282
(cherry picked from commit 9a1cd7b5063229da536a1281916ae15ec9246d1a)
