BitmapFactory::Options now let you specify if the resulting bitmap can be
"purgeable". If so, then its decoded pixels may be purged when not actively
being drawn, freeing up that RAM. When such a bitmap is drawn, it will
automatically be re-decoded on demand. This is done by having the bitmap
keep a reference/copy of the encoded data.
Where it is a reference or a copy is controlled by the "shareable" flag in
Options. If this is true, the implementation *may* just reference the encode
data (e.g. a file descriptor) rathern than making a complete copy of it.
Currently, purgeable is not supported for generic inputstreams, but is
enabled for byte-array, file-descriptor, and assets, though for impl
reasons only file-descripts are currently enabled for "shareable", but that
may change in the future.
This is just plumbing. The Java APIs existed already, but there were no C APIs to hook the Java APIs
up to. Now there are C APIs, so we can call them.
Of course, whether or not the C APIs actually work when you call them depend upon the
capabilities of the active OpenGL driver, which must be checked at run time.
Also, while we're here, make the glGetString method static. It was always supposed to be static,
but was accidentally implemented as non-static, because the code was copied from the non-static
OpenGL ES classes.
CL 147456 introduced support for HTML formatted search suggestions.
This is triggered by the value "html" in the SUGGEST_COLUMN_FORMAT
column. However, the code failed to check that the
SUGGEST_COLUMN_FORMAT column was present before trying to read it.
This resulted in an IllegalStateException being thrown when searching
with a suggestion provider that does not include the SUGGEST_COLUMN_FORMAT
column. This broke search at least in the Contacts and Music apps.
Automated import of CL 147681
- all public apis and framework changes have been reviewed by relevant folks in our branch (e.g romainguy)
- all new public apis are @hidden; they will still get reviewed by api council once we're in git
- other than that, it's mostly GlobalSearch and search dialog stuff, a new apps provider, and some tweaks
to the contacts provider that was reviewed by jham
Automated import of CL 147564
There are three major classes of changes here:
- Avoid writing lines where their values are often empty, false, or some other typical thing.
- Use partial writes to the PrintWriter to avoid creating temporary strings.
- Use StringBuilder where we need to generate real String objects (and where possible cache the result).
were already listed in attrs.xml into SearchManager.java. Add
a (brief - no time for more) description about how to add search
by voice to apps.
JAVADOC ONLY - should be safe change for cupcake sdk.
Original author: stadler
Merged from: //branches/cupcake/...
Automated import of CL 147168
InstrumentationTestCase and its descendants should be the
package manager package name (not the java package name, and
not the test package) of the package holding the Activity
under test.
Added similar notations to the ApiDemos call sites.
JAVADOC ONLY - should be safe change for cupcake sdk.
Original author: stadler
Merged from: //branches/cupcake/...
Automated import of CL 147167
were already listed in attrs.xml into SearchManager.java. Add
a (brief - no time for more) description about how to add search
by voice to apps.
JAVADOC ONLY - should be safe change for cupcake sdk.
BUG=1554704
Automated import of CL 147163
InstrumentationTestCase and its descendants should be the
package manager package name (not the java package name, and
not the test package) of the package holding the Activity
under test.
Added similar notations to the ApiDemos call sites.
JAVADOC ONLY - should be safe change for cupcake sdk.
BUG=1783981
Automated import of CL 147162
We use a single outstanding message of type SHOW_PROGRESS to refresh the progress
bar's current position as well as textual display of time and duration. This message
could get lost if the scroll ball was used to adjust the current playback position as
we entered state "mDragging" which would cause the subsequent SHOW_PROGRESS message
to be a no-op and would also cause it to not be re-enqueued.
The change refactors the seekbar logic a little and makes sure that while dragging
there isn't a pending SHOW_PROGRESS message in the queue and once dragging is over,
exactly one SHOW_PROGRESS message is reenqueued.
related to bug 1721227
This change adds four new public classes that expose a static OpenGL ES 1.1 API:
android.opengl.GLES10
android.opengl.GLES10Ext
android.opengl.GLES11
android.opengl.GLES11Ext
Benefits:
+ The static API is slightly faster (1% to 4%) than the existing Interface based JSR239 API.
+ The static API is similar to the C API, which should make it easier to import C-based
example code.
+ The static API provides a clear path for adding new OpenGL ES 1.1 extensions
and OpenGL ES 2.0 APIs, neither of which currently have a JSR standard.
Example:
import static android.opengl.GLES10.*;
...
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Note that it is possible to mix-and-match calls to both the static and JSR239 APIs.
This works because neither API maintains state. They both call through to the same underlying
C OpenGL ES APIs.
Implementation details:
This change enhances the "glgen" "gen" script to generate both the original JSR239 and
new static OpenGL ES APIs. The contents of the generated JSR239 classes remained the same as before,
so there is no need to check in new versions of the generated JSR239 classes.
As part of this work the gen script was updated to be somewhat more robust, and to
work with git instead of perforce. The script prints out commands to git add the generated files,
but leaves it up to the script runner to actually execute those commands.
