Add some new internal APIs to enumerate USB Type C ports, query their
status, determine whether they support changing power or data roles,
and doing so. The API also adds a new ACTION_USB_PORT_CHANGED broadcast
for port state changes.
The implementation includes a mechanism for simulating the behavior
of the USB stack. See 'adb shell dumpsys usb -h' for details.
Note that the underlying kernel driver interface is still subject
to change but its behavior has been encapsulated as much as possible.
Bug: 21615151
Change-Id: I0c853ae179248a4550b3e60d02a7a7e65e4546b2
- New screen on app op to record the last time each app has
caused the screen to be turned on.
- New battery stats event that tells us the reason the screen
has been asked to turn on.
- Propagate out power manager API to specify the reason a caller
is asking to have the screen turned on.
Note that currently the window flag to turn the screen on bypasses
much of this because it is being handled in the window manager by
just directly telling the power manager to turn the screen on. To
make this better we need a new API where it can specify who it is
calling the API for.
Change-Id: I667e56cb1f80508d054da004db667efbcc22e971
In previous platform versions, finishing an action mode would clean up
the current action mode even if it was not the same ActionMode
instance. Some common shared code inadvertently relied on this
behavior, so stay bug-compatible with it based on targetSdkVersion.
New apps will get the stricter behavior.
Bug 22265882
Change-Id: Id5d6341aefc07a3cb788d5d6d0b531816f761e42
We now place whoever is receiving the MMS on the temporary
whitelist while doing so, so they can get network access to
download it.
There was also an issue that needed to be fixed where we
were no longer updating the list of allowed uids while
dozing based on their proc states... we now do that.
Also did a bit of optimization of the temp white list update
path do the network policy manager, instead of going through
a broadcast we now directly call in to the network policy
manager. This also allows us to have a synchronous version
of updating the list, so we can know the app has network access
before we tell it to do anything.
Finally added battery stats events for things going on and off
the whitelist so we can diagnose the behavior there.
Change-Id: Ic7fe010af680034d9f8cb014bb135b2addef7455
Added Context.sendBroadcastMultiplePermissions(Intent intent, String[]
receiverPermissions) method, which allows an array of required permissions
to be enforced.
Bug: 21852542
Change-Id: I27c9130e8f004b428452501ebc8a36aabde1f343
- Add onFingerprintAcquired, so Keyguard can grab a wakelock to prevent
the device from sleeping.
- If we get a successful fingerprint, wake the device up, immediately
dismiss the keyguard and tell PWM that we kicked off our frame that
will represent the correct state.
- PWM then waits for this frame to be drawn, and then turns on the
screen, which results in unlocking directly to the previsouly
opened app.
Bug: 21855614
Change-Id: I0c43bcc9d334b509632704fb0c123ab3351edff2
Give more details about why we failed to create storage paths, and
search for underlying volumes using canonical paths.
Bug: 22135060
Change-Id: I75d3584403ece310438b05f5b9fe72d94c9096c6
Added Context.sendBroadcast(Intent intent, String[] receiverPermissions)
method, which allows an array of required permissions to be enforced.
Bug: 21852542
Change-Id: I3b8ff258fa9f3249c344bb8093b820b24eef00c0
Receivers of ACTION_FOUND intent are now required to have
ACCESS_COARSE_LOCATION permission.
Bug: 21852542
Change-Id: I8306f7431f067ca36bfc568a912385153fa3d496
High cpu times are expected as multiple cores can be running at the
same time, so comparing against the time between samples is incorrect.
I am reasonable certain that the values we see now are correct, so disabling this
check. However, checking for negative values (overflows) is still enabled and
will remain enabled because there is no case where we will be ok with negative deltas.
Bug:22461683
Change-Id: If9c7cdbb75ceaed059d1e0f4dd83cfdd3e021a93
