* Applications must now have ...permission.REAL_GET_TASKS to
be able to get process information for all applications.
* Only the process information for the calling application will be
returned if the app doesn't have the permission.
* Privilages apps will temporarily be able to get process information
for all applications if they don't have the new permission, but have
deprecated ...permission.GET_TASKS.
Bug: 20034603
Change-Id: I67ae9491f65d2280adb6a81593693d499714a216
(cherry picked from commit 9dbaa54f6834e013a63f18bd51ace554de811d80)
Larger OTAs (750 MB tested) are taking 3-4 minutes
to write, due to the O_SYNC needed to ensure that
the data is actually committed to disk prior to
reboot.
Bug: 18750317
Change-Id: Idfab3ffd0276df4548f69a09c72ad6f4a344b6e6
(cherry picked from commit 01c06dfb076b71cb72c4bff9175bec9d59d2efde)
A security leak was discovered whereby a malicious app could get the
IActivityContainer object from one app and use it to inject events
into another app. This fix removes the availability of the
IActivityContainer and replaces its one use with a method for
returning the information the IActivityContainer was used for.
Fixes bug 19394591.
Change-Id: Ib3cec25b25130cd8e098892c057742cfd575cfdd
The man bent over his hourglass,
A programmer of sorts. The day was green.
They said, "You have a blue hourglass,
You do not fire alarms when they're asked."
The man replied, "Alarms as they're asked
are changed within the blue hourglass."
And they said then, "But fire, you must
Alarms beyond us, yet themselves,
Alarms within the blue hourglass
That trigger exactly when they're asked."
---
Fix the delivery-fuzzing semantics that had been introduced in
81f9882b5aadd6a2289c9f521a06a7af5f35ebf0. That patch turned out
to be incomplete; in particular, alarms scheduled later might require
the validity of an already-scheduled kernel alarm even if they did
not affect the head alarm batch directly, and this was not being
addressed. For now, roll back the fuzzed delivery logic entirely.
(This is not a full revert because that patch also caused exact alarms
to be considered standalone for batching purposes, and we need to
preserve that new policy.)
Bug 18726690
Bug 18765436
This is a 'git revert' of 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0
*except* that this CL preserves the "exact alarms are treated as
standalone" portion of the original patch.
Change-Id: I54c763775877de5b6eeb5617544aa6100bb17526
cherry-pick from lmp-mr1-dev
* Inexact alarms no longer coalesce with exact alarms. The motivation here
is that exact alarms are far more likely to be wall-clock aligned, and in
general pulling all alarms toward wall-clock alignment is a bad idea.
* Wakeup times are now fuzzed within the target batch's allowed window
rather than being hard pinned at the start of the window.
Bug 18631821
Change-Id: Iefaf34eee3f2a6546abefc27e177ee2fdcff935f
(cherry picked from commit 81f9882b5aadd6a2289c9f521a06a7af5f35ebf0)
cherry-pick from lmp-mr1-dev
The code in place was inappropriately treating all recurring alarms
as non-wakeup for purposes of deferral. Worse, it was overriding the
"this deliverable batch of alarms includes a wakeup alarm" bookkeeping,
so could potentially cause inappropriate deferral of even standalone
wakeup alarms.
Bug 18591317
Change-Id: I2a62ed4badcaeb549c1ac4f086014aa829e45427
(cherry picked from commit 864d42eb96a9127b7d2f10ad11e709c24b4b4304)
The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations. This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.
We now backstop this very-friendly schedule with an increasingly
aggressive one. If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot. Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.
'Available' here means charging + device idle. If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.
A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time. If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed. If the element is not supplied on a given device,
the default backstop is 3 days.
Adds a new string to display in the upgrading dialog when doing
the fstrim. Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.
Bug 18486922
Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c
ProxyInfo.getPacFileUrl() can not be null. It will be equal to
Uri.EMPTY. Checking for null was causing global proxies to never be
disabled. Or more accurately, global proxies would be disabled, but
would reappear after a reboot.
ProxyInfo.getExclusionListByString() can be null. If no
exclusion list was specified, the proxy settings would not be
successfully saved, they would disappear after reboot.
Bug: 18453223
Change-Id: I1c27e5dca5b9664bb7468ea909bff489fa110a07
There was a window of time in Lollipop where we persisted certificates
after they had passed through a decode/encode cycle. The well-written
OpenSSL library was liberal when decoding (allowing slightly malformed
certs to be parsed), but then strict when encoding, giving us
different bytes for effectively the same certificate.
A related libcore change (0c990ab4a90b8a5492a67b2b728ac9a4a1ccfa1b)
now returns the original bytes verbatim, fixing both pre-Lollipop
installs and installs after that change.
This change recovers any apps that had been installed during the
window of time described above by doing a one-time check to see if
the certs are effectively equal.
Bug: 18228011
Change-Id: Ib82bd6db718d0490d7a26c9c1014b7c8457a7f2d
Turns off logging of responses from native daemon connector altogether.
Proper solution to follow in LMP MR1
Bug: 18260068
Change-Id: I25bc9cb61049a3efdd9a9cd11195864a04ef05fd
MediaProjectionManagerService had an active media callback which
was causing a service to be bound 100% of the time. Adding a
passive flag makes it only observe events, and allow the service
to only be bound when needed by apps requesting active discovery.
Bug: 18042409
Bug: 17969854
Change-Id: I1bfa6609e2aa507ee2ce227de50f0e5ae951e000
A few methods are found to be missing protection with system permission.
Add enforceAccessPermission() like other methods.
Bug: 17408780
Change-Id: I58a336b5cc9df2d195bdfe7b928898dde5ff169f
(cherry picked from commit b22d9ee0a364b10d488dd6a2e8ba69d5ca7f6258)
Waits for BOOT_COMPLETED when enabling system trust agents.
This fixes an issue where no agents were discovered because the
packages were not ready after an OTA.
Bug: 18065140
Change-Id: Ibff9948e1536e07f868d6b29f432923a137091e6
Updating the accessibility layer behavior to reflect the new
model where accessibility no longer overrides strong encryption.
Now enabling an accessibility service lowers the encryption
level but the user can bump it up in settings if desired.
bug:17881324
Change-Id: Ic60d760c267d3f934040a42e1963b179bd8b9f5f
Under certain circumstances when launching a new activity, the
topmost stack activity is moved to the front even though the
activity is being created in a different task.
This checks if the topmost stack task matches the desired
task and if not, moves the desired task to the top.
Also make activity dump ordering consistent.
Fixes bug 17721767.
Change-Id: I59397f31b629a208f3863887c57d6f6fb1f6e1f3
Apps can end up in priority mode by setting ringer-mode = silent.
Now they can leave priority mode by setting ringer-mode = non-silent.
(normal or vibrate)
Bug: 17884168
Change-Id: I54c853885f4ae9ee618041dd7ac6ab0663fc7b37
When restoring hundreds of apps on low-DPI devices, we end up sending
icon Bitmaps inline in the response instead of splitting into ashmem
regions. To avoid triggering TransactionTooLargeException, switch to
using ParceledListSlice under the hood.
Bug: 17926122
Change-Id: Ib4da6775e79d2fcb4aaea15f58ed998df203a5f9
This is needed to allow the always-on VPN to survive network
switches. In L, network switches are graceful, and in order to
switch to a network, the system first has to validate it using
DNS requests (from netd, running as root) and HTTP requests
(from NetworkMonitor, running inside the system_server).
This should also allow always-on VPN to work on networks like
T-Mobile that use 464xlat, fixing a bug that has been present
since K.
Bug: 9597277
Bug: 17695048
Change-Id: I0daa5707f2139339f9ececde0e73aac3bf23fdc3
Currently, the lockdown VPN adds firewall allow rules matching
the whole subnet that the server assigned, so for example if
the VPN server assigns it the IP address 10.1.23.5/8, it will
allow the whole of 10.0.0.0/8 to pass the firewall.
This is needlessly overbroad and has a particularly bad corner
case where if the prefix length is 0, everything is allowed.
Bug: 17695048
Change-Id: Idbec4b3aea0f72f9bdfd26dcd72d6a97d026fb12
The system should always be using new startActivityAsCaller() when
starting activities on behalf of someone else, to ensure that
security checks are enforced as the original caller.
Bug: 17983737
Change-Id: Ic40816a797cfdb13c0adb48b86ed4ed7d6aae8eb
Requests coming in while the service is still being brought up
were discarded. Changed to queue them so that they can be started
after the initialization is completed.
Bug: 17985588
Change-Id: Ic9d9cd2094b830c80dec54dd5ef6a18159a74dc7
Conflicts:
services/core/java/com/android/server/hdmi/HdmiCecLocalDevicePlayback.java
This is a squashed commit of the following changes:
1. Order apps by priority when performing boot dexopt.
(cherry picked from commit 65cde7d42d741c7d9aa2714a397b7333f688ab55)
2. Improve priority ordering of apps when performing boot dexopt.
Added core apps and updated system apps.
(cherry picked from commit 272bf3a274daff62995caf05da338c1f2a73dae3)
3. Stop boot dexopt when low on memory.
(cherry picked from commit 1d892dcb6b0ff3a50cc63e387667dc29baf1014f)
Bug: 17641843
Change-Id: Ie32f1c21047d3462aaf728f7633fecf647ba2b47
...handler for its Intents
Fix bug when a third party app is installed as an additional but
worse match for the intent.
Also raise up the limit for when we start printing logs about
overly large strict mode data.
And turn off the logs about services being created and destroyed,
since with the way things are using services these days these have
become way too spammy.
Change-Id: I8fe301dfd80fb4b70213cb7783b7c5426245278d
...even in extreme low memory condition
Bind to Bluetooth with BIND_IMPORTANT, so that it is allowed to
go to a higher oom adj level.
Fix some problems when this is done from a system or persistent
process, where this would go to a level that is *too* high. Instead,
introduce a new oom adj level for it that is right below persistent.
Change-Id: I002bcc4accc36c8579c4cda161be7d2fba21ba17
This is a follow up CL for I2237ded850a0d4ab43ca441d0b7df1.
Seems that we still need to update config settings every
time when "Show input method" is changed.
BUG: 17666032
Change-Id: I480aeaa038bef9c3c20e8f0b36110e92a35809db
- Add docs to Binder, Messenger, ResultReceier to explain their
relation (or lack there-of) to process lifecycle.
- Clarify some aspects of process lifecycle for services.
- Fix help text of am command.
- Fix per-package dumping of battery stats to not include history.
- Fix per-package dumping of proc stats to only include aggregated
and current stats and fix some formatting.
- Fix per-process dumping of meminfo to have an option to interpret
the input as a package, so including all processes that are
running code of that package.
- Fix top-level per-package debug output to correctly include all
of these improvements and give them a little more time (10s) to
complete for timing out.
Change-Id: I2a04c0f862bd47b08329443d722345a13ad9b6e2
