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 mClosing was set even though the panel was not
expanding, the variable was never reset leading to
bad states like the notification shade not updating,
people missing calls and similar bad bugs.
Bug: 25338991
Change-Id: I4362fda257770c98c5f9ba75a5622b14f74dc5ae
Adding comments to EXTRA_CALL_RAT_TYPE to make it clear what it is used
for, and what values are expected.
Bug: 20144385
Change-Id: I248aca61abc8a57d7aeef650e48cc498e41c859b
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
Adding the extra key that will be used to
propagate RAT information for each call via
call extras. The key is used in IMS Service.
Bug: 20144385
Change-Id: Ia7ca81d661afb579fd25315036c43489b1dca50d
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
