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
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)
Applies corner radius to Bubbles when expanded, based on
dialogCornerRadius theme attribute.
Test: manual -- Enable Bubbles, add one and expand, observe corners
Bug: 123545569
Change-Id: I88162a974534786b4ac8bed4e0fa1302bded9096
If a window is touched inside the touchable region, but outside of the
physical frame, the setting closeOnTouchOutside=True for this window
would mean that the window would close.
Currently, the window would close when ACTION_DOWN on the touchable
region happens.
However, with the new gesture nav, the KEYCODE_BACK would also be
injected. Normally, the KEYCODE_BACK would also close the window. But if
the window is already closed in response to ACTION_DOWN, the
KEYCODE_BACK event would cause the underlying window to close.
This could be confusing to the user, because in this case a single
action (swiping back outside of the dialog) causes 2 actions to occur:
the dismissal of the window, and the navigation back to the previous
screen of the underlying window.
To avoid this poor user experience, we instead dismiss the window when
ACTION_UP inside the touchable area happens.
UX impact:
This CL would not change the user experience for tapping to dismiss the
dialogs, because tap has a short duration between down and up (most
common usecase).
This CL would now allow the user to maintain the finger on the screen
outside of the dialog for an arbitrary amount of time, without the
dialog disappearing. When the finger is lifted, the dialog would be
dismissed.
This CL improves the user experience for gesturing back to dismiss the
dialog, because the dialog most of the time will dismiss and nothing
else will happen. However, there still exists opportunity to cause the
old behaviour. The window can receive ACTION_UP before KEYCODE_BACK is
injected by gesture nav.
Important! If BACK is received by the app after ACTION_UP is received
(can happen occasionally), then the we would still see 2 actions happen
in response to a single swipe. This issue is tracked in b/132735993, but
it is likely that it will remain in Q.
Bug: 131410670
Test: open any dialog (for example, go to settings->display->screen
timeout), then press outside of the dialog and hold. Watch that the
window is not dismissed. Then release finger. Watch that the dialog
dismisses.
Also, gesture back outside of the dialog area. Watch that the dialog
disappears and nothing else happens (but see the important note above
for exceptions to this).
Change-Id: I2e7c1bab986f019dc2f4640ff9f4151ebb96479c
The windows belong to a activity will be set to stopped state
when the activity is stopped. But the associated thread of
view root could be different from activity, that results the
inconsistent calling thread of surface callback, and maybe
some potential races.
Since the surface could be destroyed during traversal, also
add a check for callback notifySurfaceDestroyed to prevent
duplicated calls if the surface is released.
Bug: 130553315
Test: atest ViewRootSurfaceCallbackTest
Change-Id: Iea2cf8ff51118c0fa8c00a35c1d3e53c959ea754
This is so other TCs can have access to the smart indices fore each
event.
Note that TRON logs remain unchanged.
Bug: 132290431
Test: Manually verified.
> adb shell setprop log.tag.androidtc VERBOSE
> adb shell stop && adb shell start
> adb logcat -s "SelectionSessionLogger"
Use a custom text classifier
Observe that events in the same session as an AUTO_SELECTION event
log the AUTO_SELECTION events indices as their smart indices.
Change-Id: I109e6e71afc50a02fd81930f5ff1ec86dc47a039
A previous commit reverted the new SurfaceView background implementation
due to a Z-ordering issue (where previously the backgrounds were below
ALL SurfaceView rather than EACH SurfaceView). It's easier to solve this
with relative layering as this CL does, and then we can keep the new implementation.
The new implementation has some other bug fixes in it too (see linked bug
w.r.t to setZOrderOnTop) and so it's a win.
Bug: 132353087
Test: SurfaceViewSurfaceValidator
Change-Id: I07b6e601e57fce3adb8e5ea8e173c7d7904422ca
Each WindowContainer has its own pending transaction. These transactions
may be merged to the global one within WindowContainer.prepareSurfaces()
in a hierarchy-based order, not in a time-based order. It may cause
that a later surface operation overwritten by an earlier surface
operation. For example, atokenA.setLayer(t1, 0) was called earlier, and
then atokenA.setLayer(t2, 1) was called later. However, the layer of
atokenA might eventually be 0 because t1 could be merged into the
global transaction later.
This CL uses a single transaction per display to solve this problem.
Fix: 120282809
Test: atest SurfaceAnimatorTest
Test: Manual test with the steps in the issue.
Change-Id: Idca57d01d8be884369510642c2d9345b6ee4e3b1
We changed the SurfaceView background to be a boundless
child layer. However this was a semantic change. Each SurfaceView now
has its own background behind it instead of the backgrounds being
behind all SurfaceView. This causes an issue with some apps which
have an invisible SurfaceView hanging out for no particular reason.
Revert "SurfaceView: Correct comparison operator.",
"SurfaceView: Only show background when behind ViewRoot.",
"SurfaceView: Check correct OPAQUE flag for background visibility.",
"Correct SurfaceView background visibility.",
"Replace SurfaceView background with boundless color layer."
Bug: 123920952
Test: SurfaceViewTest. SurfaceViewSurfaceValidatorTest
Change-Id: I88ff31542ee0139d15c84ed2d6791c5cd455604b
