Bug 22505481
ag/684544 added a feature to allow shared elements that weren't
shared into an Activity to be shared back. However, if you are
targeting an older version of the SDK, you may get an unexpected
shared element back. This change in behavior has been locked
behind a target version check.
Change-Id: I7162e24f3b14fedd6b308e89e9d04ac67660f7d6
This CL addresses TODOs in Ib641dda49f7ab1c7d60207c36a47767bb408.
With this CL the position of PopupWindow is always specified in
window-local coordinates even if FloatingToolbar#mParent is not a
decor view.
Bug: 22335001
Change-Id: I0cdd63a00051fa30981e517c07682075467ac598
This is a coment-only follow up CL for I71a8d356e868dc7715b030ca,
which wrongly changed coordinates from window-local to view-local
(relative to FloatingToolbar#mParent) when showing PopupWindow.
The position of PopupWindow still needs to be specified in
window-local coordinates as we had done before
I71a8d356e868dc7715b030ca1078da4ec39368c3.
Currently the problem might not be visible to users because
1. FloatingToolbar is not a public API hence all the instances
are under our controll.
2. FloatingToolbar#mParent is alwasy initialized with
PhoneWindow#getDecorView() for now.
Bug: 22335001
Change-Id: Ib641dda49f7ab1c7d60207c36a47767bb408971c
AppOpsManager:
Changed the default mode for SYSTEM_ALERT_WINDOW to MODE_DEFAULT instead of
MODE_ALLOWED. Otherwise, an app that did not declare for this permission will
actually be allowed to perform OP_SYSTEM_ALERT_WINDOW, which is undesirable.
This change also allows callers to make their own decision based on the
current policy (M vs pre-M apps).
policy/PhoneWindowManager:
Added additional checks that will handle MODE_DEFAULT - this happens when an app
is newly installed but not yet configured.
wm/WindowManagerService:
Enriched some checks to include the treatment of MODE_DEFAULT - this will allow
pre-M apps uninterupted capability to draw on top of other apps.
Change-Id: I8de77730e158c97587427820cfba721bd5607bea
There is a zoo of components that handle the home intent and
have different priority. There is no reliable way to distinguish
the setup app from the other apps that handle home as some of
them have lower priority than the setup app and some higher.
This change adds a dedicated category to recognize the default
setup app.
Uncommented the code that grants accounts permissions as the
get_accounts permission is now a runtime permission and can be
granted.
bug:22471024
bug:22501463
Change-Id: I41726751fa2567cbcd7d09c7acfa7615b8aba577
New APIs allow the voice interaction service to set/retrieve a filter
for which of the show flags are allowed.
Change-Id: I588cbe55afee0548ad3afa22d3a7d3bc43cb54a6
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
..."FATAL EXCEPTION IN SYSTEM PROCESS"
Synchronous calls out of the system process are bad, m'kay?
This should be a safe change because the only place I see calling
this interface are within the system process where there is clearly
no other dependency on ordering.
Change-Id: I483b07cfd68d00d74797784c2a75012e8dd67141
- 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
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
