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
Ensure that the user has had a chance to see it for a few
seconds after screen recording has ended.
Bug: 19121797
Change-Id: I52b69b2029439d42163ead5dc8748889b4f61934
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
Resolver/ChooserActivity sort apps based on usage factors for the last
two weeks. A score of zero means no usage data within that timeframe.
For system health and UI relevance, don't bother even waking up apps
that have zero scores.
Bug 25126166
Change-Id: Iae34a9667eb1985d6fe986670f3fb3f1177576da
When mounting a storage volume after an SDK upgrade, the platform
grants install permissions requested by apps. This patch fixes a
bug that was causing us to re-grant permissions for all installed
apps; we now narrow the granting to just the storage volume of
interest.
Also fixes a bug where scanning of internal ASECs would bump the
VersionInfo of the legacy apps-on-SD volume.
There is still a bug here around internal ASECs not being considered
for re-grants, but that needs to be fixed in a more invasive CL that
creates a separate VersionInfo. In addition, internal ASECs (also
known as forward locked apps) have been deprecated for some time.
Bug: 24583803
Change-Id: I9115fd484ec083bc10a970f5f612860d5a53e520
