Now that we're treating storage as a runtime permission, we need to
grant read/write access without killing the app. This is really
tricky, since we had been using GIDs for access control, and they're
set in stone once Zygote drops privileges.
The only thing left that can change dynamically is the filesystem
itself, so let's do that. This means changing the FUSE daemon to
present itself as three different views:
/mnt/runtime_default/foo - view for apps with no access
/mnt/runtime_read/foo - view for apps with read access
/mnt/runtime_write/foo - view for apps with write access
There is still a single location for all the backing files, and
filesystem permissions are derived the same way for each view, but
the file modes are masked off differently for each mountpoint.
During Zygote fork, it wires up the appropriate storage access into
an isolated mount namespace based on the current app permissions. When
the app is granted permissions dynamically at runtime, the system
asks vold to jump into the existing mount namespace and bind mount
the newly granted access model into place.
Bug: 21858077
Change-Id: I62fb25d126dd815aea699b33d580e3afb90f8fd2
...into account when calculating the position information
Actually what we need here is the full transformation matrix, if it
is available. And that means actually computing the location of
views on the screen requires doing this all through transformations,
so the AssistVisualizer has been changed to do this (while still
also keeping the old mechanism for comparison to verify that things
are working correctly).
Also added new properties for elevation and alpha.
And optimized the parcelling of AssistStructure to not write things
that aren't needed; this reduces the parcelled size by about half.
Change-Id: I50b0dd2e6599c74701a5d188617a3eff64b07d03
This ensures that theme attribute values that affect the look and
feel of the FloatingToolbar views are the ones specified in the
framework.
The aim is to avoid apps modifying the toolbar's look and feel in
unexpected ways by overriding Theme attributes.
Bug: 21957785
Change-Id: Idd472b4e8511f0a039cd07f98b1fd3ce93ae97fa
When transitioning from ON to OFF with LE Advertisers, advertiser do not
get a chance to unregister themselves as the stopAdvertising checks the
state of the stack and throws before unregistering the object.
It will then never remove the callback objects causing a leak.
b/22092678 | Remote service crash after switching to restricted profile
Change-Id: I04817026a524d10d60abdd8b533554a71a0112e2
OnPreDraw is called even if the View is not visible.
So need to check isShown() and hasWindowFocus() before calling
starting selection action mode.
This hack is originally introduced for keeping selection on device rotation.
I manually verified this issue does not revive with this CL.
Bug: 22036870
Change-Id: I814db6165e2345fcacedcbd399c1a3985501c8fd
The text selection handles should be hidden / shown when the window
loses / regains focus.
Additionally renames method to make more sense.
Bug: 22062480
Change-Id: I6e160234cf112ee285367637e2f1c14defd82e89
In TextView's onPreDraw method, startSelectionActionMode()
is called, but the selection has already been started so
in startSelectionActionMode() it shows the
insertionController which hides the selectionController.
Fix this by adding a check to start the action mode only
if it is not already started.
Bug: 22028858
Change-Id: I2999423155b7a63a7d879bc8ea5032e17dff459f
Only prune ChooserTargets if the resolved activity source they came
from is still present after refreshing the list. Compare this directly
against the ComponentName rather than ResolveInfo.equals, as the
latter isn't implemented.
Bug 21953672
Change-Id: I6486bda85c19d7371167affe2a2b80a2668bd734
It is malformed to write a single intent filter like this:
<intent-filter android:autoVerify="true">
<data android:host="foo.example"
android:path="/"
android:scheme="http" />
<data android:host="*"
android:path="/custom"
android:scheme="fooexamplecustomscheme" />
</intent-filter>
In practice this app is accidentally defining a filter that will match
"http://*". This is now detected, and will never be auto-verified for
any of the mentioned domains.
Verified intent filters must *only* handle the http & https schemes.
Bug 21920537
Change-Id: I933cddbea23185d242565cac940e1e7a7e4e289b