There were two different filegroups referencing the same last released
APIs. Delete the manually defined one and switch references over to use
the one defined by prebuilt_apis.
Bug: 155197156
Test: m
Change-Id: Ib15d2c08e6400546ca03de6bfd4e5cbcc938c992
This is a smallest possible change to fix the breakage.
This change will introduce a boot time regression, but unfortunately
there is no easy way around it. Will try to address the regression in a
follow-up CL.
Test: atest PackageManagerTest
Test: atest android.security.cts.PackageSignatureTest#testPackageSignatures
Bug: 155396683
Change-Id: If92b8ce6236a0ef38d228d0705ae4f5345066e64
This allows listener know task's orientation request change before
handling display rotation through IDisplayWindowRotationController if
they can register a local TaskStackListener.
Bug: 150409355
Test: atest WmTests:TaskStackChangedListenerTest#testNotifyTaskRequestedOrientationChanged
Change-Id: Id7bfc3e63329ce26d454b7e9c143e084e04dd365
DefaultPermissionGrantPolicy is run on user startup but also in other
cases. On user creation it loads a lot of data from the PackageManager
and applies a lot of permission state.
This change adds an abstraction layer to the
DefaultPermissionGrantPolicy that caches and delays the PackageManager
calls on user creation. As a side-effect it also duplicates the state by
UID as all runtime permission state is by UID.
If this is not for user creation NO_PM_CACHE is used which just forwards
the calls directly to PackageManager.
This carries around the PackageManagerWrapper to all methods which
causes a lot of trivial churn. Other options considered:
- Make it a field in DefaultPermissionGrantPolicy but this would require
outside code to create multiple DefaultPermissionGrantPolicy for
different use cases
- Make it a Thread-Local. This is brittle and causes overhead
Also: All app-op setting was removed as this is automatically handled by
PermissonPolicyService
Test: Created user: Before 800 to 1200 ms after ~450 ms spent in
DefaultPermissionGrantPolicy on sargo-userdebug
Fixes: 150405484
Change-Id: If77214a193a39fec2f311a3aea324ef07c2dfb42
Merged-In: If77214a193a39fec2f311a3aea324ef07c2dfb42
* Before this change, the suggestionRoot would intercept all touch
events so that it can optionally forward them to the IME process
to support scrolling, no touch event will be sent to the child
view through the regular event dispatching process.
* With this change, we move the touch event transferring (to IME)
logic from SuggestionRoot's onTouchEvent to dispatchTouchEvent.
Now the touch events before a scroll is detected will be sent to
the child chip view, and only the touch events after a scroll is
detected will be sent to the IME.
* This patch also move the OnClickListener and OnLongClickListener
from the root view to the chip view, since the touch events now
either goes to the chip view or to the IME process.
* Note that in order to achieve this, given that we can't change
the API, and there is existing OnLongClickListener registered
to the chip view, we have to add a @hide API to the View to
get the existing OnLongClickListener and attach a new one to the
chip view, such that we can do the additional work of sending
the long click event to IME, when the view is long clicked.
* This patch should also fix the a11y talkback mode bug where
double-tapping on the view doesn't autofill the value.
Double-tap and hold also works that it triggers the attribution
dialog.
Test: atest CtsAutoFillServiceTestCases (sanity test)
Bug: 155245913
Bug: 154149807
Change-Id: I6f7be1ea5c0955969abb4ccae0cb421423095c4d
If TalkBack (accessibility speach) is enabled, then
when a user switch is performed (by clicking on the
user switch buttons), the device will announce that
it is switching users.
Test: manual (enable TalkBack, create a Guest)
Bug: 151669162
Change-Id: Ifa4a7b13f9a423d1dfa55873879fce71ca3a1673
The implementation is pretty much a copy of
MediaSessionRecord#getStateWithUpdatedPosition.
Bug: 154352658
Test: manual - played music and checked that seek bar updated
Change-Id: Id494f01dd18095f5df6c0806f34a7a5c92ddaf35
Previously, we generally required fully qualified names for referring
to inner class constructors (like #Notification.Builder()) despite that
not being valid javadoc. Now, we properly support #Builder() syntax and
the old syntax will error.
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
(cherry picked from commit 4c4aa41272)
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
When writing UsageStats timestamps to disk in proto, we offset the time
by the begin time to save storage space. However, there was logic which
reset default timestamp values of 0 to begin time for those stats.
This CL standardizes how timestamps are written to disk in proto for
UsageStats and updates the parsers. Since backup and restore use
database version 4, UsageStatsProto is also updated in addition to
UsageStatsProtoV2.
Bug: 155149300
Test: atest UsageStatsDatabaseTest
Test: atest android.app.usage.cts.UsageStatsTest
Change-Id: I624e4d56c91762b56eb1c3be67cd8df033fcac95
Match specs from sliding in/out from the power button. Make sure all
popup windows are dismissed correctly to avoid them blinking on
animation completion.
Bug: 154755066
Test: manual
Change-Id: Ieb6468a29f3543cf9f69da1bd53f38fab76b26a5
The app which gets bound to use microphone in the background should be
holding the CAPTURE_AUDIO_HOTWORD permission.
Test: Verify current services still work
Verify that app without permission can't be registered
Bug: 155438570
Change-Id: I4b53c45bc74df4e91026e13c7e2bfa0f5461df52
