SuggestionSpans do not make sense anymore when the text they
refer to is modified. Removed these at the lowest possible common
level: In the SpannableStringBuilder that is used to back the Editable.
This way, IME do not have to care about removing these when they change
text. And they cannot forget to so either.
Also fixed a bug in TextView's paste with multi-item paste text (never
exercised, since we have no source for such a thing).
Change-Id: I08ed921f8c04ffb1a00936a3e554a85ee82f103c
Apply (or extend) the theme Theme.Holo.SplitActionBarWhenNarrow or
Theme.Holo.Light.SplitActionBarWhenNarrow to enable splitting the
action bar across both the top and bottom of the screen. This places
the action menu along the bottom, leaving more room at the top for
titles, navigation, and custom views and more room at the bottom for
menu items.
TODO: Refine layout of the action menu when placed at the bottom of
the screen. Make action modes split as well.
Change-Id: I92c91f99c533f26aecf6b828ed041386c4f16922
Bug #4343984
TextureView can be used to render media content (video, OpenGL,
RenderScript) inside a View.
The key difference with SurfaceView is that TextureView does
not create a new Surface. This gives the ability to seamlessly
transform, animate, fade, etc. a TextureView, which was hard
if not impossible to do with a SurfaceView.
A TextureView also interacts perfectly with ScrollView,
ListView, etc. It allows application to embed media content
in a much more flexible way than before.
For instance, to render the camera preview at 50% opacity,
all you need to do is the following:
mTextureView.setAlpha(0.5f);
Camera c = Camera.open();
c.setPreviewTexture(mTextureView.getSurfaceTexture());
c.startPreview();
TextureView uses a SurfaceTexture to get the job done. More
APIs are required to make it easy to create OpenGL contexts
for a TextureView. It can currently be done with a bit of
JNI code.
Change-Id: Iaa7953097ab5beb8437bcbbfa03b2df5b7f80cd7
Wrote initial suite of tests for ThrottleService, checking a variety
of edge cases. Checks going over limits, updating policies, and reset
after cycle elapses.
Moved NTP code in ThrottleService into new TrustedTime interface,
which makes it easier to understand, and allows tests to provide custom
clocks.
Change-Id: I0d62b8b3a169516a2ab2d33025f6fe30dc792be8
When the version is reported as a codename, use the previous version
in the user agent string.
Bug: 4347787
Change-Id: Ie42a2fc2f21975b59ccac5547d813d3e777da468
Currently the counterpart to FrameLayout.setMeasureAllChildren() is
FameLayout.getConsiderGoneChildrenWhenMeasuring(). This change
deprecates FameLayout.getConsiderGoneChildrenWhenMeasuring() in favor of
a new FrameLayout.getMeasureAllChildren() method.
Change-Id: Id26ec8b3966bd1553d5fd708ad76049069fcaeef
The result from getKeyDispatcherState() was used without
checking if it returned null, which resulted in a NullPointerException.
Change-Id: I4b55ad44d5c08b7f729dbbdbcaed0e978a430258
Implemented the merging of the different spans, highlighting words that actually differ.
Some TODO left in the code.
Change-Id: Iaf01f36b07d01639a4009cced6ea9b055ce9cc1f
In Honeycomb we introduced navigation controls in the status
bar, for xlarge devices without physical buttons. What about
phones? The status bar is pretty cramped already, and
besides, it's at the top of the display most of the time,
not at the bottom where your thumb is likely to be.
Enter the navigation bar. It's a new window type that
appears atop almost everything (including the keyguard); the
window manager subtracts its rectangle from the default
visible rectangle of other windows (including the status bar
and notification shade).
However, it behaves (on phones) like the status bar in that
applications that request fullscreen windows can get access
to those pixels. Well, almost; they need cooperation from
the navigation bar implementation to make the navbar
disappear, just like the status bar.
The current SystemUI implementation of the navigation bar on
phones is still rough, but it has the basics:
+ back, home, and menu keys (NB: we're showing menu all the
time right now because checking the api level of the
package owning the top window is currently a poor
indicator of whether the app requires the menu key)
+ it tries to stick to the same physical end of the device,
regardless of device orientation (on a phone, this is
the strip of land closest to the microphone)
Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
