The underlying clearWallpaper() service method demands that only a
single kind of wallpaper be specified as the target; but a recent
patch attempted to expand the client-side legacy method to apply to
all kinds of wallpaper, incorrectly. This patch corrects that client-
side code to do things properly.
Bug 30456015
Change-Id: I0a881957b881206e5eb775c6879ba90f10f9ffb0
Bug: 31224514
Frameworks supported a mature mechanism for shader cache per each package already,
but as a special case such as Settings APP, if there are several packages in this
application which means that multiple packages shared the same SharedUserID with it,
it won't initialize the graphics disk caches, thereby APP like Settings have to
rebuild and relink shader every time during launch, which cause a bad launching
performance, so here to enable the GFX and RS cache initialization for multiple
shared packages case too.
Change-Id: If0f927e3399b775804abf1d9a868887951f471c5
Signed-off-by: Shuo Gao <shuo.gao@intel.com>
Signed-off-by: Zhiquan Liu <zhiquan.liu@intel.com>
(cherry picked from commit 7c69a669a5)
A recent fix prevented developers from specifying Holo-style mode when
displaying a date or time picker dialog. This CL also cleans up unused
code in TimePickerDialog and documents how themeResId will be used.
Adds hidden @TestApi methods for use in CTS tests. These may be made
public later, but it's too late in MR1 for API changes.
Bug: 31586821
Test: Ice2e203983769f1ea1cfa93105eb97b6fa5176b9
Change-Id: I1b7512b7647ddd7ab987beac2c0aef4fe7cc16bc
Makes it consistent with the regular stop code path and allows
for the activity to be relaunched with the right state if a
relaunch happens after stop due to sleep.
Bug: 30241363
Change-Id: I92edfe6e0e3f5c7ce3b56d49df31e601a798cd4f
Backup has some subsidiary UI needs that are vendor specific,
and policy state is not readily observable from there. We
therefore inform the sublaunched UI explicitly about the state
via an intent extra in the launch intent (rather than requiring
an API call from the launched UI).
Bug 30126678
Change-Id: I37f9530edbc00eea6c96f2c9fd67e878c07068c9
LoaderManagers configure their host callback lazily as their
associated fragment is brought up through its lifecycle states. In the
case of fragments on the fragment back stack this could happen very
late, if at all. As a LoaderManager's host callback references the
host Activity, this means that a LoaderManager could keep a destroyed
Activity reference alive.
Update the host callbacks of all LoaderManagers eagerly during the
restore non-configuration instance phase.
Bug: 30653222
Test: core/tests/coretests/src/android/app/LoaderLifecycleTest.java
Change-Id: I5d2b81daae5e7cae429fcf4934e64b3ce281140c
When support for lockscreen wallpapers was added in API level 24 the
behaviour for earlier API versions changed. Calls to the old 'set' APIs
no longer affect the overall device wallpaper, and can result in an end
user not being able to change their lockscreen wallpaper.
This upload restores the original API behaviour.
Bug: 31204228
Bug: 30456015
Change-Id: Ia16d2e2e379c54d798eef8f5c653099c2c581d78
Fix issue #30766518: Document what targeting N does
Also small documentation cleanup in a few other places.
(cherry picked from commit b34cbedb4e)
Change-Id: I9560b29faa4f2674277349272af8193122a1f95e
Switch to using more efficient countInstancesOfClasses method for
counting WebView and other kinds of instances.
Test: Launch Gmail, view a message, verify some WebView objects are
reported in dumpsys meminfo.
Bug: 31016396
Change-Id: Ib0146ee2931877399da07f854d50c2ab52092b6b
We can no longer return the "my_downloads" paths: if those Uris were
shared beyond the app that requested the download, access would be
denied. Instead, we need to switch to using "all_downloads" Uris so
that permission grants can be issued to third-party viewer apps.
Since an app requesting a download doesn't normally have permission
to "all_downloads" paths, DownloadProvider now issues narrow grants
toward the owner of each download, both at device boot and when new
downloads are started.
Bug: 30537115, 30945409
Change-Id: I533125b36444877f54373d88922f2acc777e250b
Allows PO and DO configure strong auth timeout for fingerprint.
Bug: 31430135
Change-Id: Ie6451d49aa95527adc3720d9a2a0848f58940510
(cherry picked from commit 8f010dd25d)
Work profile challenge is shown by intercepting normal activity launching and
replacing it with the confirm credential activity. For direct boot aware
activities, they should be able to be displayed when the work profile is
still locked, so add a conditional in the activity intercepting logic to bypass
work challenge in this case.
Also launching work profile activities from notification is handled specially
in order to avoid dismissing the notification if the work challenge is canceled,
so add similar logic there to allow direct boot aware activity to go through.
Bug: 30296144
Change-Id: Ib6395271cee2d4781009bb08d50351d73824de0c
When the docked stack is minimized and we are unminimizing it
due to a request to start it's currently paused top activity,
it is possible for the new intent not do be delivered immediately
because it isn't resumed due to another activity been launched in
the system (Recents) which is resumed instead. So, the user won't
see the effect of the new intent until they touch the docked activity
causing it to get the new intent and resume.
We now deliver new intents to the top activity in the docked stack if
it is in a minimized state. Then on the client side we temporarily
resume the activity and pause it again to guarantee onResume is called
after onNewIntent.
Bug: 31371093
Change-Id: Ib1764ccf5efc9d6498ce6cc8a34236c79fc07dad
The Fragments API guide was moved, but apparently a redirect was
never set up. Also, there are a few links to the old location in
the Javadocs.
Staged the revised Javadocs (see first comment for stage location).
Not going to stage the redirects file since it would trash another,
bigger CL that deals with the redirects file, but it's pretty
straightforward.
bug: 30559011
Change-Id: Ibd65f85c1ebb9789c1d40614fe11fe4ffda97e58
- Non-test-only DO/PO still can't be installed when there are
accounts.
- Test-only DO/PO can be installed even when there are accounts,
as long as all the accounts have the
"android.account.DEVICE_OR_PROFILE_OWNER_ALLOWED" feature.
Some authenticators claim to have any features, so to detect it,
we also check android.account.DEVICE_OR_PROFILE_OWNER_DISALLOWED
and disallow installing if any of the accounts have it.
- Also add logs on certain important events in DPMS.
Bug 28928996
Change-Id: I62efce10e9cc22e994ea8cae91a4fafcce25dd77
It was possible for apps to put toast type windows
that overlay other apps which toast winodws aren't
removed after a timeout.
Now for apps targeting SDK greater than N MR1 to add a
toast window one needs to have a special token. The token
is added by the notificatoion manager service only for
the lifetime of the shown toast and is then removed
including all windows associated with this token. This
prevents apps to add arbitrary toast windows.
Since legacy apps may rely on the ability to directly
add toasts we mitigate by allowing these apps to still
add such windows for unlimited duration if this app is
the currently focused one, i.e. the user interacts with
it then it can overlay itself, otherwise we make sure
these toast windows are removed after a timeout like
a toast would be.
We don't allow more that one toast window per UID being
added at a time which prevents 1) legacy apps to put the
same toast after a timeout to go around our new policy
of hiding toasts after a while; 2) modern apps to reuse
the passed token to add more than one window; Note that
the notification manager shows toasts one at a time.
bug:30150688
Change-Id: Ia1dae626bd9e22541be46edb072aa288eb1ae414
