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
+ 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
Path can be null if sd card was ejected, and we shouldn't make a thumbnail
in that case.
Bug: 19380821
Change-Id: Iee69effdd321622de026ad7b57c74cf9da81a176
Since optimistic addresses are useable upon kernel notification
there is no need for this extra connectivity delay.
---
This functionality was originally submitted in ag/572619. Owing
to issues with bind()ing to optimistic addresses (see b/18609055)
this was reverted in ag/598673.
This reverts the revert. :-)
Bug: 17769720
Change-Id: Ibee490b2af72050693b6bd748193f51e312ca527
Fixing a bug where a NetworkRequest's PendingIntent can be sent more
than once when networks are rematched before the intent completes.
Added a small delay before removing the request to give the receiving
client an opportunity to put in its own request. The delay value is
configurable via Settings.Secure.
Bug: 18614074
Change-Id: Iac7c5e5a04f42f2b6794e9e22349cc631bebeab7
This is the revert of ag/572619.
This reverts commit 9261d9d645, reversing
changes made to 32b61ab28f.
Bug: 18609055
Bug: 17769720
Change-Id: I122eba200f2071d4e5777ec34c1d04fb567345a8
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
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
To prepare for controlling from settings.
While here, add lock to app settings to backups.
Bug: 16957435
Change-Id: I059140cd07a7a0d5ceb4e0bfe5e0176cb96629d3
Once optimistic addresses become useable upon kernel notification
there will be no need for a connectivity delay.
This change requires kernel changes like:
https://android-review.googlesource.com/#/c/109934
Bug: 17769720
Change-Id: I8510c540aa655aad6a82ee322d591331357ee272
Fix the value of the ACTION_NOTIFICATION_LISTENER_SETTINGS constant
to be the actual value to which the settings app responds.
Bug: 10023397
Change-Id: I80a0ff76406a3b0b893793f9a63ffa563dae103b
We migrated to pure XT stats a long time ago, so we no longer need
to keep the DEV stats cached in RAM. This saves ~250KB on a typical
device.
Bug: 18118003
Change-Id: I3d84ba47073fa3500454784afc956c8e53404492
