Introduced signature-level permission android.permission.PEERS_MAC_ADDRESS.
It allows access to MAC addresses of WiFi and Bluetooth peer devices, without
having location permission or even if location is turned off.
Bug: 21852542
Bug: 22728628
Change-Id: If0ff80636e57b38dbedc8fcf5f520a3a6d6f734e
It was possible for other apps to request removal of the guest user
that was handled by an internal receiver in SystemUI.
Fix requires the broadcast sender to have an internal permission
so that only SystemUI can send that broadcast (PendingIntent).
Bug: 22671268
Change-Id: I63a8ced692e6d1cb2872b962ad247a827dbafbc6
Long clicking on settings gear in QS causes it to accelarate and
spin, when released it will open and enable the tuner. On first
opening there will be a warning dialog.
Also add way to disable tuner from tuner screen. This way it can
be removed from its former home in Developer Settings. All tuner
settings are reset when disabled to match developer settings
behavior.
Bug: 22462605
Change-Id: Ie700a6a15e6c3caccf7cd1885da73328e6fac6ab
Also removed READ_PHONE_STATE from SystemUI since it has
READ_PRIVILEGED_PHONE_STATE.
Bug: 22376654
Change-Id: I437f9bf324950cb70bae5be76699824da5897a6f
Typical apps are restricted so they can only view shared storage
belonging to the user they're running as. However, a handful of
system components need access to shared storage across all users,
such as DefaultContainerService and SystemUI.
Since WRITE_MEDIA_STORAGE already offers this functionality by
bypassing any FUSE emulation, reuse it to grant the "sdcard_rw" GID
which is no longer handed out to third-party apps. Then we change
the FUSE daemon to allow the "sdcard_rw" GID to see shared storage
of all users.
Bug: 19995822
Change-Id: I504c2a179ba74f142ed0d32da5baa69f4212cd82
Use the (relatively) new API for supplying a callback when a user
makes a selection from the system ChooserActivity to clear out the
screenshot notification after it has been shared to another app.
Change-Id: If023a26d690c5ae8e29f28e2422f694ae4b654cb
Settings already has this permission, and SystemUI needs it as
well so that the changes made by Wi-Fi Quick Settings are
recognized to be made by the system and not just by any app.
Bug: 20081183
Change-Id: Ie1760fc24f5f74839718fff9763f38c80cdda3ff
* changes:
Add test assist to implement motion study
Implement new assist gesture and motion
Add flag to voice interactor for supporting assist gesture
Add more internal API's for assist
Add ability to start voice interaction session directly
Add internal API's for SystemUI to start a voice interaction session
directly, without using an intent.
Make the assist gesture use that ability, if available.
Change-Id: I88ce3c7514714eb45666884847193585a07417a9
If changing wallpaper when low on memory, retrieving the default
wallpaper may return null, which triggers error handling in
ImageWallpaper. This error handling tries to perform
WallpaperManager.clear(), but for that it needs SET_WALLPAPER
permission, which it does not have.
For users with apps that auto change wallpaper, this issue can
be frequent in low-memory conditions.
The solution is to add the permisson.
Change-Id: I81503c1667e3952c2dd15599969f7dcc51623e5b
A couple of changes needed to be made to SettingsLib to support this.
- SettingsLib needed to track ACTION_CONNECTION_STATE_CHANGED
- The summary code needed to move from Settings up into SettingsLib
- Added a getMaxConnectionState to CachedBluetoothDevice
- This simplifies the states of all of the profiles into
one.
Change-Id: I7f828f0038ad0cf39274986ece6d486d545f0286
- cleanup thread issue and simplify native FingerprintService methods
- add new permissions and enforce them
- add fingerprint hardware detection API
Change-Id: I87c2243ea2412061f1e85b044138480d0161bcdf
In the process of front-loading a lot of the loading work, we moved logic
into AlternateRecentsComponent, which is not multi-user friendly. This CL
proxies all the necessary events for non-primary users to their own SystemUI
process to ensure that they handle them correctly, and proxies visibility
changes back to the primary user (since that is the only process with the
right callbacks).
Change-Id: I9fed92214ac4d4e2309ad6ffc35d09b5726c2880
The current implementation uses a whitelist of package names. Use a
system|signature permission instead of rolling our own security and
add that permission to the existing set of whitelisted packages
(SystemUI and VpnDialogs).
In addition to being less of a security risk (using well-known methods
like Context.enforceCallingPermission rather than manually querying
PackageManager and checking UIDs for package names), this enables
other system-privileged apps to control VPN as needed per the below
bug.
Bug: 18327583
Change-Id: I38617965c40d62cf1ac28e3cb382c0877fb1275d
Keep around GET_TASKS as a permission available to apps, so apps still
think they have it and don't get all uppity because they don't.
Add a new REAL_GET_TASKS that is the actual permission now.
Plus some temporary compatibility code until everyone can transition
fromn GET_TASKS to REAL_GET_TASKS.
Change-Id: I12c1102eed24844685dcbd2fa3b612811603958f
Add a new activity attribute, resumeWhilePausing, that allows an
activity specifying it to immediately start running without waiting
for the previous activity to pause. The recents activity is updated
to use this.
The implementation of this is ultimately fairly simple -- if we are
in the path of resuming such an activity, and find that we first need
to pause the existing activity, then within the activity manager we
do the regular pause flow but act like it has immediately finished
pausing right then so that we can immediately go on to the resume.
To make this clean, we tell the activity when asking it to pause that
it should not come back and tell us it is done, because we aren't in
any way waiting for it.
One potentially important change I needed to make here is the pause
callback no longer provides the saved persistent state, because we
now can't count on that callback happening. I don't think there was
really any utility in this anyway -- all modern apps will have their
save state flow happen as part of stopping, not pausing, so we'll
only capture that saved state when the stop is reported back anyway.
And since we do send the saved state back when stopping, it would
always blow away whatever we had gotten at the pause.
Finally, update the documentation for AppTask.startActivity(), and
fix the implementation handling that to be cleaner -- we need to
deal with inTask first before getting in to "oh noes add NEW_TASK
if this isn't coming from a calling activity" flow.
Change-Id: Ia1da0fac90d7bdbaafdda2e34850d795ce17a39f
The SystemUI notification doze implementation needs to run in the
main systemui process.
Bug:16900344
Change-Id: I8b21609087a4bb971bff36fb463eb2482190cd8f
This tile enables/disables hotspot and will show up for 30 days
after hotspot is used.
Bug: 16234190
Change-Id: Iceb4842e021c27c2c4c18651bccdb12957055c3d
Relaunch apps from recents using the same uid and package as was used
in the original launch.
Fixes bug 16358208.
Change-Id: I340800bfee79926b197929360d69f1d570bbf1eb
