- Prevent Search or long-press Home actions
while TV setup is being completed based
on flag TV_USER_SETUP_COMPLETE.
Test: Manual - Reset device, ran Setup, tried keys.
Test: Manual - Rebooted device after Setup, tried keys.
Bug: 62419382
Change-Id: Ic8fb0f10943ab7c39a7d9857f62e6ab292231b40
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
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
We now preflight the effect of a k/v backup delta set against the
current contents of the datastore, so we can detect and report a
quota overrun nondestructively.
Test: bit CtsBackupTestCases:.KeyValueQuotaTest
Change-Id: If69687b891271d7bbb46c3a66728b716dc51fc39
When an application is wrapped using setprop wrap.<application>, it
doesn't set the special zygote flag, or make the mallopt call. This
means that a wrapped application will behave differently, and not
be able to track zygote native allocations versus app native allocations.
This CL adds a nativePreApplicationInit call that is used after the
Zygote is forked, and when a wrapped application is called.
Bug: 62068500
Test: Booted sailfish system. Verified that the zygote has not called
Test: the new function. Verified the function is called when a wrapper
Test: is used. Verified the function is called when the Zygote forks
Test: a process.
Change-Id: I392e1b5429be77def63f7815b072d68e9408cc7f
(cherry picked from commit 2980de4a59)
When an application is wrapped using setprop wrap.<application>, it
doesn't set the special zygote flag, or make the mallopt call. This
means that a wrapped application will behave differently, and not
be able to track zygote native allocations versus app native allocations.
This CL adds a nativePreApplicationInit call that is used after the
Zygote is forked, and when a wrapped application is called.
Bug: 62068500
Test: Booted sailfish system. Verified that the zygote has not called
Test: the new function. Verified the function is called when a wrapper
Test: is used. Verified the function is called when the Zygote forks
Test: a process.
Change-Id: I392e1b5429be77def63f7815b072d68e9408cc7f
...background processes (CPU, etc)
Add full configuration params for adjusting these settings (some were
already there).
Also... as long as we are doing this...
- Get rid of all of the wakelock stuff. That is completely pointless
now that we aren't even allowing cached processes to hold wake locks.
- This greatly simplifies the code, since we don't need to deal with
two different policies for how we do checks. Instead, we just regularly
check for CPU and the CPU check interval.
- And make the CPU check more aggressive and have much more flexibility
for tuning: there are now 4 different maximum CPU use levels, depending
on how long the process has been in the cached state. This allows us to
be more strict on CPU use the longer it is sitting in the background.
Note that CPU use tracking only happens while the device is not
plugged in to power... I'll leave this for now, but I think in the
future we should think about applying these limits even when plugged
in, because in either case cached apps should really not be doing
much.
Test: manual
Change-Id: I68f4ab68be5f7d5fc4822005107fb60ef07a374d
Currently if View.setTooltipText is called while
the tooltip is being shown for that view, it will
update the displayed text. The tooltip then will
resize to wrap around the new text, but not change
its position. This looks confusing if the new text
is significantly shorter or longer.
Removing this functionality until proper
re-positioning is implemented.
Bug: 38491655
Test: android.view.cts.TooltipTest passes
Change-Id: I79689288185888854b992b89e19fe381d3ac50e4