Bug #2553187
Limit the max number of lines for each entry in the ResolveActivity to 2. Also
make sure to discard potential styling tags and newlines/space characters from
package name and activity labels.
Change-Id: Ibda3688267aa948b921164d3d3abc8c9236e61a2
glEGLImageTargetRenderbufferOES() pass the wrapped EGLImage
to the implementation, rather than the unwrapped one.
Change-Id: I149f9ed73e6ab9089110600e1db4311ba7a8c83a
I also realized the ROTATION_NN constants were misdocumented, they
actually align the opposite direction from the "orientation" angle
computed in the code (i.e. orientation=90 is left side up, ROTATION_90
is right side up). I just changed the comment here to keep the change
minimal; I'll update the code to be more consistent outside of this
release branch.
Bug: 2549875
Change-Id: I79c4286be582a21e730b25a8a24f2e1137c6e4cb
Vector::sort() is using _do_copy() incorrectly; _do_copy() calls the
copy constructor, not the assignment operator, so we need to destroy
the "destination" before copying the item.
Change-Id: Iaeeac808fa5341a7d219edeba4aa63d44f31473c
Killing the WifiWatchdogService thread from
WifiService can cause messages to be handled on
a dead thread. Quit the thread on the broadcast
instead.
A couple of more fixes:
- Do an asynchronous bring up of Wifi. This will
allow WifiWatchdogServiceThread to be immediately
brought up, instead of relying on an update.
- There is no need to listen on supplicant connection
in wifiwatchdog anymore. We kill the thread when
supplicant connection is no more.
Bug: 2546756
Change-Id: I15a188e031bc79856c55aabdd271287b0df0377d
This change introduces the NotificationPlayer class which was
created from the code of android.media.AsyncPlayer. The only modification
was to modify the construction of the MediaPlayer so it properly issues
onCompletion notifications (which are used to abandon audio focus).
Unless the sound to be played is looped, the notification is transient
and other apps may duck (uses AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK in
audio focus request).
Change-Id: I69cbb71d0892447b934351384e4e24a2e239295b
Use the content width to calculate the zoom overview
width. We used to use the minimum preferred width
to calculate the overview width as it is what we
use to define the viewport width. But some sites,
like cbsnews, engadget, the content width will be
slightly wider than the viewport width decided by
the min preferred width. The result is we can still
scroll a little bit in the overview mode. This issue
is magnified when we introduce the overscroll feature.
By using content width as zoom overview width, we
will have content fit in the overview mode. But
some sites, like
"http://www.sfjazz.org/concerts/2010/spring/artists/towner.php"
will be layout wider in the overview mode than it
is in the zoom in state. This is a tradeoff.
Fix http://b/issue?id=2551119
When receiving a message to delete the root layer, delay it until the next
new picture message, so that the layers only disappear when we start displaying
the new page, and not the moment the DOM on the old page is destroyed.
