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
There have been few breaking changes
1. TelecomManager.getCallCapablePhoneAccounts is not hidden anymore
2. CAPABILITY_VIDEO_CALLING is not hidden anymore
3. mPhoneStateListener doesn't exist anymore, so it is commented out
Change-Id: I22221eda73a20c745e316d9d56f914ab17b83533
merged from goog/mirror-m-wireless-internal-release
204f80e Add PHONE_ACCOUNT_ADDRESS to the call log DB.
Change-Id: I363403bf73b202f03b3f706a823b0f142183a695
merged from goog/mirror-m-wireless-internal-release
da35a2b Revert "Add PHONE_ACCOUNT_ADDRESS to the call log DB."
Change-Id: I4dc4865d58e4b68858c7767f201e267a72dc236b
merged from goog/mirror-m-wireless-internal-release
40c6f2b Add PHONE_ACCOUNT_ADDRESS to the call log DB.
Change-Id: I91b487137a2da621b496bf5f135fe19bb0a6ca62
When a call log entry is added, and it's phone account does not match a
currently registered one, we set it to hidden. This code was built for
the calllog restore case where call log entries would be hidden when
added if the original phone account wasn't also
present on the new device (where the restore is being performed).
We no longer do that so we're removing the code that sets any call log
entry to hidden.
Change-Id: I26ee27369e94c73446f7553f84cd4d8d4f2ff658
Added method to make it easier to insert into the voicemail status
table. Also takes in a phone account for future multi-SIM support.
Remove VvmSyncService class in favor of moving most of the code to
OmtpVvmSyncService.
Bug: 19236241
Change-Id: I5d9def276fbdbc6f825fb35e9fa31bfc3cead1ba
The settings constants for various volumes do nothing and are
used by nothing since API version 2. These are however backed
up in the cloud which is a waste of resource. This change
removes these constants from the SDK while keeping them hidden
to avoid breaking released apps and also prevents unnecessary
backup.
Change-Id: I2e91863115f5a4b997a14f8d0f57b4dc9689cfab
Enterprise phone lookup returns special photo URLs for corp contacts, which
can't be obtained just with contact IDs. So we need to cache the URIs too and
otherwise pictures sometimes don't show up.
Bug 19546108
Change-Id: Iffd5ed16527a143ea55e40e42667e7d0c16d814a
+ VvmSyncService is the base class for all visual voicemail sync
services that run the visual voicemail sync adapter. This class handles
writing to the voicemail provider and receiving changes from the
voicemail provider.
+ AuthenticatorService is a stub class for visual voicemail sync
adapters that do not use an Account (all sync adapters must have an
account associated with them, so a stub account is necessary).
+ Voicemail parcelable object to pass voicemail data around easier. This
is mostly copied from VoicemailProviderDemo
+ Extra helper methods in VoicemailContract to help insert and delete
from the voicemail provider.
+ Add multi-sim fields to VoicemailContract.Voicemails
Bug: 19236241
Change-Id: I603e3e5908704cd043e46221680d8bb600ed2cf4
In order to support multi-SIM visual voicemail, we need to record the
appropriate phone account in the VoicemailContract.Status table.
Bug: 19236241
Change-Id: I89742ab0aa7780de5cd525731685279ff5024c5e
Define the ContactsContract for a new QuickContact extra.
This can be used to tell QuickContacts to prioritize a
given mimetype.
Bug: 18391003
Change-Id: Ie5a93ad9e1919f470a638d4235d91fe337cb5ca3
Path can be null if sd card was ejected, and we shouldn't make a thumbnail
in that case.
Bug: 19380821
Change-Id: Iee69effdd321622de026ad7b57c74cf9da81a176
- Relax restriction on audio service calls that assume the volume
ui is systemui, allow calls from a blessed component app.
- Blessed component app service saved in secure settings.
- SystemUI mediates requests to replace the volume dialog, prompts
the user on activation.
- Show a low pri ongoing notification when the volume dialog is
being replaced, to allow user restoration at any time.
- Replace the controller management code in VolumeUI to use a
ServiceMonitor, backed by the new blessed app component setting.
- Add proper zen-related noman client wrappers, make avail to the
registered volume controller.
- Everything is still @hidden, no api impact.
Bug: 19260237
Change-Id: Ie1383f57659090318a7eda737fdad5b8f88737d4
This change modifies how global, secure, and system settings are
managed. In particular, we are moving away from the database to
an in-memory model where the settings are persisted asynchronously
to XML.
This simplifies evolution and improves performance, for example,
changing a setting is down from around 400 ms to 10 ms as we do not
hit the disk. The trade off is that we may lose data if the system
dies before persisting the change.
In practice this is not a problem because 1) this is very rare;
2) apps changing a setting use the setting itself to know if it
changed, so next time the app runs (after a reboot that lost data)
the app will be oblivious that data was lost.
When persisting the settings we delay the write a bit to batch
multiple changes. If a change occurs we reschedule the write
but when a maximal delay occurs after the first non-persisted
change we write to disk no matter what. This prevents a malicious
app poking the settings all the time to prevent them being persisted.
The settings are persisted in separate XML files for each type of
setting per user. Specifically, they are in the user's system
directory and the files are named: settings_type_of_settings.xml.
Data migration is performed after the data base is upgraded to its
last version after which the global, system, and secure tables are
dropped.
The global, secure, and system settings now have the same version
and are upgraded as a whole per user to allow migration of settings
between these them. The upgrade steps should be added to the
SettingsProvider.UpgradeController and not in the DatabaseHelper.
Setting states are mapped to an integer key derived from the user
id and the setting type. Therefore, all setting states are in
a lookup table which makes all opertions very fast.
The code is a complete rewrite aiming for improved clarity and
increased maintainability as opposed to using minor optimizations.
Now setting and getting the changed setting takes around 10 ms. We
can optimize later if needed.
Now the code path through the call API and the one through the
content provider APIs end up being the same which fixes bugs where
some enterprise cases were not implemented in the content provider
code path.
Note that we are keeping the call code path as it is a bit faster
than the provider APIs with about 2 ms for setting and getting
a setting. The front-end settings APIs use the call method.
Further, we are restricting apps writing to the system settings.
If the app is targeting API higher than Lollipop MR1 we do not
let them have their settings in the system ones. Otherwise, we
warn that this will become an error. System apps like GMS core
can change anything like the system or shell or root.
Since old apps can add their settings, this can increase the
system memory footprint with no limit. Therefore, we limit the
amount of settings data an app can write to the system settings
before starting to reject new data.
Another problem with the system settings was that an app with a
permission to write there can put invalid values for the settings.
We now have validators for these settings that ensure only valid
values are accepted.
Since apps can put their settings in the system table, when the
app is uninstalled this data is stale in the sytem table without
ever being used. Now we keep the package that last changed the
setting and when the package is removed all settings it touched
that are not in the ones defined in the APIs are dropped.
Keeping in memory settings means that we cannot handle arbitrary
SQL operations, rather the supported operations are on a single
setting by name and all settings (querying). This should not be
a problem in practice but we have to verify it. For that reason,
we log unsupported SQL operations to the event log to do some
crunching and see what if any cases we should additionally support.
There are also tests for the settings provider in this change.
Change-Id: I941dc6e567588d9812905b147dbe1a3191c8dd68
The ability to set EXTRA_MODE values on QuickContact
intents has existed for ages by setting the extraMode
parameter on showQuickContact().
Now we need a way for QuickContactActivity to read the intent.
Bug: 18777272
Change-Id: If5e4aa5757e62e942926a12a36345512d6fb66ca
QUERY_PARAMETER_VCARD_NO_PHOTO is used to avoid
attaching photos on vcards that get sent over NFC.
Large VCards can't be easily sent over NFC.
I'm deferring writing CTS tests till later.
Bug: 18777272
Change-Id: I6e3a7bf836978023225c709446b9113de05f6cef
