Watches for package changes so it can dynamically adjust
to reflect the actual list of available activities.
Change-Id: I3a2fef3dac4d13d1b2a7ed6fc117a7b814679669
...if the process is killed and restarted
Try to ensure that in all cases we deliver an activity result if one
was requested.
Change-Id: Id43e830d2ee782f98ed1e3b68e5e16f3258d4ad8
1. The NumberPicker was showing the IME if the input field
gets focus and hiding it when the the arrows are pressed.
The leads to a nasty behavior when the input is the first
focusable and the uses presser an arrow button. In such
a case the IME shows and hides on every arrow press pushing
the window content up and down - this looks pretty ugly.
Now the IME is show on double tap of the input field.
2. The NumberPicker input now by default has an IME action
done, hence after editing it the IME goes away.
3. The NumberPicker input now clears focus when it gets
IME action done, so the last picker in a sequence
does not show selection which is focus driven.
4. NumberPicker was incorrectly detecting double tap to
begin edit and it was possble to start edit on singe tap
if the user has double tapped before to start an edit.
Now double tap detection is using the double tap timeout
correctly.
bug:6071977
Change-Id: I0ff5a491064e51663b3abec675d839d0a65b986a
My previous change to speed up the time the IME is dismissed was
fundamentally flawed. That change basically switched the order
the application called the input method manager service from doing
startInput() and then windowGainedFocus(), to first windowGainedFocus()
and then startInput().
The problem is that the service relies on startInput() being done
first, since this is the mechanism to set up the new input focus,
and windowGainedFocus() is just updating the IME visibility state
after that is done. However, by doing the startInput() first, that
means in the case where we are going to hide the IME we must first
wait for the IME to re-initialize editing on whatever input has
focus in the new window.
To address this, the change here tries to find a half-way point
between the two. We now do startInput() after windowGainedFocus()
only when this will result in the window being hidden.
It is not as easy as that, though, because these are calls on to
the system service from the application. So being able to do that
meant a fair amount of re-arranging of this part of the protocol
with the service. Now windowGainedFocus() is called with all of
the information also needed for startInput(), and takes care of
performing both operations. The client-side code is correspondingly
rearranged so that the guts of it where startInput() is called can
instead call the windowGainedFocus() entry if appropriate.
So... in theory this is safer than the previous change, since it
should not be impacting the behavior as much. In practice, however,
we are touching and re-arranging a lot more code, and "should" is
not a promise.
Change-Id: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Added support for predefined namespace http://schemas.android.com/apk/res/auto
that aapt tool recognizes and treats as namespace with package name
taken from current application's AndroidManifest.xml, //manifest/package attribute.
Signed-off-by: inazaruk <ievgenii.nazaruk@gmail.com>
(cherry picked from commit e348909c1966c3d192841cc131a32be6ed90da18)
Change-Id: I4bff836c42a309bac36e5d1ce1899131b3c4c194
