The comment for the PHONE pattern says:
"<digit><digit|sdd>+<digit>"
But the actual pattern requires that the string contains
more than that. A phone number should be allowed to be
three digits.
Change-Id: I86d2f3d634cd0c1654dad9814906f151055dc23a
1. Removed the support for infinite pool size which nobody was using and
does not make sense.
2. Update some classes in ViewGroup to use the poolable APIs.
Change-Id: Ifdb8c10968cd06fe53085ec9d3d649f7c9a944b7
Before to implement a pool of objects, the pooled class had to implement an
interface which was leaking the pool management APIs. This requires
hiding APIs - inconvenient at best. Further, each client had to
implement the chaining of pooled instances which means adding a couple
of member variables which are manipulated by the implemented interface
methods. As a consequence the client is aware of how pooling is
implemented which is error prone and breaks encapsulation. Now the
pool objects are responsible for managing pooling state via reusable
wrapper objects and the clients are oblivious of how pooling is done.
Creating a thin cached wrapper for each pooled object has minimal
performance impact while making the code more maintainable. Actually
implementing of the old version of the APIs was taking as much code
as implementing the pooling yourself.
Also clients had to implement a poolable manager whose responsibility
was to create new instances and provide callbacks when an instance
is added to or removed from the pool. Now, the clinet class should
create a static member for the pool and expose obtain/aquire and
release/recycle methods in which it should create a new instance if
the pool did not return one and clear the state of the host when
it is returned to the pool. Updated the JavaDoc with a best practice.
The pooling was composed of several interfaces and classes scattered
over a few files, now all this is in a single small file.
Update all usages of the pooling APIs in the framework.
Also one had to write a poolable
manager which
Change-Id: Ib8dc286040eb3d7cb7d9668ba76fead05cb97647
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Note: Checked into AOSP. Cherry-picking for mr1.1.
Issue #7621806 IntProperty has infinite recursion bug
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
FindBugs description:
There is an apparent recursive loop at IntProperty.java
in method set(Object, Integer)
This method unconditionally invokes itself. This would seem
to indicate an infinite recursive loop that will result in a stack overflow.
Change-Id: I2f52dd3689198cb948925aa65dd9c95be7888fe7
This patch introduces the ability to create a Context that
is bound to a Display. The context gets its configuration and
metrics from that display and is able to provide a WindowManager
that is bound to the display.
To make it easier to use, we also add a new kind of Dialog
called a Presentation. Presentation takes care of setting
up the context as needed and watches for significant changes
in the display configuration. If the display is removed,
then the presentation simply dismisses itself.
Change-Id: Idc54b4ec84b1ff91505cfb78910cf8cd09696d7d
Strictly speaking, this is a change in behavior for all products.
Instead of using discrete zones, they will all now use spline
interpolation. We could make this behavior configurable
but there seems to be little point to it. The range of brightness
values used will be more or less the same as before, it's just
that what used to be the brightness value for all levels within
a particular zone now becomes the brightness value for the
highest level in that zone and lower values are used for lower
levels within the zone.
Change-Id: I39804ee630ba55f018e1e53c0576b28e7bd27931
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.
This puts in most of the infrastructure needed to allow us to
switch between different densities at run time. The main remaining
uses of the global are to initialize the Bitmap object (not sure
what to do about that since it doesn't have anything passed in
the constructor to get this information from), and being able to
load drawables if we need a different density than what was preloaded
by zygote.
Change-Id: Ifdbfd6b7a5c59e6aa22e63b95b78d96af3d96848
