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
Names are based on recent suggestions from the API council, such as
implemented inside ag/540453.
Bug: 18777272
Change-Id: I17a5b7cb4d4c5a0ba48936a6fc829acaab73f31d
Additional unbundling from ContactsContract.
I'm going to remove all parameter types except name.
None of them have been implemented since they were
defined in ICS.
Bug: 18777272
Change-Id: I5c4066d1e933cc4ab18df06809687ee2b7eac91c
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
