1. Add the permission protection level in the java doc
2. Make some system permissions that are not mean to be
used by third-parties system API.
bug:21402257
Change-Id: Ic0ae8d6ca44dbbbf12848a9164acc0e908c90402
All options are sent to the VoiceInteractor once ChooserTargetServices
have reported in. We don't perform explicit progressive refinement or
filtering, but an explicit option picked will be invoked.
Also fix a lingering bug around being able to nested-fling the
resolver drawer closed.
Bug 21516866
Change-Id: I6b141f5fa87d74dccec9dcb88110630696e9c38e
Removing the read/write profile/social stream permissions as they
are not needed anymore. These permissions are for accessing data
nested in the conacts provider which is already guaded by the
read/write contacts runtime permissions. The removed permissions
would be in the contacts group which means they would not provide
more protection compated to read/write contacts. Also removing
the permissions voids the need for app op support for legacy apps.
Removed deprecated APIs for social streams as these were deprecated
and will go away in the next release. We want apps targeting M to
not be able to compile if still suing these APIs to help with
migration.
Change-Id: I26ed9055847af7f92c78eb0f4ac8f9f1aa616fcd
We have a new storage permission group that has read and
write external storage. However, read external storage is
(not a regression) a normal permission while write is a
dangerous one. This leads to cases where the user disables
the Storage permission and apps still read form it. This
change makes read external storage a dangerous permission.
bug:21949045
Change-Id: I7e28f629dda6e9c1f70cb20a3d5bea74fb109890
Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light.
Though wise men at their end know dark is right,
Because their words had forked no lightning they
Do not go gentle into that good night.
Bug: 21854466
Change-Id: I0b7cd116c23f7df88e94f31b3aee7dd22a102804
Add hidden TelecomManager.setDefaultDialer for system apps
to set the default dialer and trigger the broadcast
Bug: 21846308
Change-Id: Ifdd30cd1323ab0157edf7fd966173b6c52df6ba0
This permission guards only hidden and system APIs, hance it
should be signatureOrSystem protection level.
Change-Id: I8d2b75167c6887a285af0b494c39b4ffea2f0cbf
b/20220885
Instead, move it to GSF:
ag/700092
SUBSCRIBED_FEEDS_READ/WRITE permissions guard the Content Provider
that stores sync feeds for 1p apps (Gmail, Claendar, etc).
The sync feeds are used for delivering and processing
GCM tickle-to-sync messages.
These permissions should not be used by 3rd parties but
if they were, this change will break them.
I don't know the reason these were not in GSF and 'signature'
to begin with. If someone does, please, comment.
Change-Id: I6c4e4c774fea12c7fe7082477c210ad75f007c66
Requires updating the docs in AccountManaager as well as the logic in
AccountManagerService.
MANAGE_ACCOUNTS, USE_CREDENTIALS, and AUTHENTCATE_ACCOUNTS are going
away. Where AUTHENTCATE_ACCOUNTS was required we now do signature
matching.
GET_ACCOUNTS is kept but has been grouped under contacts.
Bug: 20136477
Change-Id: Iabbb76dce8d1efc607c1f107911d7ddab598a481
- User flow is now similar to requesting access to notification
content, namely prompting the user to visit a settings page
for enabling/disabling apps access.
- New ACTION_NOTIFICATION_POLICY_ACCESS_GRANTED_CHANGED intent
for apps to listen to this state change.
- Removed obsolete request method and associated internal callback
aidl.
- Added new android.permission.ACCESS_NOTIFICATION_POLICY permission
for apps to include as a signal that they want to request this access
(and therefore appear in the list on the settings page).
- Improve javadocs, outline the user flow in NotificationManager#isNotificationPolicyAccessGranted
and link to this method elsewhere.
- NoManService now persists the user-enabled package list across reboots
and does so per-user.
- Rename public settings intent to correspond with the noman api.
Bug: 21621663
Change-Id: I72cbc21cd736e6a157b6be5d1d0ba0b4a8e7ef4e
Previously when a MidiManager client opened a virtual or Bluetooth device,
the client bound directly to the virtual device's MidiDeviceService
or BluetoothMidiDevice's IMidiDeviceServer for the given BluetoothDevice.
Only USB devices were opened in MidiService.
Now opening any type of MIDI device is done via IMidiManager.openDevice() or
IMidiManager.openBluetoothDevice(). MidiService tracks all connnections between
clients and devices.
Services that implement virtual devices must now require android.permission.BIND_MIDI_DEVICE_SERVICE
so only MidiService can bind to these services.
Bug: 21044677
Change-Id: I7172f7b1e0cbfe4a2a87dff376c32dc9b41aa563
