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
We now have the activity manager kill long-running processes
during idle maintanence.
This involved adding some more information to the activity manager
about the current memory state, so that it could know if it really
should bother killing anything. While doing this, I also improved
how we determine when memory is getting low by better ignoring cases
where processes are going away for other reasons (such as now idle
maintenance). We now won't raise our memory state if either a process
is going away because we wanted it gone for another reason or the
total number of processes is not decreasing.
The idle maintanence killing also uses new per-process information
about whether the process has ever gone into the cached state since
the last idle maintenance, and the initial pss and current pss size
over its run time.
Change-Id: Iceaa7ffb2ad2015c33a64133a72a272b56dbad53
Multi project change:
The changes in this project add the new (hidden) default sms application
setting to Settings.Secure and updates AppOps to support the concept
of an op defaulting to something other than allowed. OP_WRITE_SMS is set
to default to MODE_IGNORED.
Bug: 10449618
Change-Id: I37619784ac70c27cf9fbcbfcac1b263398bc4e01
In DevicePolicyManagementService, on boot and when certs are installed,
post notification to tell the user that their traffic may be
monitored.
Have QuickSettings use the MonitoringCertInfoActivity instead
of building the dialog itself.
Bug: 10633199
Change-Id: Ie4b97295a9fc25867c87872feccdb17f4bea071d
This API and functionality is not yet completely baked. It's worth
thinking more about this mechanism before exposing it as public API.
Issue #10461415 KLP API Review: Activity convert to translucent
Change-Id: I94d986b62443b3bfa7a9a19807ecebe36bf57e07
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
Reverts extension to assist context API to query
foreground services for assist context data.
Also hides Intent.ACTION_VOICE_ASSIST because
nobody's actually using it yet.
Bug: 10461702
Change-Id: Idf6836adc659b434e11ebb2b98e8b814c94a7227
Make it a little easier to diagnose input dispatch timeouts by
providing the detailed reason as the ANR annotation in the log.
Bug: 10689184
Change-Id: Ie18fd9ad066b0673d1f57c030e027ad0085f4650
The services themselves already handle 'null' to mean "no observer";
it was just the non-AIDL marshalling code that wasn't doing the
right thing.
Bug 9588299
Change-Id: I99e26cd207f91e8060d9fc113aef90a106640b64
We now keep track of which process and service states are actively
in use, and remove any that are not in use during a commit. The
activity manager needed to be tweaked to report this data, and ensure
it does not try to operate on one of these structures when not in
use.
Also some other fixes:
- We now keep track of process names associated with services, for
display in the UI.
- Keep track of total run time for each service, also for UI.
- The parceled format is more efficient, not storing duplicates of
process/package names, and writing times as ints when possible.
- Reduced commit period from 1 day to 12 hours, so that our UI can
be a little closer at its attempt to display the stats over 1 day.
Change-Id: Ifeda0ffe963a7b49d8eb2a3f6923f3a5e71a4e43
The calling package is important for ContentProviders that want to
grant Uri permissions as a side effect of operations, so offer it
through a new API. Validates the provided package against the
calling UID before returning.
Bug: 10626527
Change-Id: I7277880eebbd48444c024bcf5f69199133cd59e4
This API allows an application to cancel deferred high-level input
events already in flight. It forms one tool of several to help apps
debounce input events and prevent things like multiple startActivity
calls, FragmentTransactions, etc. from executing when only one was
desired since it's otherwise not desirable for things like click
events to fire synchronously.
Change-Id: I60b12cd5350898065f0019d616e24d779eb8cff9
Un-@hidden in api 18, but probably should not have been.
The framework currently takes no action based on the flag,
making the docs misleading.
Bug:10460791
Change-Id: If6cc8791a85710897c8fe77cf6682d1460e3416e
CaptioningManager is now a first-class service in Context and can
have listeners added to it to monitor changes.
BUG: 10260603, 10461210
Change-Id: I2df5b2997537bb343d902b7ace3343ad483f3717
This lets components outside the Zygote / Android resource regime
know whether this is considered a "low ram" device.
Set the property [ro.config.low_ram] to "true" if the device is to be
considered low-ram. Any other property string (or its absence) will
be interpreted as meaning this is a normal larger-ram device. The
"true" string must be all lower case.
Bug 10131789
Change-Id: I15332d169b4aa4eaa0a6c1952787af0b03d23a6b
1. If app clears transient flag w/ a gesture, the touch-outside
listener would always win, causing an unsightly hide + immediate
reshow. Instead, give the app some time to clear the flag, then
perform a smooth transition in place.
2. When the transient bars are hidden, we do not know ahead of time
which background will be used on reshow (if transient bars are
revealed, the background is semi-transparent, if transient bars
are cleared, the background is opaque). Window manager is responsible
for showing windows, but sysui is responsible for setting the view
background. Therefore, we need some level of coordination between
the two in this case. Introduce two new non-public sysui flags
that represent the window manager's request to reshow the hidden
bars, but do not reshow until sysui acknowledges (by clearing the flag).
This gives sysui whatever time is necessary to prepare itself for
reshow, avoiding unsightly blip from opaque -> transparent during
the enter animation.
3. When both system bars are hidden, any low-profile changes are
moot. Avoid unsightly low-profile animations during bar reshow
by suppressing the flag in this case.
4. Improve transient bar home -> launcher transition by cancelling
the -> opaque animation. This also fixes a bug where hitting
home from the transient bar would leave you with a semi-transparent
bar in a non-transient state.
Bug:10284800
Change-Id: I238210561d8d5f70c1a517283b986c9105a1ec75
Guard install/uninstall by enforcing that the caller have the new system-only permission MANAGE_CA_CERTIFICATES.
Also include API methods for asking whether there are any User CA certs
installed, or if one by a particular name is installed in the keystore.
CA certs will be installed via KeyChain into the TrustedCertificateStore.
Bug: 8232670
Change-Id: I17b47a452e72eb4fe556dc6db823a46c6e854be8
