..in link-opening behavior. If a candidate is marked as "ask
every time," then the user is guaranteed to get a disambiguation
prompt including that candidate even when some other candidate
app is in the "always prefer this over a browser" state.
Bug 23147746
Change-Id: I904d8697a992b3f16f32b1c1b49c2bf9424c7137
...with protection flag PROTECTION_FLAG_DEVELOPMENT
Bring back the old grant/revoke code for development permissions.
Also some more dumpsys output to help debugging.
And new dumpsys command for checking a permission.
Change-Id: I6e27e62a9ca5ec1ecc0f102714a448ea02f0f41c
When in ambient display mode, we didn't get a callback to
onStartedWakingUp, thus the time was never refreshed. Since
broadcasts are disabled in this low-power state, we need to refresh
the clock manually before turning on the screen, because we can't
rely on the broadcasts to be delivered.
Bug: 23171638
Change-Id: I249f4195a14995f7c1467e73ac2aa400b871f80e
The platform grants runtime permissions by default to apps on the
system image that provide core device use cases which a user expects
to work out-of-the-box. We are now adding a test to ensure that
OEMs cannot pregrant premissions on non approved components.
bug:23043018
Change-Id: Id76717cce0ee59678956bd0be347d3c045fe4c51
Global restriction of background data only applies to metered
interfaces, but battery saver applies to all interfaces. In the
very specific case where global background had been turned on while
battery saver was enabled, we'd end up with a stale battery saver
rule floating around.
This change triggers an update of iface rules when the global
restriction changes, giving us consistent behavior.
Bug: 23098198
Change-Id: I454dc71cf11d50a2e9e6122e8a801ff17039b43a
Adding a new carrier config key to specify the gap between the DTMF
tones sent out to the network.
BUG: 23064351
Change-Id: I3a0e20efecd62f533e796a40097f181d4c20d614
Since bluetooth connection state has a mind of its own... If we
think we are connected, but we don't actually know about any devices
that are currently connected, we probably aren't. So set the state
that way, and let everyone know.
Bug: 22977827
Change-Id: I9266f5394b179a3917b3818839f7c6b2dc238376
When long pressing on an empty Text field with the system language set
to RTL, the "paste" popup was not showing up.
The Floating Toolbar requires a content rect to determine where the
text is and place itself close to it. In the case of an empty field,
we create a "fake" content rect by taking the placement of the cursor
+1 pixel to the right. In RTL languages, this +1 causes the content
rect to be considered off the bounds of the view, as the cursor is
aligned to the right, and hence the Floating Toolbar is hidden.
After making the rect a 0 width rect, we ran into the issue that
it was considered out of bounds due to the calculation ignoring rects
that simply touch the edge of the view's bounds.
BUG: 22540083
Change-Id: I29c79b701f586970b2611178233eff082b802ec1
