Roots use a flag to indicate they have settings, and DocumentsUI
offers to launch towards someone who handles a new Settings intent.
Slight rename of browse intent for clarity.
Bug: 19993667
Change-Id: I86302ec1cfac5e435d8bc5701bdb85fb9b0dcbae
The existing management mode is too specific, and requires that
storage backends add queryChildDocumentsForManage(), etc. Instead,
to offer more natural browsing support, add a new BROWSE_ROOT intent.
It behaves mostly like MANAGE_ROOT, except that it doesn't mutate
its Uris with setManageMode(), and it shortcuts straight to VIEW on
clicked documents.
It can be launched like this:
$ adb shell am start -a android.provider.action.BROWSE_ROOT
-d content://com.android.externalstorage.documents/root/8405-1DFB
-c android.intent.category.DEFAULT
Also rename a MetricsConstants to make it clearer, and don't
auto-mount all emulated volumes.
Fix bugs around parceling of DiskInfo/VolumeInfo. Method to resolve
the best description for a VolumeInfo, which might need to fall
back to DiskInfo.
Add back "removed" volume state so we send broadcast when a volume
is destroyed, matching the expected public API behavior.
Bug: 19993667
Change-Id: I13aff32c5e11dfc63da44aee9e93a27f4690a43f
The update is that Downtime is obsolete. Replaced by the
ability to define multiple named schedule calendars.
- Make changes to ZenModeConfig to properly model manual
and automatic rules.
- Refactor the zen mode helper (and supporting classes) to
properly handle / report multiple claims on zen mode.
The "manual" rule (specified by the user in the UI) vs
one or more automatic rules.
- Automatic rules are still backed by condition providers,
but the layering is now cleaner. ConditionProviders is now
completely generic, has no ties to zen mode.
- Specifically, the new layering for zen mode (below noman) is:
ZenModeHelper: Source of truth for zen state
ZenModeFiltering: Subhelper dedicated to filtering rules.
ZenModeConditions: Subhelper dedicated to managing automatic rules.
ConditionProviders: Underlying engine for reporting named boolean state.
- Migration story for users with existing downtime config, migrated
to a single new calendar named downtime.
- For users with no existing downtime, two default calendars are created
for weeknights + weekends (icu4j for all locales will be done in a followup).
- Remove obsolete DowntimeConditionProvider/NextAlarmConditionProvider and tracking.
- Clean up obsolete resources.
- Add common zen summary description string computation.
- Add proper noman wrappers for the new model.
- Change the semantics of the global zen setting. It is now read-only. Setters
must call noman, added a "reason" to all calls for better attribution.
- Update zenmodepanel + volumedialog to the new model.
- Display the one or more automatic rules in the new zen footer summary.
- "Snooze" the automatic rules when the user explicitly turns zen off.
Bug: 20064962
Change-Id: Idd9deb865a6035ad0cfae660198dccb517e6d7cc
Since there are no third-party apps expected to be using the visual
voicemail related apps at the moment, best to keep these hidden for now.
Bug: 19236241
Change-Id: I86f622208efcc89fab523f03d2bb70c244cdf867
Also adds a test app for testing this intent. In addition, the secure
camera gets launched in the background to fix jank while sending the
intent.
Bug: 20016619
Change-Id: I7bb7e22ddaf5dc67fc09b9e63e5f3d10fe8e3ee4
First pass at delaying jobs from apps that are idle.
TODO: Throttle syncs
TODO: Provide a periodic point at which apps are checked for idleness.
Apps that switch to foreground process state are tracked by UsageStats
as an INTERACTION event that affects the last-used timestamp.
JobScheduler's logic for when an app is ready is trumped by the idleness
of the app, and only if the battery is not charging. When charging state
changes, we update the idle state of all the tracked jobs.
android package is whitelisted.
Bug: 20066058
Change-Id: I0a0acb517b100a5c7b11e3f435f4141375f3451f
This means that the source package can be determined without having to
query the database, thus making it easier to short circuit code on
voicemails that do not belong to a package.
Bug: 19236241
Change-Id: If9c3924a5365d5c3e87bff68609b5e7aee8eb218
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.
-- Resubmitting since this change was lost to a merge conflict --
Change-Id: I1ef094d5a35063e8f89cd1ecb1e5a0b59361781c
Now openQuickContact goes thorough DPM. When a lookup URI is build with
a lookup key returned by the enterprise lookup APIs for a corp contact, the
lookup key will have a special prefix. In that case we go through DPM
and have it launch QC on the managed profile, if the policy allows.
For now we use the same DPM policy as enterprise-caller-id to disable this.
Design doc: go/cp2-mnc-enterprise-dd
Bug 19546108
Change-Id: I831a8190ae902ae3b1248cce6df02e3a48f602d2
private class SearchIndexablesContract.BaseColumns is extended by public
classes. We need to make it public too.
Change-Id: Id77575f7857020531b9d311ca5ba12c6462268a5
The purpose of this feature is to prompt the Disambiguation dialog
to Users as less as possible.
- add the new "autoVerify" property to the IntentFilter class
- add new APIs to PackageManager:
verifyIntentFilter(int, int, List<String>),
getIntentVerificationStatus(String, int),
updateIntentVerificationStatus(String, int, int),
getIntentFilterVerifications(String)
for supporting IntentFilter verification
- add support for multi-user
- update PackageManager for IntentFilter verification:
basically when we are installing a new package, ask for verification
of all domains from the IntentFilters that have the "autoVerify" to true.
This means that the PackageManager will send a well defined protected
broadcast (with a new INTENT_FILTER_NEEDS_VERIFICATION action) to
an IntentFilter verifier to do the real job of verification.
We are passing in the broadcast Intent all the necessary data for
doing the verification. The PackageManager will receive as response
the result code of the domain verifications and, if needed, the list
of domains that have failed the verification.
- add a new INTENT_FILTER_VERIFICATION_AGENT permission that needs to
be set by an intent filter verifier to be considered as a trustable
party by the PackageManager.
- add also a new BIND_INTENT_FILTER_VERIFIER permission for securing
the binding between the PackageManager and a service doing the
intent filter verifications.
- add ResolveInfo filterNeedsVerification which is a boolean
to knows if the IntentFilter is of a type that needs a verification
(action VIEW, category BROWABLE, HTTP/HTTPS data URI)
- add new "domain-preferred-apps" / "d" dump command for listing the
prefered Apps for all domains
- add new "intent-filter-verifiers" / "ivf" command for listing the
IntentFilterVerifier used
- introduce the IntentVerificationService which is a basic service
for verifying IntentFilters. This service will send HTTPS requests
to the domain declared in the IntentFilter(s) for doing the
verification. This service has a low priority level so that it
can be replaced by a more sophisticated one if needed. This service
is updating the PackageManager intent verification states thru
the updateIntentVerificationStatus(...) API.
- update MockPackageManager
Change-Id: I0bfed193d0bf1f7c7ac79f6c1b160b7ab93b5fb5
Now openQuickContact goes thorough DPM. When a lookup URI is build with
a lookup key returned by the enterprise lookup APIs for a corp contact, the
lookup key will have a special prefix. In that case we go through DPM
and have it launch QC on the managed profile, if the policy allows.
For now we use the same DPM policy as enterprise-caller-id to disable this.
Design doc: go/cp2-mnc-enterprise-dd
Bug 19546108
Change-Id: I4840e7fad8a6a60249df07d993d26d03619650d4
The restored set of enabled IMEs/subtypes is merged into the
current state of the system, rather than simply replacing it.
This is because we do not want to accidentally disable or
reconfigure something that the user is currently relying on.
There's a certain amount of repetitive activity here, rebuilding
the enabled-state data structures in a different format, but it's
important for maintainability that the restore code be able to
rely on the core InputMethodUtils implementation of reading/writing
the settings element.
Bug 19822542
Change-Id: If0104151b3526da6ecc669adde3119a239ecafeb
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
