After reset (docking) Pixel C Keyboard that was previously paired with
a device goes into so-called non-discoverable mode, where it will
establish connection only with device that it has connected before. When
scanning for available devices we need to wait till the keyboard starts
advertising itself as discoverable, and only then try to pair.
Also, let's flush the device cache when we attach the base to make sure
the device that we seen before and cached again in the right state after
reset.
Bug: 24915541
Change-Id: I136c1c4235080a25529b4b1c2b1da9bc18508811
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
A crash occured on updating after calling removeSelection with showing
selection handlers. This was because some selection-handler code didn't
consider the case the selection index was -1 (-1 means there is no selection).
This patch fixes this crash.
Bug: 23299977
Change-Id: I736d315e073f773aec597522203015205a8da42b
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
