The framework tries to have a focused view all the time. For
that purpose when a view's focus is cleared the focus is given
to the first focusable found from the top. The implementation
of this behavior was causing the following issues:
1. If the fist focusable View tries to clear its focus it
was getting focus but the onFocusChange callbacks were not
properly invoked. Specifically, the onFocusChange for
gaining focus was called first and then the same
callback for clearing focus. Note that the callback
for clearing focus is called when the View is already
focused. Also note that at the end the View did not
clear its focus, hence no focus change callbacks
should be invoked.
2. If not the first focusable View tries to clear focus,
the focus is given to another one but the callback
for getting focus was called before the one for clearing,
so client code may be mislead that there is more than
one focused view at a time.
3. (Nit) The implementaion of clearFocus and unFocus in ViewGroup
was calling the super implementaion when there is a
focused child. Since there could be only one focused View,
having a focused child means that the group is not focused
and the call to the super implementation is not needed.
4. Added unit tests that verify the correct behavior, i.e.
the focus of the first focused view cannot be cleared
which means that no focus change callbacks are invoked.
The callbacks should be called in expected order.
Now the view focus clear precedes the view focus gain
callback. However, in between is invoked the global
focus change callback with the correct values. We may
want to call that one after the View callbacks. If
needed we can revisit this.
Change-Id: Iee80baf5c75c82d3cda09679e4949483cad475f1
Added a new method ContentObserver.onChange(boolean, Uri) that
receives the changed content Uri. This can help applications make
better decisions about how to interpret a change notification.
Change-Id: I8e35378b6485fe22c5bc240ba07557d269af0836
- was a subtle regression introduced when fixing bug #5753006
- as we are now using SkPaint::kGlyphID_TextEncoding (glyph encoding)
instead of SkPaint::kUTF16_TextEncoding (UTF16 encoding), we need to
force the UTF16 encoding in some cases that are NOT going thru
the TextLayoutCache / Harfbuzz shaping
- fix also breakText() the same way
- also clean some old comment
- Warning: depends also on a CL from Skia for having getBaseGlyphCount() "const"
Change-Id: I3d1fc87f070884876c679b33541f810fbfb5df3f
Improved the documentation a little bit.
Fixed a bug in ContentService wherein if a ContentObserver was
passed as an argument and its deliverSelfNotifications() method
returned true, then notifyChange would tell all observers that
the change was a self-change even though it was only a self-change
from the perspective of the provided observer.
Deprecated ContentObservable.notifyChange since it is never
used and in general it shouldn't be because we want the notification
to be posted to the handler.
Change-Id: Idde49eb40777e011a068f2adae8a32f779dfb923
We now have an animation that can start as soon as we detect to
rotate the screen, and have a different phase once the new UI
is ready to complete the transition into it.
Change-Id: I05b9c12a699232acbddc36b4a994a4452db71476
In change Ief74d0e4f4f28dff7a435e9dab1fab1ca1d9bfaf with a sha1 of
e81932e92a773538e1ad1ad1d4bfd8f241860c8d it seemed like a good idea
to throw away all TLV's on errors. In retrospect that was probably
not a good idea. For example on the MTN Ghana SIM the error
occurs because of some 0 pad bytes at the end, all of the actual
TLV's are good, so throwing away everything is unreasonable. Instead
accepting what is valid seems a better approach.
Also, add a couple debug lines on error paths.
Change-Id: I4add0c9cd242f46e0ef8700229d0ec755b9e4c4c
The VM is allowed to use null to represent the bootstrap class
loader, so attempting to call methods on it is a bad idea. Use
the system class loader instead.
Change-Id: I9190848945f679d546d5fb30aba10fd27c7e5404
The special shared-storage step was mistakenly writing its data directly
to the USB output pipe rather than to the proper stacked data handling
chain that applies compression and encryption. Fix this by getting rid
of the custom handling of the shared-storage data, instead folding it
into the normal data handling flow [with a small amount of additional
management because e.g. it doesn't need a "manifest" pseudofile in the
archive stream].
Fixes bug 5897791
Change-Id: I3995b07963334d2f8cce49b247c87d3d3ff93bed
