Each user has its own Settings.System.* and Settings.Secure.* namespace now. In
addition, this CL introduces the new Settings.Global.* namespace, which contains
a number of previously-elsewhere named settings entities; these Global.* entities
are common to all users. Because these elements have been moved from their prior
existence in the other namespaces, attempts to access them under their old names
and namespaces are detected and redirected (with appropriate compile-time and
logging messages) to their new homes.
The new Global.* namespace can only be written by system-level code, just like
the existing Secure.* namespace. If an app attempts to write a key that was
previously in the System.* namespace but has been moved to the Global.* namespace,
then a warning is logged and no write is performed; the action is a no-op. (The
app is explicitly not crashed, to avoid breaking well-behaved apps that can't
know any better.)
There is also now a hidden API for getting/setting settings entities associated
with a user other than the caller's. Reading/writing data for a user other than
yourself requires the signature-level INTERACT_ACROSS_USERS_FULL permission.
Manipulating data for a different user cannot be done via the ContentProvider
query() / insert() APIs; you must use the Settings.get/put APIs for that degree
of control. In general, use of the get/set API is *strongly* preferred over
query-type access to Settings.
Bug 6985398
Change-Id: Ibee54ddff99fb847c8c2479c23b50f1e7524d724
When the BaseIWindow.resized method got switched from taking (int x,
int y, ...) to taking (Rect, ...) the SurfaceView.MyWindow override
never got updated.
Fixes bug 6992324.
Change-Id: Id0b9625559ae0100336f4573f09d313138c8a6e7
Large software layers won't draw if they're larger than the size of the drawing
cache, in which case this log will be triggered.
bug:7078391
Change-Id: Ib42a060b8e3b3642417df9243a086aa15b2989b1
Framework changes to store and read a secure setting for package verification.
Default is on/true.
This setting will be turned on/off via the Settings app.
Bug: 7082362
Change-Id: I6f93d3136add8af0dbbdc664f0473c5f5b7e3fee
Bug: 7073422
The feature that is using search box implementation was removed from
browser after Honeycomb. This is to remove the js interface that
is added for this feature.
Change-Id: I9441d461caf189467e4ad45de958c13b81f4ff17
- cache the text aligment as we cannot resolve the text alignment during reset of the text direction
Change-Id: I79de625e517bf8bad6313fd5e349f1181b1eaa30
New API to register as an explicit user, which allows you to
also select ALL to see broadcasts for all users.
New BroadcastReceiver API to find out which user the broadcast
was sent to.
Use this in app widget service to handle per-user package broadcasts
and boot completed broadcasts correctly.
Change-Id: Ibbe28993bd4aa93900c79e412026c27863019eb8
This will make the default value of the automatic synchronization
in the SyncStorageEngine configurable with overlays for use by
vendors who want or have legal requirements to have the synchronization
off by default.
Change-Id: Iabdb355c4a1169fe8e254e91c43e162c5913d5e0
SearchView uses SearchManager.APP_DATA to pass data between the origin activity
and the search activity. This works for text searches (keyboard), but it's not
implemented by voice recognition searches. The method createVoiceAppSearchIntent
initializes a empty bundle that is filled with the QUERY parameter.
This patch adds the SearchManager.APP_DATA parameter if is present, let the
search activity access to the data passed by the origin activity
Patch 2: Fix code style
Change-Id: I52dce34e1efd07a30ad74d52bfc60fbae1c4310b
- Refactor DragState to take Display instead of DisplayContent.
- Rename xxxAnimationLw methods in WindowManagerPolicy to xxxPostLayout
to reflect animation refactoring.
Change-Id: I502f2aa45a699ad395a249a12abf9843294623f0
Added more complete support for logical displays with
support for mirroring, rotation and scaling.
Improved the overlay display adapter's touch interactions.
A big change here is that the display manager no longer relies
on a single-threaded model to maintain its synchronization
invariants. Unfortunately we had to change this so as to play
nice with the fact that the window manager wants to own
the surface flinger transaction around display and surface
manipulations. As a result, the display manager has to be able
to update displays from the context of any thread.
It would be nice to make this process more cooperative.
There are already several components competing to perform
surface flinger transactions including the window manager,
display manager, electron beam, overlay display window,
and mouse pointer. They are not manipulating the same surfaces
but they can collide with one another when they make global
changes to the displays.
Change-Id: I04f448594241f2004f6f3d1a81ccd12c566bf296
