Provides defaults for java_sdk_library to that are equivalent to those
already used by the framework modules to simplify conversion.
* The java_api_finder is in the defaults as that should be used by
all mainline modules.
* The public/system/module_lib scopes are explicitly specified in the
defaults to include module_lib but exclude test as changing that
behaviour by default would break upwards of 24 existing
java_sdk_library usages.
* The stubs for each API scope is compiled against module_current
because if they compiled against the scope specific sdk version it
would create cycles for "current" and "system_current" because some
of the modules contribute to those.
Test: m update-api
Bug: 155164730
Change-Id: Icd5b893b080d3a8b92b11b856a71b700be96dafa
When trying to remove the starting window from an activity and
there is another new transition applied, the starting window
could not be removed because
1. ActivityRecord#startingDisplayed were set to false.
2. Cannot apply TRANSIT_PREV_DONE animation in removeIfPossible
because firstWindowDrawn and startingDisplayed are both false.
3. Because the task is animating, so it thought the animation is
applied and we should wait for #onAnimationFinished.
There are two things to do for fix this issue
1. Only set startingDisplayed to false when the starting window
must not exist.
2. Check the animation is applied for the starting window instead
check isAnimating for whole task.
Fixes: 154189349
Test: atest AppWindowTokenTests
Change-Id: I9bda35c792aaa4d0865b370faca09f1a90035c29
A windowless SurfaceControl could grant input via
IWindowSession.grantInputChannel, but other window may receive the
obscured events because of the type value of input window is always 0.
The obscured or partially obscured flag indicates that the window
received this motion event is wholly or partially obscured by another
visible window above it.
We have to filter out the trusted overlap so the motion event could
properly dispatch to the view if it is a security sensitive application.
Bug: 156063505
Test: enter split window mode and check the motion event
Change-Id: I10f63ea131a70ee8cc7d5c4b3e5ca4e5f06fdbad
* Don't clear inline suggestions when receiving VIEW_EXIT from
Autofill session
* Don't clear inline suggestions when IME becomes invisible
from IMS.onInputViewFinish(), instead only clear when
IMS.onInputFinish() is called
* Don't clear inline suggestions when launching an intent from
inline action chip (be it authentication intent or regular
action)
Test: atest android.autofillservice.cts.inline
Bug: 156099633
Change-Id: I8bebec3135410131e12c62e37b8a63a3702f7fac
We need to add modified WindowContainers to the BLASTSync set
before applying any changes. Recall that while participating in
sync window containers stop using the Display global
pending-transaction and instead redirect their changes in to the
BLASTSync-transaction. If we add to the BLAST sync too late, some
changes could go in to the WM transaction while others go in to
the BLASTSync-transaction. This means the effects would not be
applied atomically.
Bug: 149946388
Bug: 155814541
Test: Expand PIP. No flash.
Change-Id: I9b9b8f2308098d045a44004e2cca6dcbf84efcd9
Charging status is different from plugged status and can be used as a
state for certain metrics.
Bug: 140496920
Bug: 143495340
Bug: 145838040
Test: bit statsd_test:*
Change-Id: I1ef41191588b6d26346323203dabe488d488c131
* Imagine this event sequence:
1) the IME tries to re-attach an inline suggestion view to the
window (e.g. because IME layout changes), it calls into the system
server which causes recreating the backing view because it was
destroyed earlier due to 0 ref-count (this happens under the hood
without IME knowing it happens, so the view is still attached to
the window).
2) the IME receives a new inline suggestion pointing to the same
backing view (perhaps due to filtering kicks in).
3) the recreation from step 1 finishes, but now it will callback
to the new inline suggestion, therefore the old view doesn't receive
the new SurfacePackage. See RemoteInlineSuggestionUi for why.
4) the view in step 1 is detached from window, since it never
receives a SurfacePackage from the remote view, its detach shouldn't
cause a reference count down on the remote view.
Test: atest android.autofillservice.cts.inline (sanity test)
Bug: 154683107
Change-Id: I2e6814ef3889de603f6e170efcb795b69ec9febe
Previously the scroll position would never be reset anymore
unless the user actively did so. We're now resetting the position
whenever the visual stability manager tells us we're allowed to
do so.
Bug: 154137987
Test: atest SystemUITests
Change-Id: Ifd5858f47827610a64a9a12cff777bd2440334a9
This reverts commit f4580a24ab.
Reason for revert: someone submitted it by mistake
Bug: 156335617
Bug: 156010854
Test: see bug 156010854 for manual steps
Change-Id: Ia9e6b91eca5f47d35b54393cc7256fb54f58f276
