Create a setting "verifier_verify_adb_installs" to allow developers to control
package verification on ADB installs only. If package verification is enabled,
the setting will:
0, Do not perform package verification on apps installed through ADB/ADT/USB
and perform package verification on all other installs.
1, Use package verification on all installs. (Default)
Bug: 7183252
Change-Id: I9d3eb8abb5ba5e93f8634d3135794e92ff6273b6
We're adding support for searching for text (books, magazines) and video
(tv, movies).
Bug: 7208141
Change-Id: I19dd2f745518a96b22b02a29c1ab9a89d53cc0cc
Add a setting to globally disable Wifi display.
Fixed a bug where the wifi display broadcast receiver
was running on the wrong thread.
Removed the wifi-display QuickSettings dialog, all functionality
has been moved to Settings.
Bug: 7178216
Bug: 7192799
Change-Id: I9796baac8245d664cf28fa147b9ed978d81d8ab9
Notification and Alarm volumes are per user: they are saved and restored
when the foreground user changes.
Media volume is global: it is still saved and restored per user for
implentation reasons but is copied from one user to the next to ensure
media playback volume continuity when switching users.
Ringer mode (silent, vibrate...) is now a global setting.
Bug 7128886.
Change-Id: I9f4f5a0a3985552bca61c2cc3bbe5a144db755a6
Added a setting that will be used to control whether the user can see the
package verification setting in the Setting app.
Bug: 7022814
Change-Id: Ifa096682e90c83760df5db12c4cf72e2f897db9c
Various wifi settings that are explicitly defaulted did not get their
default code properly converted to refer to the correct settings
database table.
A collection of moved-to-Global settings that had not yet been
marked @deprecated in the Secure.* namespace are now so marked.
Also updated the namespace used to refer to wifi settings from the
Wifi Service. These changes are cosmetic, but they do eliminate a
number of runtime log messages.
Bug 7153671
Change-Id: I9e5b6464d025cfb480ef97373996e38e82f90593
The default behavior for sending a message to a premium SMS
short code (or suspected premium SMS number) is to ask the user for
confirmation. Enable the user to set a default policy ("remember this
choice" checkbox) to always/never allow the app to send SMS to
premium short codes in the future. The policy can be changed by
the Settings app in the app info screen.
Bug: 5513975
Change-Id: I15f45f34dc4da4aef7d0efd675be6bc3a4ceb720
Oops. Stacked bugs: first, the desired user handle was not properly
being passed from the call() entry point to the database operations;
then on top of that, the client-side cache management was still
looking in the local user's cache for the data, so a request to read
a different user's settings would return the local user's instead if
that key was already known to the local user's cache.
Reads and writes of a different user's settings are now uncached,
so they're relatively much slower. They're rare, however, so this
is not something to worry about unless we encounter a real world
case where it's a significant factor.
This CL also adds a bit of cross-user settings read/write testing
to the existing provider suite. These new tests caught both the
known wrong-user-write bug and discovered the client-side cache
bug, so yay.
Finally, the existing wholesale mutual-exclusion approach would
deadlock in certain circumstances due to the fact that the
settings database creation code might have to call out to the
Package Manager while populating the bookmark/shortcut table,
and the Package Manager would then call back into the settings
provider in the course of handling that request. The synchronization
regime has been significantly tightened up now: now the database
code [which is known to deal with concurrency itself] is allowed
to cope with multiple parallel openers of the same db; this
allows the settings provider to avoid calling out to other parts
of the system even implicitly while its internal lock is held.
Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
Also tidy up the bookkeeping for a few settings that were earlier
moved to Global without the redirect tables being fixed up.
Change-Id: I69275db3b2636cd6ba9c8c51b88e97d8ba4b7b7d
(1) It's okay to write literal null as a settings element value
(2) Properly convey the user handle in the put-for-user variant
Bug 7137201
Bug 7139826
Change-Id: I0ed77d65e8377f0e0580a2668f10b7167ad34928
The Settings.System.STAY_ON_WHILE_PLUGGED element should have been
migrated to the global table, but wasn't. This CL does a couple of
things around dealing with this:
(1) Tidies up the migration tables outright, so that they correctly
reflect the intended final state
(2) Introduces the option of doing a key migration only if the element
has not yet been moved to the new table, to allow for safe retry-
-with-ignore. This will make it easy to make any future alterations
to the global vs per-user association of individual elements
(3) Migrates the STAY_ON_WHILE_PLUGGED element if it hasn't been already.
Bug 7126575
Change-Id: Ic5fa9ba45f11b09270bd5bc94c26fbbd84abc749
This change is the initial check in of the screen magnification
feature. This feature enables magnification of the screen via
global gestures (assuming it has been enabled from settings)
to allow a low vision user to efficiently use an Android device.
Interaction model:
1. Triple tap toggles permanent screen magnification which is magnifying
the area around the location of the triple tap. One can think of the
location of the triple tap as the center of the magnified viewport.
For example, a triple tap when not magnified would magnify the screen
and leave it in a magnified state. A triple tapping when magnified would
clear magnification and leave the screen in a not magnified state.
2. Triple tap and hold would magnify the screen if not magnified and enable
viewport dragging mode until the finger goes up. One can think of this
mode as a way to move the magnified viewport since the area around the
moving finger will be magnified to fit the screen. For example, if the
screen was not magnified and the user triple taps and holds the screen
would magnify and the viewport will follow the user's finger. When the
finger goes up the screen will clear zoom out. If the same user interaction
is performed when the screen is magnified, the viewport movement will
be the same but when the finger goes up the screen will stay magnified.
In other words, the initial magnified state is sticky.
3. Pinching with any number of additional fingers when viewport dragging
is enabled, i.e. the user triple tapped and holds, would adjust the
magnification scale which will become the current default magnification
scale. The next time the user magnifies the same magnification scale
would be used.
4. When in a permanent magnified state the user can use two or more fingers
to pan the viewport. Note that in this mode the content is panned as
opposed to the viewport dragging mode in which the viewport is moved.
5. When in a permanent magnified state the user can use three or more
fingers to change the magnification scale which will become the current
default magnification scale. The next time the user magnifies the same
magnification scale would be used.
6. The magnification scale will be persisted in settings and in the cloud.
Note: Since two fingers are used to pan the content in a permanently magnified
state no other two finger gestures in touch exploration or applications
will work unless the uses zooms out to normal state where all gestures
works as expected. This is an intentional tradeoff to allow efficient
panning since in a permanently magnified state this would be the dominant
action to be performed.
Design:
1. The window manager exposes APIs for setting accessibility transformation
which is a scale and offsets for X and Y axis. The window manager queries
the window policy for which windows will not be magnified. For example,
the IME windows and the navigation bar are not magnified including windows
that are attached to them.
2. The accessibility features such a screen magnification and touch
exploration are now impemented as a sequence of transformations on the
event stream. The accessibility manager service may request each
of these features or both. The behavior of the features is not changed
based on the fact that another one is enabled.
3. The screen magnifier keeps a viewport of the content that is magnified
which is surrounded by a glow in a magnified state. Interactions outside
of the viewport are delegated directly to the application without
interpretation. For example, a triple tap on the letter 'a' of the IME
would type three letters instead of toggling magnified state. The viewport
is updated on screen rotation and on window transitions. For example,
when the IME pops up the viewport shrinks.
4. The glow around the viewport is implemented as a special type of window
that does not take input focus, cannot be touched, is laid out in the
screen coordiates with width and height matching these of the screen.
When the magnified region changes the root view of the window draws the
hightlight but the size of the window does not change - unless a rotation
happens. All changes in the viewport size or showing or hiding it are
animated.
5. The viewport is encapsulated in a class that knows how to show,
hide, and resize the viewport - potentially animating that.
This class uses the new animation framework for animations.
6. The magnification is handled by a magnification controller that
keeps track of the current trnasformation to be applied to the screen
content and the desired such. If these two are not the same it is
responsibility of the magnification controller to reconcile them by
potentially animating the transition from one to the other.
7. A dipslay content observer wathces for winodw transitions, screen
rotations, and when a rectange on the screen has been reqeusted. This
class is responsible for handling interesting state changes such
as changing the viewport bounds on IME pop up or screen rotation,
panning the content to make a requested rectangle visible on the
screen, etc.
8. To implement viewport updates the window manger was updated with APIs
to watch for window transitions and when a rectangle has been requested
on the screen. These APIs are protected by a signature level permission.
Also a parcelable and poolable window info class has been added with
APIs for getting the window info given the window token. This enables
getting some useful information about a window. There APIs are also
signature protected.
bug:6795382
Change-Id: Iec93da8bf6376beebbd4f5167ab7723dc7d9bd00
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
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
Split the DisplayManager into two parts. One part is bound
to a Context and takes care of Display compatibility and
caching Display objects on behalf of the Context. The other
part is global and takes care of communicating with the
DisplayManagerService, handling callbacks, and caching
DisplayInfo objects on behalf of the process.
Implemented support for enumerating Displays and getting
callbacks when displays are added, removed or changed.
Elaborated the roles of DisplayManagerService, DisplayAdapter,
and DisplayDevice. We now support having multiple display
adapters registered, each of which can register multiple display
devices and configure them dynamically.
Added an OverlayDisplayAdapter which is used to simulate
secondary displays by means of overlay windows. Different
configurations of overlays can be selected using a new
setting in the Developer Settings panel. The overlays can
be repositioned and resized by the user for convenience.
At the moment, all displays are mirrors of display 0 and
no display transformations are applied. This will be improved
in future patches.
Refactored the way that the window manager creates its threads.
The OverlayDisplayAdapter needs to be able to use hardware
acceleration so it must share the same UI thread as the Keyguard
and window manager policy. We now handle this explicitly as
part of starting up the system server. This puts us in a
better position to consider how we might want to share (or not
share) Loopers among components.
Overlay displays are disabled when in safe mode or in only-core
mode to reduce the number of dependencies started in these modes.
Change-Id: Ic2a661d5448dde01b095ab150697cb6791d69bb5
We now notify the user of a captive portal before switching to the network as default.
This allows background applications to continue to work until the user confirms he
wants to sign in to the captive portal.
Also, moved out captive portal handling out of wifi as a seperate component.
Change-Id: I7c7507481967e33a1afad0b4961688bd192f0d31
The intent is used to launch camera when the device is secured
(e.g. with a pin, password, pattern, or face unlock).
bug:5955016
Change-Id: I5470cf7ee9deab9677665ef0566bac88bdfd80c6
The tokenOffsets is the offset from trimed contentLine.
But it is used in substring as the offset from un-trimed contentLine.
How to reproduce bug (ICS and before):
1. Add a contact record with name and a phone number (ex. 090-1111-2222)
2. Search by "0" in Contacts app
3. Contacts shows a wrong number something like "0900111102222"
Change-Id: I1e1cb2f3bd135d98e1573a50aa6ddc021af35b9f
bug: 6879638
- add new enum value BATTERY_PLUGGED_WIRELESS
- check for sys online file with contents "Wireless"
Change-Id: I22dc3c40f50573c98643e7b5cbcb237d0216530d
The major goal of this rewrite is to make it easier to implement
power management policies correctly. According, the new
implementation primarily uses state-based rather than event-based
triggers for applying changes to the current power state.
For example, when an application requests that the proximity
sensor be used to manage the screen state (by way of a wake lock),
the power manager makes note of the fact that the set of
wake locks changed. Then it executes a common update function
that recalculates the entire state, first looking at wake locks,
then considering user activity, and eventually determining whether
the screen should be turned on or off. At this point it may
make a request to a component called the DisplayPowerController
to asynchronously update the display's powe state. Likewise,
DisplayPowerController makes note of the updated power request
and schedules its own update function to figure out what needs
to be changed.
The big benefit of this approach is that it's easy to mutate
multiple properties of the power state simultaneously then
apply their joint effects together all at once. Transitions
between states are detected and resolved by the update in
a consistent manner.
The new power manager service has is implemented as a set of
loosely coupled components. For the most part, information
only flows one way through these components (by issuing a
request to that component) although some components support
sending a message back to indicate when the work has been
completed. For example, the DisplayPowerController posts
a callback runnable asynchronously to tell the PowerManagerService
when the display is ready. An important feature of this
approach is that each component neatly encapsulates its
state and maintains its own invariants. Moreover, we do
not need to worry about deadlocks or awkward mutual exclusion
semantics because most of the requests are asynchronous.
The benefits of this design are especially apparent in
the implementation of the screen on / off and brightness
control animations which are able to take advantage of
framework features like properties, ObjectAnimator
and Choreographer.
The screen on / off animation is now the responsibility
of the power manager (instead of surface flinger). This change
makes it much easier to ensure that the animation is properly
coordinated with other power state changes and eliminates
the cause of race conditions in the older implementation.
The because of the userActivity() function has been changed
so that it never wakes the device from sleep. This change
removes ambiguity around forcing or disabling user activity
for various purposes. To wake the device, use wakeUp().
To put it to sleep, use goToSleep(). Simple.
The power manager service interface and API has been significantly
simplified and consolidated. Also fixed some inconsistencies
related to how the minimum and maximum screen brightness setting
was presented in brightness control widgets and enforced behind
the scenes.
At present the following features are implemented:
- Wake locks.
- User activity.
- Wake up / go to sleep.
- Power state broadcasts.
- Battery stats and event log notifications.
- Dreams.
- Proximity screen off.
- Animated screen on / off transitions.
- Auto-dimming.
- Auto-brightness control for the screen backlight with
different timeouts for ramping up versus ramping down.
- Auto-on when plugged or unplugged.
- Stay on when plugged.
- Device administration maximum user activity timeout.
- Application controlled brightness via window manager.
The following features are not yet implemented:
- Reduced user activity timeout for the key guard.
- Reduced user activity timeout for the phone application.
- Coordinating screen on barriers with the window manager.
- Preventing auto-rotation during power state changes.
- Auto-brightness adjustment setting (feature was disabled
in previous version of the power manager service pending
an improved UI design so leaving it out for now).
- Interpolated brightness control (a proposed new scheme
for more compactly specifying auto-brightness levels
in config.xml).
- Button / keyboard backlight control.
- Change window manager to associated WorkSource with
KEEP_SCREEN_ON_FLAG wake lock instead of talking
directly to the battery stats service.
- Optionally support animating screen brightness when
turning on/off instead of playing electron beam animation
(config_animateScreenLights).
Change-Id: I1d7a52e98f0449f76d70bf421f6a7f245957d1d7
Preloaded drawables now have a density associated with them, so we
can load the correct drawable if we are using a different density.
Window manager now formally keeps track of the density for each
screen, allowing it to be overridden like you can already do with
size, and relies on this density to drive itself internally and
the configurations it reports.
There are a new set of Bitmap constructors where you provide a
DisplayMetrics so they can be constructed with the correct density.
(This will be for when you can have different windows in the same
app running at different densities.)
ActivityThread now watches for density changes, and pushes them
to the DENSITY_DEVICE and Bitmap global density values for that
process.
A new am command allows you to change the density.
