This system-only permission allows a service to disable the transmit LED
when a camera is in use.
Bug: 8554573
Change-Id: I64f7e3fcdc8ded8be3904650bd0c91d3b8f10dd4
Accessibility services can perform special operations such as retrieve
the screen content, enable explore by touch, etc. To ensure the user
is aware that the service will perform special operations we were using
permissions. However, the special operations cannot be performed unless
the service is really enabled by the user and it is at this point that
we want to notify the user about the service capabilities.
This change adds capability attributes to the accessibility service's
meta-data XML file. The service has to declare the capability and when
it is enabled we show the user the capabilities in the warining dialog.
bug:8633951
Change-Id: Id3442dc71dad018e606888afdc40834682fdb037
This covers the scenario where an app doesn't find an account of the
required type and requests the account manager to add one of that
type.
Bug: 8537648
Change-Id: I4d9c8842c2d90aa668f16034d3db007dc61714b8
This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.
Use this power wisely.
This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]
Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2
Protect app widget broadcasts from abuse.
In this case the app was sending an APPWIDGET_UPDATE broadcast
without specifying a target, which (a) should not be allowed (you
should not be able to send updates to other apps), and (b) resulted
in every single potential app widget in the system being launched...
which was about 75 of them.
Change-Id: I9d48733610ce6d5a7c32e69a3e06b9f33bd79a34
Show notification when a bugreport is finished, letting the user
launch a SEND_MULTIPLE intent to share them. Add dialog that warns
user about contents before sharing. Since bugreports are now stored
in private app data of the Shell app, use FileProvider to build Uris
that we can grant others access to.
Define BUGREPORT_FINISHED as being a protected broadcast. Delete
older bugreports automatically to reclaim disk space. Migrate any
Intent extras to ClipData when building PendingIntents.
Add --receiver-permission support to am shell command.
Bug: 7005318
Change-Id: If6c607dbcf137362d5887eac482ff7391563890f
It is beneficial that there is a mechanism on the platform
to notify applications whether it is safe to perform somehow
expensive operations while the user is not using the device.
Thus, user experience will not be degraded. An example is
discarding of unused blocks on a mounted file system instead
of doing this on every write operation.
bug:8056794
Change-Id: I708bad9d3ce6c8f1d5a1c05c0abf46f81a3d464b
Also add a hook for ConfigUpdateInstallReciever subclasses to
change the delivery of data- in this case, from raw text to
b64 encoded binary.
Change-Id: I4859c8db1cc97c2427310a108b2fef03975df2b4
# Via Android Git Automerger (1) and Doug Zongker (1)
* commit '9c4ba4fe752b131b01aa402389c96eb8f24764b8':
add android.permission.LOOP_RADIO for access to loop radio device
Currently we have an "enhance web accessibility" setting that has to be
enabled to make sure web content is accessible. We added the setting to
get user consent because we are injecting JavaScript-based screen-reader
pulled from the Google infrastructure. However, many users do not know
that and (as expected) do not read the user documentation, resulting in
critique for lacking accessibility support in WebViews with JavaScript
enabled (Browser, Gmail, etc).
To smoothen the user experience now "enhance web accessibility" is a
feature an accessibility plug-in can request, similarly to explore by
touch. Now a user does not need to know that she has to explicitly
enable the setting and web accessibility will work out-of-the-box.
Before we were showing a dialog when a plug-in tries to put the device
in a touch exploration mode. However, now that we have one more feature
a plug-in can request, showing two dialogs (assume a plug-in wants both
features) will mean that a user should potentially deal with three
dialogs, one for enabling the service, and one for each feature. We
could merge the dialogs but still the user has to poke two dialogs.
It seems that the permission mechanism is a perfect fit for getting
user permission for an app to do something, in this case to enable
an accessibility feature. We need a separate permission for explore
by touch and enhance web accessibility since the former changes the
interaction model and the latter injects JavaScript in web pages. It
is critical to get user consent for the script injection part so we
need a well-documented permission rather a vague umbrella permission
for poking accessibility features. To allow better grouping of the
accessibility permissions this patch adds a permission group as well.
bug:8089372
Change-Id: Ic125514c34f191aea0416a469e4b3481ab3200b9
When launching an assist, we have a new API allowing the
current foreground activity/application to provide additional
arbitrary contextual information that is stuffed in the
assist intent before it is launched.
Change-Id: I0b2a6f5a266dc42cc0175327fa76774f814af3b4
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
Initial implementation, tracking use of the vibrator, GPS,
and location reports.
Also includes an update to battery stats to also keep track of
vibrator usage (since I had to be in the vibrator code anyway
to instrument it).
The service itself is only half-done. Currently no API to
retrieve the data (which once there will allow us to show you
which apps are currently causing the GPS to run and who has
recently accessed your location), it doesn't persist its data
like it should, and no way to tell it to reject app requests
for various operations.
But hey, it's a start!
Change-Id: I05b8d76cc4a4f7f37bc758c1701f51f9e0550e15
- Remove SEND_SMS_NO_CONFIRMATION
- Add SEND_RESPOND_VIA_MESSAGE Permission
This permission is held by the phone and applications that want to
handle respond-via-message should require this permission of the
sender. This permission is signature/system and currently only held
by the Phone app.
Bug: 5108429
Change-Id: Ib611368d488de2f8e1e853f550eb2c654305eda4
According to the javadocs for these intents, they are all
protected intents. It appears the original author forgot
to add them to this file.
Change-Id: I025061716d5707f10939019f2bc5bc3d4d23b04f
At least one of these was getting spoofed in the wild.
We don't want to go too far this late in the game, but this is a good start.
bug:7622253
(cherry picked from commit 47918ae3b4e7ebb54711884e9ff9d0300591ab8b)
Conflicts:
core/res/AndroidManifest.xml
Change-Id: I118b31489fe7add5b8d69289cab9f4e8ab269495
At least one of these was getting spoofed in the wild.
We don't want to go too far this late in the game, but this is a good start.
bug:7622253
Change-Id: Id8ec2778b15fe001e6fd0d5a010181bb21c52ad8
Also, remove ability to filter widgets by feature
in appwidget picker in anticipation of api change
Change-Id: I325de0b98f03d3a250758d504229ea27794b5330
Create a BLUETOOTH_STACK permission to share between all users of
Bluetooth apk. Bluetooth Manager binds to apk of current user
bug 6925422
Change-Id: I2df5546e977c2d77bc66d97d12479d933826922a
Issue #7211769: Crash dialog from background user has non-working "report"
The report button now launches the issue reporter for the correct user.
Also for crashes on background users, either disable the report button,
or simply don't show the dialog depending on the build config.
Issue #7244492: Bugreport button in Quick Settings doesn't actually do anything
Now they do.
Issue #7226656: second user seeing primary user's apps
I haven't had any success at reproducing this. I have tried to tighten up
the path where we create the user to ensure nothing could cause the
user's applications to be accessed before the user it fully created and thus
make them installed... but I can't convince myself that is the actual problem.
Also tightened up the user switch code to use forground broadcasts for all
of the updates about the switch (since this is really a foreground operation),
added a facility to have BOOT_COMPELTED broadcasts not get launched for
secondary users and use that on a few key system receivers, fixed some debug
output.
Change-Id: Iadf8f8e4878a86def2e495e9d0dc40c4fb347021
Contacts app uses a custom account picker which calls the system account picker
when an account needs to be added. The system accout picker invokes choose
accout type dialog which overlays over the system acccount picker. Because these
two dialog boxes use different themes, he one behind is wider than the one in
foreground and ends up looking like a thin black strip protruding from the two
sides.
Bug: 6980517
Change-Id: Ia8b23767d995dcbe1a58087cb4bfbee140c2c744
1. This change adds a global gesture for enabling accessibility.
To enable this gesture the user has to allow it from the
accessibility settings or use the setup wizard to enable
accessibility. When the global gesture is enabled the user
can long press on power to bring the global actions dialog
and then hold with two fingers for a few seconds to enable
accessibility. The appropriate feedback is also provided.
2. The global gesture is writing directly into the settings for
the current user if performed when the keyguard is not on. If
the keygaurd is on and the current user has no accessibility
enabled, the gesture will temporary enable accessibility
for the current user, i.e. no settings are changed, to allow
the blind user to log into his account. As soon as a user
switch happens the new user settings are inherited. If no
user change happens after temporary enabling accessibility
the temporary changes will be undone when the keyguard goes
away and the device will works as expected by the current user.
bug:6171929
3. The initialization code for the owner was not executed due
to a redundant check, thus putting the accessibility layer in
an inconsistent state which breaks pretty much everything.
bug:7240414
Change-Id: Ie7d7aba80f5867b7f88d5893b848b53fb02a7537
