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
Dream manager now fires broadcast intents when entering + exiting
dreamland (except when testing).
Power manager can now listen for dreams ending, using polling only
as a backstop.
Also:
- Bullet-proof dream-manager/dream against known failure modes
- Add new read/write dream permissions
- Refactor dream-manager to delegate work + state management into
a new DreamController class, via a handler
Bug:6999949
Bug:7152024
Change-Id: I986bb7812209d8c95ae1d660a5eee5998a7b08b1
7173152 API REVIEW: android.content.pm.PackageUserState
7172969 API REVIEW: android.app.PendingIntent
7172730 API REVIEW: android.content.Context
7172726 API REVIEW: android.manifest.permission
Change-Id: Iad470256d3b5ca5596487f6a699ec1871457c3b5
- New "cost money" flag can be put on a permission to
have this emphasized in the UI.
- Some further re-organization of permissions to better
match UX spec.
Change-Id: I450ac739eff6b90e7c7fc39589d68db82b61f897
- New public APIs to find out when a user goes to the foreground,
background, and is first initializing.
- New activity manager callback to be involved in the user switch
process, allowing other services to let it know when it is safe
to stop freezing the screen.
- Wallpaper service now implements this to handle its user switch,
telling the activity manager when it is done. (Currently this is
only handling the old wallpaper going away, we need a little more
work to correctly wait for the new wallpaper to get added.)
- Lock screen now implements the callback to do its user switch. It
also now locks itself when this happens, instead of relying on
some other entity making sure it is locked.
- Pre-boot broadcasts now go to all users.
- WallpaperManager now has an API to find out if a named wallpaper is
in use by any users.
Change-Id: I27877aef1d82126c0a1428c3d1861619ee5f8653
* changes:
DO NOT MERGE Push event logging down into libcore.EventLogger
DO NOT MERGE Added event logging for config installation failures.
DO NOT MERGE Create intermediate directories when installing config data.
DO NOT MERGE Add components for the Android Config Updater to system server.
This adds the necessary bits to verify and install configuration
updates using system server. It also includes the cert pinning
updater as the first user.
Change-Id: I42307f58074157b33b6e01216aab10022340d449
The window manager now has a facility to provide a full-screen
animation, which the activity manager uses every time a user
switch happens.
The current animation is just a simple dumb slide until we get
a design from UX.
Also some cleanup: moved the portrait task animations to the
default config so we always have an animation for them, and finally
got the java symbol stuff out of public.xml.
Change-Id: I726f77422b2ef5f2d98f961f8da003e045f0ebe8
