For an app to either send or receive content change notifications,
require that they have some level of access to the underlying
provider.
Without these checks, a malicious app could sniff sensitive user data
from the notifications of otherwise private providers.
Test: builds, boots, PoC app now fails
Bug: 32555637
Change-Id: If2dcd45cb0a9f1fb3b93e39fc7b8ae9c34c2fdef
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
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
Bug 30786309
If the Activity used in makeSceneTransitionAnimation isn't
the same one used in the startActivity call, a NullPointerException
could be thrown.
Change-Id: Id21c54fcf99b353feab62f7fc160997ed06e7d23
(cherry picked from commit 3289bfa289)
(cherry picked from commit a3edbf6a5d)
Mitigates an issue where a LevelListDrawable would constantly
be reloaded even if unchanged. To avoid this, small icons are
now only reloaded if they no longer point to the same resource.
Note that StatusBarIconView already has this logic.
Change-Id: I6be436e5cef7b7ca91a28edc413b1aaa0f1007d5
Fixes: 30496073
In the class description, fixed the reference link that points to the
Fragments guide.
Bug: 29007808
Change-Id: I3399e5f10c461eb6666a04f8829c6cde774948e0
* changes:
Improved the transition when clicking on the last notification
Fixed a bug that could lead to an empty notification
Removed contentDescriptions that hindered accessibility usability
Fixes a bug where setting a null bigLargeIcon would not clear it
Fixed the transition of the background of the notifications
Fixed a bug where the notification would fade out in a ugly way
This is a squashed rollup of backup/restore infrastructural work in
the N release. It intentionally omits semantic/API changes such
as the introduction of the onQuotaExceeded() callback.
This patchset should not be merged beyond M maintenance releases.
Bug 29617908
Bug 29848715
Change-Id: I1eb25ad07f3bbf1132198d8a233722c41f1ac4cc
An accidental side-effect of introducing the XML content file and its
domain semantic checking was that the shared-storage domain got
dropped on the floor. Now the mechanism understands what it means
again.
Bug 29999884
Change-Id: I22b99c96869683d1a92430f237dda54b170b8f60
Because we were also looking for legacy icons and the legacy icon
was always restored for old listeners, the icon would not disappear.
Change-Id: Id911d405e5ae00bf45e34368effbf67c2425a40c
Fixes: 30663590
Updates to progress bars are the main culprit in system
performance events caused by apps spamming the notification
service. Rate-limiting only updates allows us to set a lower
threshold wihtout the owrry of mistakenly dropping bursts of
notifications being quickly posted after a network sync.
Also reduce logspam caused by the rate-limit events.
Bug: 30132961
Change-Id: I49acda6a2831204da45e899ddd3d62d571d7174b
- When the cached UID state says a UID is in the background,
check with AM and get the latest state, since the state
might just have been changed.
Bug 30640208
Change-Id: If448f6f21f290fa0fc13550d9c740f56aa8bfce0
A lot of calling framework code expects a null value on failure,
and didn't catch the previous exception. There were some strange
corner cases where previously a null value was not checked for
in framework code, allowing the null Resources object to be
returned to the caller. Introducing an exception changed the
semantics and can crash certain apps.
Bug:30422475
Change-Id: I51d34ae43c9ec605a8790989c56cf85b815ff5b8
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: Icc8f8dbd060762ae1a7b1720e96c5afdb8aff3fd
