We now back up & restore the set of enabled notification listeners. Post-
restore, a listener that had been enabled on the ancestral device will be
enabled on the current device as soon as it's installed, matching the
user's previous configuration. After this has happened the enable/disable
state for that app is not "sticky"; disabling it again will work as
expected.
The infrastructure for accomplishing this is general: it can be leveraged
by any ManagedServices derivative. There's a bit of extra wiring in the
settings provider to support the restore-time information flow as well.
This is because ManagedServices -- like many other parts of the system --
monitors writes to the settings provider and does work in response to new
writes of the elements that it cares about. Unfortunately this means that
there is no way to use the BackupAgent's restoreFinished() hook to post-
process the restored data: by the time it is run, the ManagedService's
observers have already executed and culled any unknown components from
the description that was just pushed into settings.
As of this patch, the settings provider's restore logic knows that a
particular settings element will require a message to interested observers
about the restore-driven change. The message is delivered as a broadcast,
and is sent after the new value has been committed to the settings db.
Adding other system ManagedService handling that parallels this will only
require adding a new corresponding entry to the table of individual settings
for which the relevant "this settings element is being restored" broadcast
is sent, found in SettingsHelper.
(It isn't sent for all settings elements because very few settings elements
have semantics that require it; 3rd party code won't be running yet during
platform restore anyway; and sending up to hundreds of broadcasts during
setup & restore is far from ideal.)
Bug 19254153
Change-Id: Ib8268c6cb273862a3ee089d2764f3bff4a299103
Not yet working, unless you turn off SELinux enforcing.
We need to update SElinux to allow the system process
to give apps access to /data/system/heapdump/javaheap.bin.
Currently watching can only be enabled through the shell,
such as:
adb shell am set-watch-heap com.android.systemui 1024
The last number is the process pss size in bytes, so this is
asking us to warn if it goes about 1K which will be all the
time.
Change-Id: I2089e5db2927afca0bf01a363c6247ee5dcb26e8
A ChooserTargetService can be implemented by apps that wish to offer
additional deep-link targets for the system intent chooser to in turn
offer to the user. This allows apps to create contextually relevant
shortcuts for UI flows that would otherwise require several steps of
explicit disambiguation. For example, a chat app might offer one-touch
access to recent conversations when sharing a photo to it from
elsewhere.
The chooser implementation must limit the number of
ChooserTargetServices it elects to query in order to respect available
system resources. Only the system chooser is permitted to bind to a
ChooserTargetService.
Change-Id: Ia7e075ee649c51cf2035f20aee166c5a27d91aeb
Instead of a runs-forever periodic alarm that drives key/value backup
passes, we instead schedule-on-demand a trigger job that will kick off
the pass after a batching interval. The key semantic change is that
we now never wake for key/value backup work unless we've been explicitly
asked to do so. We also use a rather longer batching interval than
was previously the case.
Bug 19536032
Change-Id: Ie377562b2812c9aeda0ee73770dfa94af6017778
- cleanup thread issue and simplify native FingerprintService methods
- add new permissions and enforce them
- add fingerprint hardware detection API
Change-Id: I87c2243ea2412061f1e85b044138480d0161bcdf
android.media.action.USB_AUDIO_ACCESSORY_PLUG and android.media.action.USB_AUDIO_DEVICE_PLUG
were removed in a previous change.
Change-Id: I22d09b9a0eb4f6f29a31a50ed8bfa7e09c52b064
The ShutdownActivity was implemented in the system server
code, which is no longer part of the boot class path. This would
work fine when requesting a shutdown from the primary user, since
in that case the activity would be loaded in to the main system
process which also has the system service code loaded.
However, when executed from a secondary user, we need to spin up
a new system process for it; that system process is just a regular
app process, without the system service code, so *boom*.
To fix this, move ShutdownActivity to the framework jar.
Change-Id: Icb831cd6ed619da5feede5605c45ef177a892fbc
We have no code that listens for AudioManager.ACTION_ANALOG_AUDIO_DOCK_PLUG
and AudioManager.ACTION_DIGITAL_AUDIO_DOCK_PLUG
Change-Id: I96a746c84e5a4b17df1b9fbdbb5de77e6bc39714
Allows ManagedProvisioning to determine whether there's a
challenge and thus whether to disable NFC provisioning.
Other implementation option: new hidden boolean API method.
Can't think of benefit of new API method "isBlockInUse", other
than doesn't leak PDB size and is more explicitly tied to the
use case. Open to either impl if anyone has opinions on the matter.
Bug: 18508767
Change-Id: I28d2eb5a0837ff85cb91f140b17ce1dd843fe9d6
The current implementation uses a whitelist of package names. Use a
system|signature permission instead of rolling our own security and
add that permission to the existing set of whitelisted packages
(SystemUI and VpnDialogs).
In addition to being less of a security risk (using well-known methods
like Context.enforceCallingPermission rather than manually querying
PackageManager and checking UIDs for package names), this enables
other system-privileged apps to control VPN as needed per the below
bug.
Bug: 18327583
Change-Id: I38617965c40d62cf1ac28e3cb382c0877fb1275d
Also updates existing row and dialog layouts to use preferred list item
or dialog padding as appropriate, fixes incorrect activity themes, and
updates ChooseAccountActivity variants for Material.
BUG: 18314215
BUG: 18292562
Change-Id: I2fde4ba6db80d839104abdaa334a46ad1861600f
Move the android.telecom.* namespace back to @hide, and also mark it
with @SystemApi so that system-privileged apps can use them.
Bug: 18302450
Change-Id: I33ae1b9b0dfdb1c5eff51ca3c829196bcfc9411c
This is necessary/desired for two reasons:
1. UX around network scoring shipped with L despite lacking underlying
platform support. We do not want network scoring applications to
trigger this UX on L devices, and therefore we must break the contract
of what defines a network scorer so that apps build against the new
contract don't trigger the old UX.
2. As a start towards generalizing the term "score" for a potentially
broader role in the future, though that role is very much undefined.
Bug: 18160480
Change-Id: If228977513e32e45bc44dbeda24aa18436fdfca6
Make REGISTER_PROVIDER_OR_SUBSCRIPTION and REGISTER_CONNECTION_MANAGER
part of the public API so that they can be used by third-party apps.
Bug: 18114695
Change-Id: I1b8578cbc82e95ea78b4a2166f4a23650a0c375f
New design of capability switch for L.
Add new RIL requests:
RIL_REQUEST_GET_RADIO_CAPABILITY
RIL_REQUEST_SET_RADIO_CAPABILITY
RIL_UNSOL_RADIO_CAPABILITY
These commands allow the framework to communicate what the Radio
Capabilities for each logical modem has or should be using.
It can support 2/3/4G switch and has flexible architecture to support
future technology.
Change-Id: Iedf7f608d2ba3c06a883500f2d85abb98e69d9c1
