If flag for error after attach is not reinitialized, it may cause
NullPointerException on subsequent onAttachedWindow if error text
was reset to null.
Change-Id: I8976c28a6ca71017e5c4b3f29d4eeeb2eda48c38
For managing the ui mode, consider the device to be a television if it
has either the FEATURE_TELEVISION or FEATURE_LEANBACK system features.
When leanback is available for non-television devices, we need to
reconsider the use of these features for setting the television ui mode.
Change-Id: I7b82372ce19067e010be9b42111816bab186f95b
Due to an internal rounding in the renderer, the calculations
for the cropping area could be slightly offset, getting out
of the image boundaries. I sanitized the rect by ensuring they
are inside the image.
Bug: 12174629
Change-Id: Icc37790732ddd479631b898b23c05501d2dcd5be
Cherrypick of I0f8d33b0c77129f72581bc43e7f4fdc25469b520
This CL allows the Framework class InputMethodManager to behave
in a more deterministic way, that is to say, with an I/O barrier.
InputMethodManager#setAdditionalInputMethodSubtypes is internally
implemented as a RPC to the corresponding counterpart in
InputMethodManagerService. The problem here is that this RPC is
marked as "oneway". As a consequence, this public API call
returns immediately without waiting the additional subtypes are
actually added. This behavior is also not documented so far
unfortunately.
See the following demo code:
Final InputMethodManager imm = ...;
imm.setAdditionalInputMethodSubtypes(id, subTypes);
Final List<InputMethodInfo> ims = imm.getInputMethodList();
Currently, it is not guaranteed that the InputMethodInfo returned
from #getInputMethodList reflects the result of the previous call
of #setAdditionalInputMethodSubtypes because of its undocumented
asynchronous nature.
With this CL, InputMethodManager#setAdditionalInputMethodSubtypes
behaves as if it has I/O barrier. This change should make it easy
for IME developers to use additional subtype mechanism.
BUG: 13033954
BUG: 13291370
Change-Id: I0455b176bfb3176c533ba3241881f05092b98abc
Due to race conditions or programming errors, the NsdManager
can attempt to process an asynchronous status message (and issue
a callback to the listener) after the listener has already been
removed from the NsdManager state. This causes dereferencing of
null objects, and a crash.
Split out the three async-queue message cases: these are ones
in which message.arg2 does not hold an NsdManager array index
and the code should not interpret this field as if it were.
Add an explicit check for "null listener" (the array index in the
message has already been released), log a warning, and exit early.
Safeguard accesses to the "NSD service type" string from a possibly
null) NsdServiceInfo object... return a constant "?" string rather
than crashing.
Bug: 9016259
Manual cherrypick of commit b1fbb14122a99c62363a949dd634294f5e887ef,
change-ID I7a6ff6842cf035cefbafe2a023ae1fd43734081e in master.
Change-Id: I8d9b7a1763d47d061a0f46b3cb453de4bdb8c2ed
android.software.leanback - the device supports leanback UIs.
android.software.leanback_only - the device ONLY supports leanback UIs.
leanback_only is a hidden feature for now.
Change-Id: I497bd96464125ad81212c804e150f210f3e95af2
-Updated default code in activities from ADT
-Updated screenshots for ADT wizards when changed
-Updated activity_ with fragment_ where required
-Other minor changes
Stage: http://quixote.mtv:8004/training/basics/firstapp/creating-project.html
Patch: Removed border from the new ADT screenshots.
Patch: Replaced device screenshots using an Android 4.4 device.
Patch: Addressed Katie's comments.
Change-Id: Ic0acf714b1b5913f1f82d6eafac53666a721dfe4
