Rather than using a scroller, find the actual edge intercept
based on the trajectory of the fling.
This is done by finding the two points it could intersect with
and checking which point is 'closer' (i.e. would be hit first
by the PIP).
Bias towards using the intersection with the top / bottom edge
if the PIP is being flung along the side it's currently on.
Also increases the maximum time for the fling.
Bug: 35358634
Test: manual - fling PIP around screen while in landscape
and portrait
Change-Id: I26e943a5ddbc726ab86bc11e4271d4db034f3d47
The current documentation implies that the intent is sent to the
application that requested provisioning (which would be in the
primary profile for managed profile provisioning). However it is
sent to the new DO or PO only.
Test: make docs
Change-Id: I9d1f66ec6f3d6d7fbaa1617d13a7da12d4acb490
* Add BluetoothDevice.getBatteryLevel() API to retreive battery level
information of remote device
* Add BluetoothDevice.ACTION_BATTERY_LEVEL_CHANGED intent to notify user
that remote device's battery level has changed
Bug: 35874078
Test: make, pair with devices and use them
Change-Id: I41051ee25383f5f3a1e505aef6f8c526385f58bd
As there is no caller for the SystemAPI convertToTranslucent, there is no situation
where requestVisibleBehind will actually result in the activity becoming
visible behind. However we have bugs in the requestVisibleBehind code-path,
so rather than fix them...it seems better to just prevent ourselves from
running in to them. Full deletion of the code-path is scheduled for post-O
branches.
Change-Id: I6e7c79e036986564d2d443a603e63c341de23057
Fixes: 62512584
Test: Repro from bug. go/wm-smoke.
Apps with a normal UID are typically isolated enough to not require
socket tagging; we're mostly interested in tracking down internal
UIDs that have lots of code sharing the same UID.
Also fix up everyone doing manual string checks of Build.TYPE, since
we now have first-class fields for those.
Bug: 38126076
Test: builds, boots
Change-Id: I3a40348196bd8459289f2b9355d9783a07f1e7dd
By default, all subscriptions are wiped on first boot after a factory
reset. This ensures that if data is wiped outside of userspace (e.g.
in fastboot/recovery), the profiles are wiped, as there's no way to
offer this option to users in those modes - the radio isn't available
for us to access the eUICC.
This API provides a way to bypass this wipe if the user opts to retain
the policies for a wipe done from userspace (e.g. by unchecking the
"Wipe eUICC" checkbox in platform settings before wiping). We tell the
LPA to note this and skip the wipe on the ensuing factory reset.
Change-Id: I2fe472417497e28b043841a5aa2dc9efa45ebbff
Test: TreeHugger
Fixes: 62681577
This way an app store can shift blame for update-related network
traffic onto the app that is being updated.
Using a well-known tag makes it easy for developers to identify
that they didn't explicitly request the traffic at runtime, similar
to how backup/restore traffic is handled.
Bug: 38282350
Test: builds, boots
Change-Id: I003dd7c9615d4ab318250f1e44fa5d195ac94d23