am: 3b25fd081d
* commit '3b25fd081d6af21b16ab4b96ead70766b3d78d06':
Fix a couple bad links in the javadoc for android.os.health.
Change-Id: I27ccd973ff6a14387a11f19c30dcb5a3ae95b802
am: 9aa6bb5a4a
* commit '9aa6bb5a4a8bd00a175e8a9c338b52bc24a162b4':
Two phases to set the password for disk encryption
Change-Id: Ic77d5608961b34993848fc71809a27001d919abc
am: ac29617c6e
* commit 'ac29617c6e11085c9648d150a50c5daa15d65645':
Flesh out the docs for the android.os.health package.
Properly blame the correct uid for wakeup alarms that don't have a WorkSource.
Change-Id: I28bae3d984af6d19852fb63eda5fb21c1b6c98dd
am: d8c38b892b
* commit 'd8c38b892b86cc9cb94633b6f9d74126e2d53c60':
Cancel animation and jump to current state if not animating picker
Change-Id: I20684e1e974e1d5f8f6987ca9eac17d3da470763
am: 638a6e8140
* commit '638a6e8140a22a0ddb5d5dacb02173795073bd1a':
Fixed connectivity state in some restricted network scenarios.
Change-Id: I5d3fdbbff6d92be9657d3ed466462ca911d20881
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
Another scenario that is not properly handled is when a UID whitelisted
for Data Saver is brought back to foreground: although the proper
firewall rules are set, CS is not notified, and the apps state would be
DISCONNECTED / BLOCKED.
This CL introduces many changes that fix this issue:
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when the Battery Saver status changed.
- Fixed updateRuleForRestrictBackgroundLocked() to invoke
onUidRulesChanged() when an app whitelisted for Data Saver is brought
back to the foreground.
- Added a new API (onRestrictPowerChanged() and getRestrictPower())
to notify external services about Battery Saver mode changes.
- Fixed CS logic to properly handle the Battery Saver changes.
Externally to this change, the CTS tests were also improved to verify
the apps get the proper connection state; they can be verified running:
cts-tradefed run commandAndExit cts -m CtsHostsideNetworkTests \
-t com.android.cts.net.HostsideRestrictBackgroundNetworkTests
BUG: 28521946
Change-Id: I8eaccd39968eb4b8c6b34f462fbc541e5daf55f1
am: 0588954071
* commit '058895407140de0e513b82150c3acb6131e971a2':
Move the 'pretend idle jobs can run now' broadcast into AMS
Change-Id: Ia97d382761fc8b9f2c11729cd027a2d8c6c9379b
Calling Objects.hash with a byte[] will call the identity hashCode on
the byte[] and this doesn't agree with the use of Objects.deepEquals
in equals.
Bug caught by error prone.
Also, replaced usage of Objects.deepEquals(mServiceDataUuid, ...) with
Objects.equals(mServiceDataUuid, ...), because mServiceDataUuid
is an Object of type ParcelUuid.
Bug: 28585195
Change-Id: Id92734874339985fedafe1a28286a6a4dcd88d3b
am: 5d6a218d9e
* commit '5d6a218d9e0d21367f6365d4de51532ca7e14dc9':
Dismiss docked stack if an activity is shown on top of the lock screen
Change-Id: Ia5f98128501fcf648da94d6393f799d83ca89656
It's a protected broadcast, so sending it directly from 'am' is
no longer an option. This is needed for CTS as well as being
generally useful during app development.
Bug 28406044
Change-Id: I101915a8c6f19454330a8db2079a75023c112582
In one phase, we make the new password work, and in the second we make
it the only one which works ("fixation"). This means that we can set
the password in Gatekeeper between these two phases, and a crash
doesn't break things. Unlocking a user automatically fixates the
presented credential.
Bug: 28154455
Change-Id: I18812f9ce753486ce4e33b4fe2cca392b006b39c
NetworkPolicyManagerService (NMPS) keeps an internal list of uid
rules (mUidRules) for network restrictions, and when these rules
changes it needs to notify external listeners (such as
ConnectivityService / CS).
Prior to Android N, both Data Saver mode (the feature previously known
as "Restrict Baground Data") and Battery Save mode used the same set of
firewall rules to implement their restrictions: when Battery Saver mode
NPMS would mark all networks as metered and set the proper firewall
rules externally.
Recently, these 2 modes were split in 2 distinct firewall rules and
NMPS.updateRuleForRestrictBackgroundLocked() was changed to update
the mUidRules logic based on the Data Saver firewall (since the Battery
Saver firewall changes are handled externally, on
updateRuleForRestrictPowerLocked()). As such, CS was not notified when
the power-related changes were made, which would cause apps to get a
state of CONNECTED / CONNECTED when querying its active connection.
This change refactores the mUidRules to use bitmasks, in preparation for
another change that will fix the issue.
It also fixes a minor bug that was preventing removed packages to be
removed from the whitelist.
BUG: 28521946
Change-Id: I9f0e1509a6192cad403f740c1cd76a6b7dab7d26
It is risky/complicated to try to put the activity showing on-top of
the lock screen in the right fullscreen configuration with the current
architecture. So, we just dismiss for now.
Bug: 28195260
Change-Id: I29a0350993ce8fe548d4a465b06d877cde151c78
This API was using a oneway aidl call, which meant that the
service was disabled some time after the method returned. That
confused tests that were turning a service off during tearDown
and then turning it back on again in setUp.
Bug: 28621277
Change-Id: I75984df0613bdbb1bc876e2a15caf59106027337
The code assumed mapping from a permission to an app op
is one to one but this is not always the case. For example,
READ_SMS is mapped to OP_READ_SMS and OP_READ_ICC_SMS which
resulted mapping the READ_SMS permission to the OP_READ_ICC_SMS
instead of OP_READ_SMS resulting in a failure to find the op
name given the permission.
This breaks the AppOpsManager.permissionToOp() API for READ_SMS
returning null instead of OPST_READ_SMS. The consequence of this
is that the apps that proxy permission protected operations may
let the operations for READ_SMS go through as they would get a
null app op, i.e. no app op while there is one and it can be
disabled for the caller.
bug:28620132
Change-Id: I92f8ef375ae2122b7266c50653ce73f3d90f4b28
If there are no enrollment applications on the system, but someone still
makes a KeyphraseEnrollmentInfo and tries to print it, it would generate
a NPE on a map object. Instead of setting the map to null when we don't
find any enrollment applications, we can just set it to an empty map.
Bug:28622866
Change-Id: I023e6fd90effd3143c19817a0d6637a013bebc31
When relaunching an Activity, the DecorView and ViewRootImpl is re-used,
along with the IBinder activity token. This means that when we create
new resources, we end up just updating the base Activity resources.
However, we would set the configuration to the new requested override
config and then proceed to update existing Resources references, which
would return immediately due to the equality check for configuration
updates.
This change pushes the setting of the new override config to the
updateResourcesForActivity method, which will properly update Resources
references that are held in the re-used DecorView.
Bug:27915587
Change-Id: I113007a40fa464b8a234b073dcf851e16fee0177
am: c5be8f8a4b
* commit 'c5be8f8a4b9946f26f43201a06e7ec3f9b34857e':
Correct docs about what is ignored in full-data backup
Change-Id: If70b6d247126758dcc82ec7780060ad99253a32d
You can't back up content in e.g. getNoBackupFilesDir() even if your
app explicitly tries to.
Bug 28321431
Change-Id: Ifa2a4bc518de03aba4c8809e60d8bb90fce767f8
