When Intent.FLAG_ACTIVITY_REORDER_TO_FRONT was set the TaskRecord
member frontOfTask was being set true incorrectly for the top
activity. It should only be true for the bottom activity. This fix
ensures that frontOfTask is always set correctly for all activities by
consoldating it into one method.
Fixes bug 12171535.
Change-Id: If982dad3c81b2b816adc5d89e7e0496923098a70
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
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
-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
