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
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 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
Three phases involved:
phase 1: change all code references to circurlar_display_mask_offset to
config_windowOutsetBottom, and mark circular_display_mask_offset
deprecated.
phase 2: remove circular_display_mask_offset from device overlays
phase 3: remove circular_display_mask_offset symbol and default setting.
Bug:25220421
Change-Id: Ia3f77610dbbb964eb58c6b28f6206799d56c44c2
...after more than 60 minutes left
The sensing timeout alarm was being cancelled immediately after it
was scheduled it. Now only cancel it when we are done sensing or
have reset activity.
Change-Id: Id0440cda7dd1b81bf871f16dfb015df6284cf6af
If ALLOW_CROSS_PROFILE_APP_LINKING has been set:
If there is an app with status always across profiles, and some
apps without status always in the current profile: show an intent
picker instead of directly resolving across profiles.
BUG:25109215
Change-Id: I74a67d231284ce912121ea0818109fbf904183e8
There is a race where if you unbind to a service before its
process has come up, we would leave the service record active
and keep it running. Fix this by checking the service state
after its process up and proceed to bring it down if it is no
longer needed.
Also added a similar check when restarting a service, just in
case there are other ways we can get into this situation.
And while I am at it, I tweaked the broadcast queue dump output
a bit to hopefully make it a lot easier to figure out how long
it is taking to process broadcasts.
Change-Id: I46b98f1fe394ab8039ea4cc81fb5d3afb6391a31
This is a partial revert of http://ag/738523 , but not a full
revert because M apps that have gone through the WRITE_SETTINGS
route to obtain permission to change network state should
continue to have permission to do so.
Specifically:
1. Change the protection level of CHANGE_NETWORK_STATE back from
"signature|preinstalled|appop|pre23" to "normal". This allows
apps that declare CHANGE_NETWORK_STATE in their manifest to
acquire it, even if they target the M SDK or above.
2. Change the ConnectivityManager permission checks so that they
first check CHANGE_NETWORK_STATE, and then ask Settings
if the app has the WRITE_SETTINGS runtime permission.
3. Slightly simplify the code in the Settings provider code that
deals specifically with the ability to change network state.
4. Make the ConnectivityService permissions checks use the
ConnectivityManager code to avoid code duplication.
5. Update the ConnectivityManager public Javadoc to list both
CHANGE_NETWORK_STATE and WRITE_SETTINGS.
Bug: 21588539
Bug: 23597341
Change-Id: Ic06a26517c95f9ad94183f6d126fd0de45de346e
When a package is removed during an OTA, we weren't removing it from the
shared user list. This means anyone asking for the packages for a shared
UID would continue to see the old package.
Bug: 24906701
Change-Id: Ifb6d64195e6b8af7454e19591611af66a40cbd10
