bug:3360821
1. While my previous change:I3baff68c has partially fixed this bug
it was still possible for a callback to be invoked on init. If a
callback was already regitsered and the init is called the
callback is incorrectly notified.
Change-Id: I05c6cb78f4c7b7d2a00c52aef42c1698d9479be5
The problem is that SoundPool never calls the onLoadComplete() callback
when load() method fails because the file cannot be opened.
AudioService loadSoundEffects() was blocked waiting for a callback
that never came.
In this particular case, this happened on a specific build where sound
effects assets were not included.
The fix consists in waiting for the callback only if at least one sample is
accepted by SoundPool load().
Also moved the initial loading of sound effect samples from the boot completed
broadcast receiver to the audio service message handler to avoid waiting in the
main system server thread.
Change-Id: I902e5988f8b644a81d8e585c52eed1df4ca0ec05
ContentProviders are allowed to return null and both
of our contact directories (Focus and Exchange) actually
do when they find no data to return.
The problem is that when LoaderManager receives a result
from a loader, it checks if the result is the same as
previously received. That's fine, as long as the loader
always returns a different result. Now consider a loader
that returns null when it cannot produce the result.
What we are seeing is that if the loader is rapidly restared
and returns null twice in a row, the null is never
delivered to the callbacks.
In the case of the reported bug, the scenario is this:
1. We look for "foo"
2. Data for "foo" comes from a directory and we display it
3. We hit backspace twice in rapid succession. Each time
we hit backspace, the loader is restared, but since we do
this very fast, the second restart overrides the first. So
far so good.
4. The directories are programmed to return null if the
query string is less than 3 characters long, so the loader
returns null twice.
5. Loader manager looks at the final result, compares it
to the previous result and since they are the same (both null)
concludes that it does not need to deliver either of them.
6. The UI attempts to show the stale data and blows up
Bug: 3352125
Change-Id: I3e5bc505faa03f72ebe5cb010377a740f5c7d5b6
The width of the dropdown was only taking into account
the width of the items and not background padding.
Change-Id: If27291c96191d4ac1f3e9200c6f6f585a19008c3
This enables the system bar to carve out a region through which
events will be sent to the IME behind it.
Bug: 3238092
Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
Also hide the bitmap thumbnail stuff, we can't support it in its
current form.
And fix some bugs with propagating paths to native code. Yikes!
Change-Id: I13ab37ddbdba5c073489cba5eab035117d3c1574
Return wrappers from GetProcAddress for glEGLImageTargetTexture2DOES
and glEGLImageTargetRenderbufferStorageOES which unwrap the EGLimage
handle before calling through to the implementation.
Change-Id: I2f5b180ab3ccdb28a4f510a2bd8c2eee941a84df
Add EGL_KHR_gl_texture_cubemap_image and EGL_KHR_gl_renderbuffer_image
to the static EGL extension string since these require no new APIs
beyond what is already required.
Change-Id: I2d1fde86b19bb9eee46b3b977f51784a17cfcc3c
LockScreen wasn't correctly updating StatusView when the battery
status changed. In addition, the messages aren't supposed to
"pop" when changed, so changed visibility state from GONE to INVISIBLE
when not in use.
Change-Id: Icacbf7e2275c77a28e7e0a9d1247abdbebadcd4f
This change implements the onFrameAvailable callback for the
SurfaceTexture java class. It includes the C++ SurfaceTexture code as
well as the JNI and Java code to enable the callback.
Change-Id: Ifd8b8e7ad46ee70cba6da1c2e96dab8045d1ea30
action items are added
Rules for action bar overflow:
Items are considered for inclusion in the order specified within the
menu. There is a limit of a total count, optionally including the
overflow menu button itself. This is a soft limit; if an item shares a
group ID with an item previously included as an action item, the new
item will stay with its group and become an action item itself even if
it breaks the max item count limit. This is done to limit the
conceptual complexity of the items presented within an action
bar. Only a few unrelated concepts should be presented to the user in
this space, and groups are treated as a single concept.
There is also a hard limit of consumed measurable space. This limit
may be broken by a single item that exceeds the remaining space, but
no further items may be added. If an item that is part of a group
cannot fit within the remaining measured width, the entire group will
be demoted to overflow. This is done to ensure room for navigation and
other affordances in the action bar as well as reduce general UI
clutter.
The space freed by demoting a full group cannot be consumed by future
menu items. Once items begin to overflow, all future items become
overflow items as well. This is to avoid inadvertent reordering that
may break the app's intended design.
Change-Id: I878f6b15619059258c91c01f4fe838feac161d6d
Bug: 3184831
Copied holo layouts to *_holo.xml and restored the old layouts for
non-holo (pre-honeycomb) apps to use so that their layout assumptions
aren't messed up.
Change-Id: If4dcef16191a47a4b101da6bfb0c2df1757d1ae4
