Ignores the old, re-appropriated key "idle_duration" which is now
set to a high value in order to force disable app idle on devices
with bug b/26355386
Bug:26355386
Change-Id: Iff9de843ad6e547d29c1583687fc7f7ce7e15090
With the updated rolling window of stats for app idleness, we need to make sure
it is populated before we initialize some defaults.
Now that we look at older entries to figure out idleness, if those
entries are in the future (due to time change), set them to the current
screen on time.
Bug:26504153
Change-Id: Ia22add0e8eaf0f137002bbe3e91d747fef5b7d69
App Idle queries are very frequent and so they only check in memory stats.
However, in memory stats can be missing some entries, especially after a rollover, but also
due to a larger bug fixed in master (too risky to take now).
The fix is to do a deep query (reading older files from disk) and maintain a parallel cache
of stats for app idle. That way the rolling window of data required to serve app idle queries
stays in memory.
Bug:26355386
Change-Id: I2dd3946b45d7d893410715bb0534b2b48694ced6
Symptom:
As issue link:
https://code.google.com/p/android/issues/detail?id=193100
RootCause:
UsageStatsService.onDisplayChanged executed in system main thread,
If calling UsageStatsManager.queryEvents with too many events before it
(i.e. in daily usage event file,
too many activity resume / pause events or configuration change
during monkey test),
System will be blocked then watchdog timeout.
Solution:
Let display listener executed in background thread handler
BUG: 25355086
Change-Id: Ic894d112612400ed8fb7ba843b3309fdc4f66fe1
(Cherrypicked from 4e59db328d8b0cc163d2e3eb0f7f3a108f20a58d)
(cherry picked from commit 7018f60b06fd0c647ebf13225320d7e15d02e075)
It is possible that older platforms may have not cleared the lock pattern,
but instead only checked this flag to determine the lock pattern enabled
state. In such cases, upgrading to a platform with that only checks the
lock pattern can lead to the lock screen being re-enabled by accident.
These new methods allow this condition to be identified and resolved.
Bug: 26029690
Change-Id: I8f7ebc0e1915049afe49c219c87010aa38a16244
Add a new mechanism where we retain previously used provided
processes in the "last activity" oom adj state for 20 seconds,
before allowing them to fall down to a regular cached process.
This should help reduce thrashing when something is acquiring
and releasing a provider repeatedly.
Change-Id: I889472de7bb4da574b46f07e36a99978813643cb
Android currently forces USB into MTP mode if there was no modes
specified. This causes issues on Clockwork devices as they do not
support MTP.
The hack stops this behaviour, and also sets MTP mode back to none.
Bug: 25547826
Bug: 25582050
Bug: 25244201
Change-Id: I772e35d0a5db51b17e9d71c59e6a157dabb1d296
It is possible for an external process (e.g. sys-ui) to call into
WM to get the bounds of a stack in between the construction of the
DisplayContent object and SystemServer telling WM that the display
is ready. Incorrect bounds would be returned to the caller in this
case since the baseDisplayWidth/Height is only set when the displayReady
call is made.
We now initialize the base display information when the DisplayContent
object is created so any call to get the logical display rect of the
display will always return the right bounds. This should be okay as the
display manager is initialized way before window manager.
Bug: 22961090
Change-Id: Iebd688ad8f4c08556846fcebb543e58bd2c01414
Symptom:
As issue link:
https://code.google.com/p/android/issues/detail?id=193100
RootCause:
UsageStatsService.onDisplayChanged executed in system main thread,
If calling UsageStatsManager.queryEvents with too many events before it
(i.e. in daily usage event file,
too many activity resume / pause events or configuration change
during monkey test),
System will be blocked then watchdog timeout.
Solution:
Let display listener executed in background thread handler
BUG: 25355086
Change-Id: Ic894d112612400ed8fb7ba843b3309fdc4f66fe1
(Cherrypicked from 4e59db328d8b0cc163d2e3eb0f7f3a108f20a58d)
The bulk of package moving already occurs on the handler thread,
but one of the precondition steps requires that we make an installd
call to calculate disk space of the app. If there was already
another long-running installd call going on, we could end up ANR'ing
the caller.
Since movePackage() is already designed to return a moveId and go
async, we can push all the precondition steps onto the handler thread
to prevent the ANR.
Bug: 25490003
Change-Id: I62d555c23bbf81b791f6f4cabc40c3d64c580cf8
I think what probably happened is that since we only report an app
going in to the "interaction" state as an interaction event to usage
stats, apps that sit around in that state forever will only see one
interaction at the start and never again. So usage stats could start
thinking they are idle.
Fix this by having the activity manager report an interaction event
for such long running applications at least once a day.
Also, because it is correct and for paranoia by protected us another
way, system uids should never go in to standby.
Change-Id: I8a3805bfca86cbe78560488a649ecd07427da99a
When copying all fields from one PackageSettingBase to another, we
also need to copy volumeUuid, which had previously been missed.
Without this, packages using sharedUserId that are installed on
adopted storage devices will be destroyed, since after reboot we
think they actually belong on internal storage (where volumeUuid is
null).
Bug: 25334169
Change-Id: I223361bd1e19e7d5dd78626682ac7c5cbecb9fa1
During system boot, we prune app-ops belonging to apps that have
been uninstalled. However, apps installed on adopted storage devices
haven't been scanned at this point, so they appear to be uninstalled.
To avoid pruning app-ops for these apps, we need a getPackageUid()
variant that also considers "uninstalled" apps for which we still
have PackageSetting values.
Bug: 25206071
Change-Id: I1820f674d45c5ddc1c5f10ed7d859e7025005e28
This violates a MUST in RFC2131, but apparently some
implementations don't know or care.
Bug: 25343517
Change-Id: I80459b58ffe231e7ed64e77bafa157a96b745149
This helps with some cases where perisistent network connections
need a more frequent keep alive signal. Actually make it 9
minutes to ensure that things needing a 10 minute cycle will
execute within that time.
Change-Id: Ife8c7b7f7f82b108d5a6c1624bd6115e6087c3be
