- Added a new custom PNG chunk that carries the layout padding ints.
- Extract the padding ticks from .9.png images and store in the chunk.
- Load the padding information at runtime into Bitmap and NinePatchDrawable.
- The new chunk is ordered first so that it doesn't cause a problem in older
versions of the platform.
Bug: 6087201
Change-Id: I5de46167a1d44b3ec21065b0c165e594b1dc8399
Improved how the various callbacks are managed and sequenced
to reduce code duplication.
Added a heuristic to avoid postponing traversals until
the next vsync frame if we did not actually do any drawing during
the previous frame. This helps in the very common case where
drawing occurs in response to input.
Change-Id: I277d9eeaf50408f8745a3cfd181db1d140770658
A careful reading of the EGL spec, as well as experience with many
different EGL drivers, has shown that it is error prone to attempt to
discriminate between different error conditions.
We now treat any error besides EGL_CONTEXT_LOST as an indication that the
EGL context is in a bad state, most likely due to the window manager
having removed the underlying surface flinger surface.
In addition, we changed the way we deal with this kind of error:
Previously we would ignore the error and keep rendering. But if the
EGL context and surface has become invalid, it would be better to
stop drawing. We now stop drawing until the surface view surface is
recreated.
See b/6032663 for an example of this problem affecting the GMM app,
but note that GMM is using their own version of GLSurfaceView, so this
change won't help them directly. They'll have to make a similar change
to their version of GLSurfaceView.
Change-Id: Iffe3e1e3a3c7a91d03140fd34391eadeaecf777e
Signed-off-by: Jack Palevich <jackpal@google.com>
Migrated the bulk of Surface operations from WindowState to
WindowStateAnimator. There remain a multitude of cross-referencing
between the two classes and most of the other classes in the wm
package.
Change-Id: I4bfdfb84be31341371f3ef311aca8fc6a4966692
More refactoring. This time wallpaper animations were broken up from
WindowManagerService and the layout piece kept there while the
animation piece was moved into WindwoAnimator.
Also, applyAnimationLocked and applyEnterAnimationLocked were moved
from WindowManagerService to WindowState.
Change-Id: I05935023702ce05fdfdc804342ec14f719cdfea4
The current NFC stack formats tags to the INITIALIZED state
as defined by NFC forum; in that state the tag has the
NDEF Capability Container, but does not contain any message
yet.
Tags in that state (correctly) return the NDEF technology,
but the documentation does not specify that the message
may be null.
Also, get rid of buggy getLastErrorCode and use
(cached) presence check value to determine if tag was
lost during read.
Change-Id: If4293428093024ba9cda5dd7c9979b8b06353234
Fragments don't work as desired if called after life-cycle events
such as onDestory() or onSaveInstanceState().
The new approach doesn't work after onDestroy() either, but we can more
easily detect this now. For pre-JB apps, we will log an error, and for
JB and onwards we will throw.
Update documentation to make these rules clear, and to encourage
the use of a single Activity per API call, and to make the call
in onCreate().
Bug: 5199662
Bug: 5994691
Bug: 6034901
Bug: 6125297
Change-Id: Ib0dde6abfa44cd56c7ddc13ba0ad0e83bbe30058
The new DisplayList properties design has ordering conflicts with the
way that alpha works with old animations (AlphaAnimation). This CL
disables DiksplayList properties while I'm working on a fix and some
more thorough tests for old animations-vs-DL properties in general.
Change-Id: I8f6893138f939171491c2ec3c889214ee55d17b7
Previously we created the PointerLocationView on whatever thread
happened to trigger the call to updateSettings(). There was
also some messiness around having to add or remove the view
while not holding mLock.
Now, just post the work to the policy handler.
This also makes it possible for us to use invalidate() instead
of postInvalidate() in PointerLocationView, which is more efficient.
Change-Id: I0646d7aeecffdc22f6ac56ae3ef951e7a12e2b93
Surgical hack for getting Settings to run multiple instances without
causing other system services/providers from doing the same.
Change-Id: Ic5dab61976a04c3012235299ba55edfcd8273dbb
Two parts to this:
1. Stop treating FLAG_ONGOING_EVENT notifications specially
(in particular, ordering them at the top of the panel).
2. Set the priority bits on the system UI notifications
appropriately (low).
Change-Id: I3bde7e573654c5aad5e1c5d29e6a21ba94edcc5b
There are now two "rebuilder" classes, each of which
consumes a Notification.Builder and modifies its behavior.
(Inheritance in Builder classes is...not advisable.)
- BigPictureStyle: includes a large Bitmap above the usual
notification strip.
- BigTextStyle: shows the contentText in a large, wrapping
TextView instead of truncating to one line.
As for SystemUI, the notification panel now shows the
expanded form if it is available, otherwise the usual
contentView is shown.
(Note that the structure of largeIcon notifications has
changed a bit: The largeIcon is no longer handled by the
status bar at all; it's entirely inside the template now.
Not only does this make the code simpler, and make large
notifications possible, but it fixes the longstanding
irritation that tapping on a largeIcon doesn't highlight the
whole notification row. Man, that feels good.)
Change-Id: I2b9d8a6ea4385659d8cb1ed467c1caf5e12628dd
Shows a little indicator next to the current user in the power menu
when multi-user is enabled.
Fixed a bug where Settings was sometimes being launched in the wrong
process when there are 2 instances running.
Change-Id: Iaf2a00f6d1871fd2a88d8982439e445423bb2896
This will allow apps to figure out if discovery is active or not
and based on that initiate a new discovery for fresh connections
Change-Id: I4778f135fdd88773e4f0d50c384f9b6ebf561e6d
GLES20Canvas defined several JNI functions used only by HardwareRenderer.
Now that we have a JNI layer dedicated to HardwareRenderer we should
host the renderer related methods there.
Change-Id: I0bcb4ad0bcc1c4a37290df10c1685f2cfe5504ca