This change passes the originating URL and accompanied referrer to
package verifiers, when available.
Bug: 6544677
Change-Id: I9ebc71bc13f549bd88267e444816151a99bda000
This introduces a public API for the Android keystore that is accessible
via java.security.KeyStore API. This allows programs to store
PrivateKeyEntry and TrustedCertificateEntry items visible only to
themselves.
Future work should include:
* Implement KeyStore.CallbackHandlerProtection parameter to allow the
caller to request that the keystore daemon unlock itself via the
system password input dialog.
* Implement SecretKeyEntry once that support is in keystore daemon
Change-Id: I382ffdf742d3f9f7647c5f5a429244a340b6bb0a
Split WindowManagerImpl into two parts, the WindowManager
interface implementation remains where it is but the global
communications with the window manager are now handled by
the WindowManagerGlobal class. This change greatly simplifies
the challenge of having separate WindowManager instances
for each Context.
Removed WindowManagerImpl.getDefault(). This represents the
bulk of this change. Most of the usages of this method were
either to perform global functions (now handled by WindowManagerGlobal)
or to obtain the default display (now handled by DisplayManager).
Explicitly associate each new window with a display and make
the Display object available to the View hierarchy.
Add stubs for some new display manager API features.
Start to split apart the concepts of display id and layer stack.
since they operate at different layers of abstraction.
While it's true that each logical display uniquely corresponds to a
surface flinger layer stack, it is not necessarily the case that
they must use the same ids. Added Display.getLayerStack()
and started using it in places where it was relatively easy to do.
Change-Id: I29ed909114dec86807c4d3a5059c3fa0358bea61
Reverting to the previous stub as the display adapter registration
and the logical to physical mapping is not at all what we are going
to need moving forward.
Fixed up the service initialization order so that the display manager
service has a context from the start.
Change-Id: I717f2f1099c7a77180ef207c371ec8329258850a
Add a View.toString() method.
Rename all of the View private flags to have a PFLAG prefix to
avoid going insane trying to figure out which constant goes with
which flag.
Activity.dump() now includes a summary of the activity's view
hierarchy, using the View.toString() method.
All exceptions thrown by FragmentManager now perform a dump of
the owning activity state, where appropriate.
Change-Id: I6482e397e10cb5a0612ab02ce6ed5131823437a6
So each user can have their own set of intent resolution preferences.
ResolverActivity now launches the activity on the correct user, and
persists the preference for the correct user.
Bug: 6961905
Change-Id: I6d3a8a9af89bc649277d4fc8d0f367ee123f8392
Remove the last user of FileUtils#getFileStatus and move it to
Libcore.os.stat instead. Then we can remove the JNI code that does the
equivalent of a stat.
Change-Id: Ieb566a2a8a17c2dd0150724b4eb3ac1cc41c823d
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
This allows you to, say, make a Context whose configuration
is set to a different density than the actual density of the device.
The main API is Context.createConfigurationContext(). There is
also a new API on ContextThemeWrapper that allows you to apply
an override context before its resources are retrieved, which
addresses some feature requests from developers to be able to
customize the context their app is running in.
Change-Id: I88364986660088521e24b567e2fda22fb7042819
Lockscreen and statusbar now launch the intent on the current user.
Make sure that the intent resolution is made to the package manager
for the specific user, as the app could have been disabled for that
user or may have an alternative app installed.
Change-Id: I93b0f972d6c7e8880b146da83dc3d08a68fe7e51
Moved a bunch of methods from PackageManager to UserManager.
Fix launching of activities from recents to correct user.
Guest creation APIs
Change-Id: I0733405e6eb2829675665e225c759d6baa2b708f
Added a new method to Context: startActivityAsUser() requiring the
INTERACT_ACROSS_USERS_FULL permission.
Show the correct Recents list, based on current user.
Added a getRecentTasksForUser() in ActivityManager. Hidden and requires
the INTERACT_ACROSS_USERS_FULL permission.
Change-Id: If5b56465efdd3ead36601a3b51ed4af157bbf35c
- You can now use android:singleUser with receivers and providers.
- New API to send ordered broadcasts as a user.
- New Process.myUserHandle() API.
For now I am trying out "user handle" as the name for the numbers
representing users.
Change-Id: I754c713ab172494bb4251bc7a37a17324a2e235e
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.
- Expose the existing Context.sendBroadcast() as
Context.sendBroadcastAsUser().
- Add new android:singleUser attribute for services.
- Add new INTERACT_ACROSS_USERS_FULL permission for full
system-level access to cross-user interface (allows
sendBroadcastAsUser() to send to any receiver).
- Add new INTERACT_ACROSS_USERS_FULL permission for
more restricted cross-user interaction: this is required
for android:singleUser, and allows you to use
sendBroadcastAsUser() but only to send to your own
receivers.
Change-Id: I0de88f6718e9505f4de72e3f45d29c0f503b76e9
This change passes the originating URL and accompanied referrer to
package verifiers, when available.
Bug: 6544677
Change-Id: If9ff6663ad7f3426b7aea2aceb1413b689788138
Bug 6921236
Add a default contentDescription for MediaRouteButton.
Add long-press "cheat sheet" support to MediaRouteButtons created by
MediaRouteActionProvider for use in the action bar to match standard
action button behavior.
Change-Id: I313cfcb2349210765b084c3388095de4624009e8
