Loading the avatar icons and drawing them into the sized bitmap
turns out to be quite expensive and the cost increases with number
of users. Caching them shaves off several hundred milliseconds from
Keyguard inflation time during user switching on the lockscreen.
For instance, 15ms vs. 750ms with 3 avatars on a certain 7" tablet.
Bug: 7986933
Change-Id: I3e2065bfa25aa263133ba204ca364c3b04d7c0ff
For restricted profiles, if an app tries to guess an account name and
requests an auth token, even though the framework is going to prompt
for permission, it could be authorized by someone who can't read.
If the app is not opting in to see accounts, don't let it get auth tokens
by verifying first that it's in the list of known accounts.
Bug: 8736380
Change-Id: I6caf88cfe14aa1023d55bcb28ad80ccd89eeb79b
Touch exploration and enhanced web accessibility can be toggled at
run time. However, the code that updates the state of these features
was not properly doing that. In particular, it did not write to the
settings if the feature gets disabled. Now the logic is much cleaner.
If there is a service that can request and requests a feature and
the feature is not enabled, we enabled it, otherwise the feature is
disabled.
bug:8790771
Change-Id: I218dfa12fd02220c94940b54f42bed578811a794
Because the resolve activity always assumes CATEGORY_DEFAULT, there are odd
cases where apps with malformed intent filters wind up interfering with
users' ability to specify a preferred launcher app.
Bug 8805220
Change-Id: I4c1295dc844e442eec6efd603ce11b673879dd5a
Cherry-pick of I0c383eb82ed041e57a7d32321df2d67b462d4e21 from master
Oops, it seems the fused location provider was being denied access
to locations when any user other than the primary device owner is
logged in. This was breaking the fused location provider entirely
for all secondary users of a given device.
Bug: 8766225
Change-Id: Ic0db5f2094828c897a405abb0dca6ac39a2ca526
When we've installed an apk from the archive, recheck whether
to apply the system-uid policy restrictions around file system
restores.
Bug 8833099
(cherry picked from commit 2baf6dcfcf7fc1705db25e64dc0cb11fa3509d39)
Change-Id: I972fe1543f2234aa76baf562d6f806175ac0248e
When we've installed an apk from the archive, recheck whether
to apply the system-uid policy restrictions around file system
restores.
Bug 8833099
Change-Id: Ifa1b5877673a0d6ca6acf94e60f314fd0dda008c
IActivityController has a new callback which the Watchdog calls
when it detects that the system process is hung. This may be
use full monkey. All hail the monkey!
Also add a new private feature to Binder to be able to turn off
all incoming dump() calls to a process. The watchdog uses this
when it reports it is hung, so that if someone, say, wants to
collect a bug report at this point they won't get stuck waiting
for things that are all busted.
Change-Id: Ib514d97451cf3b93f29e194c1954e29f948c13b1
1. The scheduling was relying on receiving battery level broadcasts
which however are not sent if the device is asleep. The maintenance
window was not bound and we could miss a frame if the user did
not interact the device longer than the min time between two
maintenance windows.
2. Hide the idle maintenance intents since this will be rewritten
to user services.
bug:8688454
Change-Id: I17b421b09823cb46ec218cabda19e02432d94f8c
1. When a service dies we clear its state and remove it from the bound services waiting
for new onServiceConnected call in which to initialize and add the service. The
problem is that after clearing and removing a dead service there is a call to
onUserStateChangedLocked with will end up rebinding to the service, so we get
multiple onServiceConnected calls as a result of which we add the service twice and
it becomes a mess. Note that every time the service dies we end up being bound to
it twice as many times - royal mess! onUserStateChangedLocked is not even needed
since we cleare and remove the serivce and this method will be called when
the service is recreated.
2. When a service dies and is recreated by the system we were not adding it properly
since we regarded only services that we bond to and wait for the connecton. Now
we are also regarding service which died and are recreated.
bug:8796109
Change-Id: I5ec60c67bd3b057446bb8d90b48511c35d45289d
Also be sure to drop any pending package-changed broadcasts
that are targeted to a now-removed user.
Bug 8594153
Change-Id: Ib14874b4a67b968bbf6ca12ee095c85383aff324
...app storage size for apps w/ .so files
The lib directories are tagged with the apk install number,
so must be explicitly passed down to installd.
Change-Id: Ic37b03726f9a7405eb05956703f8198223b22595
Bug: 8365223
This change is a supplement for I77f01c70610d82ce9070d4a
The disabled state of disabled pre-installed imes should be changed
to ENABLED_STATE_DISABLED_UNTIL_USED on boot or user switch.
Change-Id: If8ff1b2b95c36d33148def2ab87bd006aa520cc0
I.e. don't bother trying to send a BOOT_COMPLETED broadcast to the
newly-installed/enabled system app when its host user isn't live.
Also use the static isSystemApp()-type helpers instead of duplicating
those tests locally.
Bug 8594153
Change-Id: I4bd0b86351d67f72c44eae8d1afce6a98f034d31
Recent changes started watching for CONNECTIVITY_ACTION broadcasts
to handle the case where a network is disconnected without the
interface going down.
However, when lockdown VPN is enabled, the broadcast contents are
augmented, and all connections appear disconnected until the VPN
comes online. This caused a reset feedback loop to occur.
Since LockdownVpnTracker already handles networks being disconnected
separately from interfaces going down, this change disables handling
the broadcast when lockdown is enabled.
Bug: 8755148
Change-Id: I70a348aa97a4b22eaaf23aa5ed344de3e9a9ab0b
Specifically, send it a BOOT_COMPLETED broadcast just as it would have
received during device (or user) startup.
Bug 8594153
Change-Id: I847c16df56d038a25758e594f951bc15348edc19
This change is removing the check for debuggable build to
log fstrim events. While this was done everywhere else, one
place was overlooked.
bug:8688454
Change-Id: I354e1deebfd801f971dd91b9e7972c6ebfd093f3
Added the precondition that the device should be charging to the
existing ones of the device not being used for awhile and the
battery level being high enough. Note that even if the device is
charging, we have to check the battery level since the user can
unplug it at any time.
bug:8688454
Change-Id: I709b1620571301743dc3504a6a625e2018951bfa
