This is just the initial state tracking. Still to go is
actually triggering Bluetooth A2DP correctly and tracking
process state in the system server.
Change-Id: I33031d52799d6e2d7208910da833831085cc3677
- Added radio buttons to indicate the selected item
- "Add account" is one of the list options instead of a button
- Removed icons
- Added "Cancel" and "OK" buttons
- Use dialog theme
- Omit description text by default
Bug 6505441
Change-Id: I672a11481ee99e183142142bddf8f97b7b149d37
Added bitmaps for permission group icons. We had to pick either
icons for a dark or light background, and it had to be light for
settings, so the installer theme has gone back to dark.
Tweaked the permission groups to match the icons.
Redid the group priorities to make them correct (they were written
with higher priorities being less important).
Fixed bug where priority was not being used for system apps.
Change-Id: Ia3d3f0c1614a11b4cfd11682ce9e6c9f87d75c06
These groups are assigned priority for sort-order when displayed to users, and use
the new permissionGroupFlags to indicate whether they contain personalInfo.
Change-Id: I27e81912e08b8d7766b8ce449b4b3bd6473d8f07
Introduce IRingtonePlayer, which handles playback for both Ringtone
objects and Notifications. SystemUI now hosts this player, which it
registers with AudioService. It also keeps MediaPlayer instances
warm, and cleans them up after stop() or Binder death.
Move both Ringtone and NotificationManagerService to play back audio
through this new interface.
Bug: 6376128, 6350773
Change-Id: I1dcb86d16ee3c4f07cdb2248d33dcff4ead3609a
These intents should only be sent by the system:
android.intent.action.HEADSET_PLUG
android.intent.action.ANALOG_AUDIO_DOCK_PLUG
android.intent.action.DIGITAL_AUDIO_DOCK_PLUG
android.intent.action.HDMI_AUDIO_PLUG
android.intent.action.USB_AUDIO_ACCESSORY_PLUG
android.intent.action.USB_AUDIO_DEVICE_PLUG
Change-Id: I7be41892a9c4e619ca3e1c892fad6f1f2714c74f
Signed-off-by: Mike Lockwood <lockwood@google.com>
To give RINGTONE_PICKER external storage access, move it from system
to MediaProvider. Fix OOBE when getRingtoneUri() kicked requery().
Bug: 6346701
Change-Id: I837002eef0580b8cdd8920a27b068c745995a8a3
Third party apps now can't get access to the extras of the
intents associated with tasks, to keep private data in them
from leaking out.
Change-Id: I95af9e181ac42557bc8b981807e7ddd266a88d0e
Add permissions for various things it pokes. Create new permission
to control launching non-exported activities from recents. Hidden
API to relax WallpaperService checks.
Change-Id: I547fdcd7c213dd153ae101533ce7c56cd8f86a0d
The CellBroadcastReceiver app will allow apps with the new permission
"android.permission.READ_CELL_BROADCASTS" to read previously received
cell broadcast messages from a new ContentProvider database at URI
"content://cellbroadcasts". This will enable third parties to provide
additional information to users in the event of emergencies without
delaying or interfering with the initial system alert dialog to warn
the user when the alert is received.
Includes a new android.telephony.CellBroadcastMessage class which
can be instantiated from the Cursor retrieved from the ContentProvider.
This was previously a part of the CellBroadcastReceiver app, but can now
be used by third party apps with read permission on the ContentProvider.
Change-Id: I2c31f62b63c050c7946de2d81c28a5f4dc6f00b0
Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.
Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.
InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.
Added a fake InputDevice with ID -1 to represent the virtual keyboard.
Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
Also lock down the rest of the development tools permissions to
be development permissions that must be granted through an
explicit shell command.
Change-Id: I1ba216fffe1aab4bb9f83fcef108efc504f892f4
Simplified input injection API down to just one call.
Removed all input state reading API. It was only used by the
window manager policy and required a permission that applications
could not obtain. READ_INPUT_STATE is now unused and deprecated.
Change-Id: I41278141586ddee9468cae0fb59ff0dced6cbc00
Broadcast intents that get sent out when users are added/removed/switched.
More work on generating user-specific information in package manager queries.
APIs to update user name and query a user by id.
Removed Package.mSetStopped and mSetEnabled, since they're not user specific.
User removal:
- Cleanup ActivityManager, PackageManager, WallpaperManager, AppWidgetService
and AccountManager.
- Shutdown processes belonging to the user.
Don't show vibrate option in long-press power if there's no vibrator.
Lock the screen when switching users, to force unlocking.
Change-Id: Ib23a721cb75285eef5fd6ba8c7272462764038fa
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: I3709c831fc1883d7cb753cd2d3ee8e10a61e7e48
These are permissions that an application can request, but won't
normally be granted. To have the permission granted, the user
must explicitly do so through a new "adb shell pm grant" command.
I put these permissions in the "development tools" permission
group. Looking at the stuff there, I think all of the permissions
we already had in that group should be turned to development
permissions; I don't think any of them are protecting public APIs,
and they are really not things normal applications should use.
The support this, the protectionLevel of a permission has been
modified to consist of a base protection type with additional
flags. The signatureOrSystem permission has thus been converted
to a signature base type with a new "system" flag; you can use
"system" and/or "dangerous" flags with signature permissions as
desired.
The permissions UI has been updated to understand these new types
of permissions and know when to display them. Along with doing
that, it also now shows you which permissions are new when updating
an existing application.
This also starts laying the ground-work for "optional" permissions
(which development permissions are a certain specialized form of).
Completing that work requires some more features in the package
manager to understand generic optional permissions (having a
facility to not apply them when installing), along with the
appropriate UI for the app and user to manage those permissions.
Change-Id: I6571785c6bb5f6b291862b7a9be584885f88f3a5
1. Added methods to the ActivityManagerService remote interface
that allow accessing content providers outside of an application.
These methods are guarded by an internal signature protected
permission which is given to the shell user. This enables a
shell program to access content providers.
2. Implemented a shell command that takes as input as standart
fagls with values and manipulates content via the content provider
mechanism.
Change-Id: I2943f8b59fbab33eb623458fa01ea61a077b9845
SerialManager: provides access to serial ports
SerialPort: for reading and writing data to and from serial ports
IO with both array based and direct ByteBuffers is supported.
Accessing serial ports requires android.permission.SERIAL_PORT permission
Each platform must configure list of supported serial ports in the
config_serialPorts resource overlay
(this is needed to prevent apps from accidentally accessing the bluetooth
or other system UARTs).
In addition, the platform uevent.rc file must set the owner to the
/dev/tty* files to "system" so the framework can access the port.
Signed-off-by: Mike Lockwood <lockwood@android.com>
Services now must explicitly opt in to being accessed by isolated
processes. Currently only the activity manager and surface flinger
allow this. Activity manager is needed so that we can actually
bring up the process; SurfaceFlinger is needed to be able to get the
display information for creating the Configuration. The SurfaceFlinger
should be safe because the app doesn't have access to the window
manager so can't actually get a surface to do anything with.
The activity manager now protects most of its entry points against
isolated processes.
Change-Id: I0dad8cb2c873575c4c7659c3c2a7eda8e98f46b0
Add a system permission to enable the use of any installed
media decoder when decoding for playback (as opposed to transcode).
Change-Id: Ifb10a5fa8d5663a78ccbb5fa8266ad6535c234f2
This is a manual merge of a change going in to ICS-FactoryROM.
These permissions are needed to separate the (potentially invasive)
access to the user's social stream from the existing read/write
contacts permission.
Per discussion with Android release team, we are also hiding the
stream item API until we figure out a better way to guard the data.
Bug 5406886
Change-Id: I8339d743c3ebe8923c7ee47f2900444efcf82a52
- made the UI match the spec
- added ability to force the account chooser to appear
- added ability to pass in a description that will override the stock one
- added ability to pass in requiredFeatures for addAccount
- added ability to pass in an authTokenType for addAccount
Bug: 5293377
Change-Id: I243c0fd6598c943b1f65753e1f5d3c86629f64f5
A core app is one that has coreApp="true" in its manifest tag.
The system can successfully boot (though a little painfully) with
only framework-res.apk, SettingsProvider.apk, SystemUI.apk,
DefaultContainerService.apk, and Launcher2.apk set as core apps.
Currently this boot mode is always turned off.
Change-Id: Ieaa4a8031c2c391a12996aa8d8b1d65fc2b09d6b
The resolver activity was hiding the following activity from recents.
Also some other fixes: a little better memory use debugging, removed
some unneeded code from window manager, moved some system activities
into their own process, added some more running process information for
manage apps.
Change-Id: I66687d16989ff965d524b92dc360f37c19199717
These intents are sent by Bluetooth-Pbap app which doesn't
have the system uuid. Instead protect with admin permission
on the reciever side.
Change-Id: Ibb788e1526108909b5a3b15462ac3a008b041613
Protects us from apps getting packet snooping ability
(ie, routing all your traffic through their server by
modifing your APN settings). We may eventually revert this
if/when we have time to provide a proper API and scary UI
like VPN has.
bug:5242750
Change-Id: I71d73807ca5268c6aacc2156839b4d11427048c4
New broadcast that is dispatched immediately after connectivity
changes have been handled by ConnectivityService, bypassing any
applicable CONNECTIVITY_CHANGE_DELAY.
Also protect CONNECTIVITY_CHANGE broadcasts, since they should only
be sent by system.
Bug: 5198167
Change-Id: I75f1fb44b21da1879f0ab960bcaa481126d70fde
- Add methods to TelephonyManager to provide access to IMS records on
the ISIM application of the UICC, as well as access to the ISIM
AKA authentication algorithm.
- Add support for the new IMS methods to CDMALTEPhone, using the helper class
ImsUiccRecords to load the IMS records from the ISIM. The same approach
can be used to implement IMS support for UMTS/LTE devices.
- There is a new RIL request, RIL_REQUEST_ISIM_AUTHENTICATION, which is
used to perform IMS AKA authentication using the algorithm on the ISIM
application of the UICC. The challenge nonce and response are both encoded
as Base64 strings.
Change-Id: I73367c7d9bc573d0d883d68adf09891de1319129
