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
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
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
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
Change-Id: Ia16d2e2e379c54d798eef8f5c653099c2c581d78
