Bug: 130151718
Bug: 132179354
Test: Switch between gesture nav modes, ensure that system and sysui are
in the right state
Change-Id: I364d155292fc378af552b6ce9e6acca879224693
This allows Bubbles to be collapsed instead of finished
when there is only one activity in the stack.
Bug: 126852149
Test: launch activity, press back
Change-Id: Iad8db0549853e3f385d54fc6b6cea5e502d37139
* changes:
Add calling package parameter to IRcs methods
Use injected instance of RcsControllerCall
Create new RcsMessageQueryResultParcelable
Create new RcsParticipantQueryResultParcelable
Create new RcsThreadQueryResultParcelable
Currently only for the ContextImpl.enforcePermission code paths and only
when 'secure debug_package_permission_check' is set.
This feature is disabled on user-builds.
Test: Enabled permission checking for my app and
- checked runtime permision denial
- permission denial because app is instant
Bug: 111075456
Change-Id: Ib85777db69ee490608e9dac32a3b97971c0ba215
- Normally this will be picked up in the next GC, but there is no reason
to wait
Bug: 129295298
Test: Manual
Change-Id: I945336e86d0980f926586cfba6327c8c6c142ce8
With my previous CL [1], CursorAnchorInfo API was globally disabled
for cross-display scenario including ActivityView scenario.
This CL slightly relaxes the above condition so that IMEs can rely on
CursorAnchorInfo APIs again to interact with apps running inside
ActivityView.
The basic idea here is keeping reporting relevant information from
ActivityView to InputMethodManagerService (IMMS) so that IMMS can take
the display hierarchy because of ActivityView into account. As long
as IMMS has the up-to-date hierarchical information, IMMS can tell
InputMethodManager (IMM) running in the IME client process about the
missing coordinate transformation information from the virtual display
space to the outer display space where the IME is actually shown.
Note that there was a similar fix for AccessibilityService that keeps
reporting ActivityView location to WindowManagerService (WMS) [2].
Ideally we should be able to share the logic, but to do so we need to
introduce a generalized callback mechanism into WMS so that IMMS can
be notified when a cetain coordinate transform matrix has changed.
For Q, this CL implements IMMS's own mechanism to keep track of
ActivityView hierarchy instead of introducing a direct dependency from
WMS to IMMS.
For R+, most likely we may want to reconsider how ActivityView should
be implemented.
There should be no behavior change in this CL if ActivityView is not
involved.
[1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
3d2cc0fffd
[2]: I38da5b84a11890bf0f4a57eb9d5b7e71bdcc16a9
d8ec938609
Fix: 115693908
Test: atest CtsWindowManagerDeviceTestCases:ActivityViewTest#testInputMethod
Change-Id: Id0411a80456182111bb5b681c6d1230b58e7ec2e
Currently, the translation of the transformation matrix computed by
WindowState.getTransformationMatrix is related to its own display.
However, if the display has been re-parented, the translation might
be misplaced to the visual result. This CL makes it return the global
transformation matrix.
Bug: 129098348
Test: atest WindowStateTests
Change-Id: I38da5b84a11890bf0f4a57eb9d5b7e71bdcc16a9
Android Q introduce the FLAG_DELAY_SAVE, which allows the autofill service to delay the SAVE UI by
keeping the session open. But this approach introduces a new problem, as fields from different
activities could have the same AutofillId.
Test: atest MultiScreenLoginTest#testSaveBothFieldsCustomDescription_sameIds
Test: atest AutofillIdTest
Test: atest CtsAutoFillServiceTestCases # sanity check
Fixes: 113593220
Change-Id: Ibd187f5c58c150f820972fcab6d88217294ffe2d
This reverts commit 02014297fd.
Reason for revert: QT SDK Finalization. Will be merged again on/after May 13th
Bug: 129975435
Change-Id: Ia054b193a982dee669630555974d2d7831fe2b50
Instead of static methods, create an instance of RcsControllerCall that
holds a reference to the Context and inject it where it is used.
This will be used in a follow up commit that will require the calling
package name be passed when calling IRcs methods.
This change will allow passing a calling package name to an
RcsServiceCall or an RcsServiceCallWithNoReturn, so uses of the call
method might look something like:
```
mRcsControllerCall.call((iRcs, callingPackage) ->
iRcs.getFileTransferContentUri(mId, callingPackage));
```
Alternatives to storing the context here would have been:
1. To store the context everywhere the RcsControllerCall is injected and
get the calling package name at each RcsControllerCall call
2. To store the calling package name everywhere that the
RcsControllerCall instance is injected
Compared to solution 1, the implemented solution avoids repeating the
logic of retrieving the calling package.
Compared to solution 2, the implemented solution does not introduce any
complexity. In addition, the individual classes do not care about the
calling package name outside of the need to pass it to an IRcs method.
In the future, the implemented solution may also provide a useful point
to provide logic involving calls and the context (or other injected
dependencies). Though this future concern is not alone enough to justify
the solution, since the solution adds no additional complexity against
other solutions, it seems like a nice benefit.
Note, to avoid polluting this commit, a follow-up issue (b/128029441)
has been created to adjust the name of RcsControllerCall to reflect that
an instance of RcsControllerCall does not represent a single call to
RcsController.
Bug: 123699565
Test: Existing tests pass
Change-Id: Ib0f55f14397e5eb1e5a55864094c0be0c4e37c06
Merged-In: Ib0f55f14397e5eb1e5a55864094c0be0c4e37c06
This change attempts to fetch the unbadged icon from ApplicationInfo for
a given PackageInfo before falling back to the default (badged) icon.
Test: manual; verify that TestDPC is only badged once when viewing device admins
Fixes: 112254944
Change-Id: I55026af543ff71ac0d947159bc6aeb3b33f31271