This change updates the docs for the MATCH_UNINSTALLED flag to note that
without the QUERY_ALL_PACKAGES permission, uninstalled packages will not
be returned.
Bug: 149846504
Test: builds
Change-Id: Id0c5b7f29172bd334dc1b2a32ce1f4eb7b1f0bd3
* changes:
Apply fixed rotation when showing snapshot starting window
Only use snapshot starting window for the same rotation
Do not capture task snapshot with fixed rotated activity
The names of the individual modules do not quite follow the pattern
that java_sdk_library uses so this temporarily sets the following:
naming_scheme: "frameworks-modules"
That causes java_sdk_library to use a naming scheme that matches the
one used by the individual modules of this. It will be cleaned up
later.
Test: Removed API from current.txt, ran checkapi and it detected the
API change. Ran update-api and it updated the API txt file.
Added method without any nullability info, ran checkapi and API
lint reported issues as expected.
Bug: 155164730
Change-Id: Ifcdbfd77373710481343c9ff800543eaaa8c2ea8
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
Unlike splash screen starting window that inherits the size of
activity directly, task snapshot needs the final size to draw right
after adding to display. Otherwise the content will look like as
cropped because the surface size uses different orientation.
And because starting window is added before executing transition,
assume there will have transition if the owner of starting window
is also the top activity.
Bug: 155862858
Test: ActivityRecordTests#testFixedRotationSnapshotStartingWindow
Change-Id: Idb4f9a92a6e2594356416afd0ab6360e94e66497
So the snapshot won't show half if the its has a delta of 90 degree
rotation with the actual activity. If the snapshot is not compatible
with the activity, the starting window type will be splash screen.
Bug: 155862858
Test: atest ActivityRecordTests#testIsSnapshotCompatible
Change-Id: I8d8a926d057f1d18d028fcc03bddbb17ffbbf96b
Because the rotation of activity and task are different, The
information of snapshot may be inconsistent. And since it is a
temporal state, in most cases the snapshot is available after
the fixed rotation is cleared. This fixes a non-rotated snapshot
is shown on a rotated activity when repeating launch and swipe
to home quickly.
Also the fixed rotation launching app should not be cleared if
there is pending rotation, otherwise it is too early that the
display is still in old rotation. This fixes flickering when
switching between activities in different rotation from quickstep.
Bug: 155862858
Test: atest TaskSnapshotControllerTest#testPrepareTaskSnapshot
ActivityRecordTests#testActivityOnCancelFixedRotationTransform
Change-Id: I8e30e87ea4aad907c4ad4338b91fcff3078380ad
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
There are a few things the timeout was protecting against:
* IME taking too long to come up or failing to come up entirely - in
this case, the user cannot enter text anyway, so the incremental
degradation in UX from autofill not showing either is relatively
minimal.
* IME taking too long to send back the InlineSuggestionsRequest - this
would happen if the IME implementation is suboptimal. There's a valid
case for protecting against this, however there are many other ways
the IME can prevent Autofill from working correctly (e.g. just not
showing the chips) that we do not have a fallback for - so introducing
a fallback for just one of these cases doesn't seem worth the added
complexity.
Note: There doesn't seem to be any cleanup the timeout was doing that
needs to be handled.
Test: manual:
* switching focused view multiple times, also with a Thread.sleep(7000)
in the keyboard to make sure a delayed response works fine, also
tested with multiple partitions.
* smart reply, including clicking through from a notification
* interrupting pending request with manual request
Test: atest InlineAugmentedLoginActivityTest InlineLoginActivityTest \
AugmentedLoginActivityTest LoginActivityTest
Fixes: 154334419
Change-Id: Id934fe3be991b5d70e9e8cb3e37b0fd869d783b7
* 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
BtHelper.isBluetoothScoOn() should not return true if
the BT headset profile is not connected.
Bug: 154464603
Test: regression tests for calls over Bluetooth
Change-Id: I7c075977be79810cc57f06426fb9eec01c72606c
This reverts commit 0df8812486.
The original CL is trying to reduce the dependency of PownerManager to
finish input when screen off by using display state.
However, it doesn't fully fix the original Bug 26851566 since we only
finish input connection but didn't callback onFinishInput callback for
IME client.
Also, for some scenarios, the window / view focus may not change
during screen turns off / on:
- Focusing timing when disable keyguard, then quickly screen off / on.
- Using P-sensor to turning screen off / on.
When the above scenario happens, makes input connection cannot re-start
and soft-keyboard can't be shown.
(The recovery is manually focus on next window or activity.)
As the above reason, we need to re-consider the lifecycle of
input connection, window / view focus when not only screen state but also
device inactive state when always-on-display.
Fix: 156045961
Fix: 154605805
Bug: 26851566
Bug: 156215187
Test: atest CtsInputMethodTestCases
Change-Id: If06daf71160aa44a4254ac125561974ecbdef4f2
