The whitelist is now maintained by DeviceIdleController,
which is moving out into its own independent system service.
Network stats now queries it for the whitelist, instead of
collecting that itself.
Also did a few improvements in alarm manager -- made the
code for moving alarms out of the pending list more robust,
and fixed the debug output to always print the contents of
the pending list even if we aren't in a pending state. (That
would have helped me identify the problem much earlier.)
Change-Id: I0f7119d4c553c3af4d77b2f71246fa6e2c13c561
These system|signature only permissions must be required by
an InCallService and ConnectionService respectively.
Bug: 20304458
Change-Id: I26156afb610a7f549c0a1a7c01c2096928ef33a7
* changes:
Rename removeVideoCallListener to unregisterCallback
Bluetooth document fix: remove reference from open API to hidden entities
Fix build due to merge of 7595842 and renaming due to 8eb87f0
Merge commit '052a0da' into merge2
Merge commit 'db1dbb8' into merge2
Merge commit '7e5e791' into merge2
Merge commit '170102d' into merge2
Merge commit '4cb5d80' into merge2
Merge commit '83cda00' into merge2
Merge commit 'c91bc62' into merge2
Merge commit 'cffc360' into merge2
Merge commit '7f61051' into merge2
Merge commit '167c3a7' into merge2
Merge commit '4467b98' into merge2
Merge commit '25a217c' into merge2
Merge commit '04b18ec' into merge2
Merge commit '7595842' into merge2
Merge commit '2bbd2b6' into merge2
Merge commit '4890351' into merge2
Merge commit 'cd405fe' into merge2
Merge commit '6ddbb5e' into merge2
Merge commit 'de93575' into merge2
Merge commit '9561e74' into merge2
Add am shell command to set and get idle
Add public API to check if an app is idle
Bug: 20534955
Bug: 20493806
Change-Id: Ib48b3fe847c71f05ef3905563f6e903cf060c498
Create the new permission MANAGE_PROFILE_OWNERS to restrict setting
the profile/device owner.
BUG:19838376
Change-Id: Ib55a2db85fcb6f34e3b88c398683bddb0ad66868
Create a DevicePolicyManager API which can be used by OTA subsystem
to tell device owners about pending updates. Device owners will get
a callback from its DeviceAdminReceiver when the update service sends
out such notifications.
Bug: 20213644
Change-Id: Ifcc755655e4f441980cf77d76175a046112ca9ae
A new flag for DPM.resetPassword() method that specifies that the
device should be decrypted without asking for the password or pattern.
Bug 19250601
Related CL in Settings App: https://googleplex-android-review.git.corp.google.com/#/c/670206
Change-Id: I9ca3472dc18e66e618ff772dee16ca4a450e9997
Since the demise of the connectivity change delay,
CONNECTIVITY_ACTION_IMMEDIATE has been sent out back to back with
CONNECTIVITY_ACTION.
Interested parties should watch for CONNECTIVITY_ACTION.
Bug: 20013379
Change-Id: I072dddf95adb3bbd17fa1f7159d4ea848ade8f19
Use the term "SystemUpdate" instead of "OTA", in public
DevicePolicyManager APIs that handle OTA policies.
Bug: 19650524
Change-Id: Iebdaea91337d617147cb411b6f47e0f3fae8671c
Currently only one app can write to the SMS provider and it has to
be set as the default SMS app by the user in the UI. The default
SMS app is set by enabling the write SMS app op for it and keeping
this op off for other SMS apps. Hence, this permission does not
guard anything and can be taken out. The API change is fine as if
an app refers to the permission in the manifest as string it will
be ignored and if it was referred in Java the value is statically
compiled in the source.
Change-Id: I1128c3b034e6c7dda4baa051500ac1ef46a53575
UICC privileged carrier apps will extend CarrierConfigService to provide
carrier-specific configuration. Apps/services will use
CarrierConfigManager to read the current configuration.
CarrierConfigManager also defines the set of configuration variables and
their default values.
Bug: b/19483786
Change-Id: I027211b43276afd6fe893ae50048c52f2aed5cf5
This API allows apps other than the system's CaptivePortalLogin
to handle signing in to captive portals.
bug:19416463
Change-Id: I27fce5856b635233e6ff66396d50ccabedd76cf5
UICC privileged carrier apps will extend CarrierConfigService to provide
carrier-specific configuration. Apps/services will use
CarrierConfigManager to read the current configuration.
CarrierConfigManager also defines the set of configuration variables and
their default values.
Bug: b/19483786
Change-Id: I027211b43276afd6fe893ae50048c52f2aed5cf5
The ACCESS_MOCK_LOCATION permission is gated by a secure setting
toggled in developer options by the user. Hence, there is no need
for getting yet another consent from the user for accessing it.
Change-Id: Ica1a72f587a712d7da7c00cfc4a8ca228064286e
These permissions are definded by the platform to protect the
subscribed feeds provider which is not in the system, neither
is its contract specified in the system. Both the contract and
the implementation of the provider are in GmsCore. Hence, this
permissions shuld be declared by GmsCore, not the system. Until
GmsCore adds the permissions we have to keep this as removed
but present in the implementation to keep apps that use the
provider working.
bug:20192150
Change-Id: I3f38b01a159bb430c30948b14de7cdaf5cb50772
Allow device owners to set OTA policy for automatically accept/postpone
incoming OTA system updates. This class only provides the setting
and getting of OTA policy, the actual OTA subsystem should handle
and respect the policy stored here.
Bug: 19650524
Change-Id: I9b64949fab42097429b7da649039c13f42c10fd1
Instead, require the intent sender to hold the new system-or-signature
UPDATE_CONFIG permission. An application holding this permission is
now responsible for verifying the integrity/source of an update, before
sending it to one of the ConfigUpdateInstallReceiver subclasses.
Bug: 8949824
Change-Id: I0925051c1dcef312b8508fb34927150ffbc346f9
- Create method in DevicePolicyManager to send device
provisioning status to ManagedProvisioning.
- Define status updates used by ManagedProvisioning.
Bug: 20001077
Change-Id: Ia98fc765d1ebb2ba9680636ca15c2c870d160261
1. Defining the new permission groups and moving relevant permissions
to these groups.
2. Removed some permissions that were guading ... nothing and old
permission groups.
3. Removing unnecessary comments for siganture and system permissions
as they are no surfaced to the user.
Change-Id: Ibd7e6bb22b3559a4febb37c39326350eeb4285bd
Add method to allow authorized data block wipe in support of factory
reset protection. This will allow ManagedProvisioning to respond to
and pass factory reset protection challenges during automated device
setup.
- Adds the wipeIfAllowed method to clear the data block
- Creates a protected-broadcast to send to allowed package
Bug: 19792435
Change-Id: I897f2ea2afb1222a1fc8ac49290ee45ea4d3f2d7
Add idle mode support to the alarm manager. Introduce
a new concept of flags associated with alarms to tell
the alarm manager how to treat the alarm -- they allow
everything from the alarm that will bring us out of idle
mode, to alarms that are allowed when idle or should
also bring us out of idle. The standalone boolean is
now also a flag.
(Note there is currently no protection from user space
setting the flags however it wants; I will be working
on that in a follow-up change.)
When in idle mode, the alarm manager pushes all alarms
that shouldn't execute during that time over to a
separate list that is not executed until out of idle.
To help with this, I reworked a bit how Alarm objects
are managed, so that when rebatching or moving between
lists we don't have to allocated new objects but can
just use the same existing instance.
Also tweaked the sync manager to deal with idle mode,
which currently just means doing the same thing as when
low on storage -- turning off sync.
Add new ACTION_CHARGING and ACTION_DISCHARGING broadcasts
that apps can listen for to know when the device is actively
charging and discharging. These are better than the old
POWER_CONNECTED and POWER_DISCONNECTED ones because we only
report charging when we actually see that there is enough
power being provided to charge the battery (and will report
discharging if there is not enough power).
The job controller uses these new actions for scheduling
jobs that want to run while plugged in. Removed the
"stable charging" stuff while doing so, since the new
charging state serves as an even better signal for that.
Introduced two new process states: FOREGROUND_SERVICE and
TOP_SLEEPING. This will allow us to treat foreground services
specially (such as still allowing network access to them for
background music playback) while not mixing them together with
whatever happens to be the top activity while the device is
asleep.
Also some other small cleanup here and there.
Change-Id: I7a9808b578bad6f50deb8e1baf919298512a0d3a
Add internal API's for SystemUI to start a voice interaction session
directly, without using an intent.
Make the assist gesture use that ability, if available.
Change-Id: I88ce3c7514714eb45666884847193585a07417a9
New hidden intents and permissions for a generic SIM-activation
activity. New activity will handle generic SIM setup requests and then
delegate to the appropriate activation method (OTASP, HFA,
CARRIER_SETUP).
Change-Id: I1b22200544abefe486ec961b67a6e77b4d15aec3
- Adds a camera service to system server that forwards events to the
mediaserver camera service.
- Notify the camera service when the device user changes.
Bug: 19186859
Change-Id: I172a2ce46c8e8a131ae7e8dd99d60c5f4f0d6668
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
The existing one, being deleted here, did not work properly: it only
updated the file used by libcore and bionic, it did not update the ICU
data.
Most of the installation logic exists in code in libcore/tzdata that is
independent of the server code so that it can be tested.
Bug: 19941636
Change-Id: Id0985f8c5be2f12858ee8bf52acf52bdb2df8741
Added new API consisting of android.app.usage.NetworkUsageManager and
android.app.usage.NetworkUsageStats. Through them data usage on a
network interface can be programmatically queried. Both summary and
details are available.
Bug: 19208876
Change-Id: I0e0c4b37ae23ad1e589d4b0c955b93f28ba4333e
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
