Prevents the dump actions from being blocked by traversals.
Removed a stale comment on queueOrSendMessage and renamed it to
reflect its current implementation since it no longer has a secondary
queue. Removed an unnecessary lock as well.
Bug: 10948648
Change-Id: Ic5fcc567212fb9cc07566c12f5f419af13c2b0b1
Currently it's possible for the home application to suggest new
wallpaper dimensions and the WallpaperService to request the bitmap
between when the new dimensions have been propagated and the old
bitmap has been forgotten. This leads to the WallpaperService
drawing a Bitmap with the old dimensions into a Surface with the new
dimensions.
By forcing the WallpaperManager to forget the old Bitmap immediately
before we reload it, we can ensure that we always have a Bitmap of
the correct size.
Bug: 10853302
Change-Id: I298ac5f3f8bcde54eeb1e45d21bf2ba3cbb618c9
getCropAndSetWallpaperIntent should only accept URIs with
the content:// scheme, so that the receiving application
doesn't crash opening a file it can't access.
bug:11173560
Change-Id: I855496633b646373db757e9d8e6e425568103b8b
This enables apps to discover and clean up persisted Uri grants when
the underlying Uri becomes invalid, such as when an account is
removed.
Bug: 11142566
Change-Id: Ieeb36cb1155acf226327ebe91cdd30b822d69d1b
When an app has already been started, and a ContentProvider component
is enabled with DONT_KILL_APP, use the existing ProcessRecord to
install the provider.
Bug: 11118692
Change-Id: I990f18b337eb19768ee1db895f1e2eb982046cce
mProvider is HashMap<ProviderKey, ProviderClientRecord>. String
is not correct object for KEY. Complete removal using iterator.
Bug: 11086495
Change-Id: I51e4576544ef02ede6f96938689dd4e43ec6eb4f
For the new documents work, we're only interested in the subset of
ContentProviders that actually implement DocumentsContract. Instead
of returning all providers, add <intent-filter> support to make it
easier to limit the set of returned ProviderInfo.
Define a well-known action for DocumentsProviders, and start using it
when querying for roots. Continue supporting the old <meta-data>
approach until all apps have been updated.
Bug: 8599233
Change-Id: I05f049bba21311f5421738002f99ee214447c909
Not enough time to fix everything, so instead we'll make it a warning
in this release and finish up turning it into a target-SDK based
exception in the next release.
Change-Id: I5aae64a1225a145f03ba4162238b53d5e401aba2
Apps that run components in separate processes, especially that
host providers in separate processes, can hit a race condition
where two processes simultaneously discover that the files/cache
dir must be created, then each calls mkdirs(). One of these will
fail not because the dir couldn't be created, but because it lost
the race and mkdirs() returned false to signal that it already
existed -- and this was assumed to be a hard failure.
We now recheck existence after a mkdirs() failure to discern this
case and proceed appropriately.
Bug 10515463
Change-Id: I13fbdd838921223f75ab11faa47291c82b21c650
All ContentProvider calls are currently blocking, making it hard for
an app to recover when a remote provider is wedged. This change adds
hidden support to ContentProviderClient to timeout remote calls,
treating them as ANRs. This behavior is disabled by default.
Update DocumentsUI to use a 20 second timeout whenever interacting
with a storage provider.
Bug: 10993301, 10819461, 10852518
Change-Id: I10fa3c425c6a7225fff9cb7a0a07659028230cd3
- Calling build() on a Style now goes through the same
codepath as calling build() on the Builder.
- Documented new constants and unhidden classes.
- Fixed crash in Action.clone().
Bug: 10112103
Bug: 10461196
Change-Id: I08cd94790b538a361ccf8ff3682f6a86a7812b95
Now when memory low, if a service's process is above
a selected pss, then the process is not allowed to go
in to the service a list.
Also simplified the normal meminfo details dump to not
include the shared dirty and shared clean sizes by
default, since these can be very confusing. You will
still get to see them with the "-a" flag.
Finally some small steps to better managing service
processes in the LRU list, so hopefully we can some
day be better about letting them drop down in the list
when there isn't really much interesting happening in
the process. Not yet used at this point.
Change-Id: I654bfd6d05de2a63120185ebb15ffda8cbeb5dac
Change our Intent flag to indicate that a Uri permission grant is
persistable, but don't actually persist it until explicitly taken by
the receiving app. This prevents apps from spamming each other if
persisted permissions aren't really required.
Remember the last time a persisted grant was taken by an app, and
use this to prune away the oldest grants when the number of grants
grows too large. Allow apps to query persisted grants they are
holding, and allow them to release previously persisted grants. Add
public UriPermission class to return grant details and timestamp.
Track various permission strengths separately, and combine together
after each mutation pass. Persistable grants are currently treated
like global grants, but they could be moved to have owners in the
future. Require that grant holders trying to extend a persistable
permission actually hold a persistable permission themselves.
Bug: 10835779
Change-Id: I95b2f797c04ce7fd2612f9a644685dbd44e03759
Uses new column to mark writability. Also filter file selection in
create mode to only allow writable files.
Bug: 10667164, 10893268
Change-Id: I90f74efbb7ac634fbdb3cc02a904a96a434d3605
ParcelFileDescriptors now carry an optional socket fd to communicate
close events. So, make sure that the correct creator is called when
reconstructing parceled PFDs.
Bug: 10759966
Change-Id: Ic6b9ffb8cb7af5f3a12440def595f74682231866
Changed public constants from integers to strings. Internally
everything is still integers, since we want that more efficient
representation for most things.
Changed the Callback interface to OnOpChangedListener. We also
have a private versin that again takes an int, and tricks to
make both work.
Reworked the class documentation to be appropriate to the SDK
(as much as it can be); most of the existing documentation is
moved to the private implementation. Also added documentation
of the MODE constants.
Change-Id: I4f7e73cc99fe66beff9194e960e072e2aa9458f8
Apps without sdcard_r or sdcard_rw are still able to write to
their package-specific directory, but someone needs to first make
that directory on their behalf. This change will delegate the
mkdirs() call through to vold when an app fails to create directly.
MountService validates that the path belongs to the calling user, and
that it's actually on external storage, before passing to vold.
Update Environment to make app-vs-vold paths clearer.
Bug: 10577808
Change-Id: I43b4a77fd6d2b9af2a0d899790da8d9d89386776
...be uncached and too large
When the device is in a low RAM state, when we go to pull a cached
process out to use for some background operation, we can now kill
the current process if we consider its size to be too large.
Note that the current implementation for killing processes is to
just use the same killUnneededProcessLocked() method that we already
have for other things like too many cached processes. This is a
little wrong here, though, because in this case we are at the
point where the caller is actually looking for a process to use.
This current code is not actually removing or cleaning up the
process, so we still need to return the now killed ProcessRecord
and let things fall out from there, which typically means the caller
trying to make an IPC on it and failing and falling into its "oh
no the process died unexpectedly" path. All code using this
*should* be able to handle this correctly, anyway, since processes
really can be killed at any time.
At some point we may to make this implementation cleaner, where it
actually tears down the process right in the call and returns a
null ProcessRecord. That is very dangerous however (we'd need to
go through all paths into this to make sure they are going to be
okay with process state changing on them like that), and I'm not
sure it is really worthwhile. This intention is that killing
processes like this is unusual, due to processes being too large,
and anyway as I wrote all of our incoming code paths must already
be able to handle the process being killed at this point and one
could argue this is just another way to excercise those code paths.
Really, the main negative to this is that we will often have spam
in the log with exceptions about processes dying unexpectedly.
If that is the only issue, we could just add some conditions to
quiet that up at in this case.
We don't want to compute the size of the process each time we try
to evaluate it here (it takes 10s or ms to do so), so there is now
a new field associated with the process to give us the last pss
size we computed for it while it was in the cached state.
To be able to have better cached pss data when we now need it, the
timing for computing process pss has been tuned to use a much
shorter delay for the situations when the process has first switch
into a new state. This may result in us having a fair amount more
pss data overall, which is good, as long as it doesn't cause us to
be computing pss excessively and burning cpu.
Procstats now also has new state to keep track of the number of
times each process has been killed by this new system, along with
the min, avg, max pss of all the times it has happened. This has
slightly changed the checkin format to include this additional data
at the end of pkgkills/prockills lines.
Other changes here:
- Fixed a problem where GPU RAM was not being seen when dumping
the full RAM details of a process. This was because in that
case the system would ask the process to compute its own MemInfo,
which it returned, but the process doesn't have permission to
access the files containing the GPU RAM data. So now the system
always computes the MemInfo and hands it to the app.
- Improved broadcast delays to not apply the delay if the next receiver
of the broadcast is going to run in the same process as the last
one. A situation I was seeing was an application that had two
receivers, one of which started a service; we are better off letting
the second receiver run while the service is running.
- Changed the alarm manager's TIME_TICK broadcast to be a foreground
broadcast. This really should have been anyway (it is supposed to
go out even minute, on the minute, very accurately, for UI elements
to update), and is even more important now that we are doing more
things to delay background broadcasts.
- Reworked how we maintain the LRU process list. It is now divided
into the two parts, the top always containing the processes holding
activities. This better matches the semantics we want (always try
to keep those around modulated by the LRU order we interleave with
other cached processes), and we now know whether a process is being
moved on the LRU list because of an activity operation so we can
only change the order of these activity processes when user operations
happen. Further, this just makes that common code path a lot simpler
and gets rid of all the old complexity that doesn't make sense any
more.
Change-Id: I04933ec3931b96db70b2b6ac109c071698e124eb
* Make sure that pm.getHomeActivities() returns the activity metadata
as well, so that the caller can trace the reference
* Add a public canonical name for that metadata key
Bug 10749961
Change-Id: Ic4d0750d61001ffe5af180398f042afa30eea1ce
