Some products manipulate only the master volume, and the existing
code does not play volume-change tones when the master volume
is adjusted. This CL includes some config-driven behavior that
will play those tones (via the system stream) if desired.
Bug 6498986
Change-Id: I2415773325d0a0039efc67897bc371b1f2e18063
If the destroyNative JNI method is called twice, it will attempt to free
the socketData twice, and the second free will cause an assertion failure.
To avoid this, check whether mSocketState has already been set to CLOSED
while holding the write lock. If it has, then destroyNative has already
been called and should not be called again.
Bug: 3096033
Change-Id: Ic7c0bbf21823d389b26919da8c533d8ac4d49064
Activity.setImmersive(boolean) / android:immersive="bool" are now public.
In addition, if the foreground activity is immersive then an update lock
will be held on its behalf. This lets applications such as movie players
suppress the display of intrusive notifications, OTA-availability dialogs,
and the like while they are displaying content that ought not to be
rudely interrupted.
The update lock aspect of this mode is *advisory*, not binding -- the
update mechanism is not actually constrained; it simply uses this information
in deciding whether/when to prompt the user. It's more a guideline than
a rule.
Bug 6154438
Change-Id: Ibd3491fc437077f3fa0d9708ed91955121e8c877
For devices that don't care about the previously default bluetooth profiles,
add a config var to disable them.
Change-Id: I21a894130d280016cfd5db1b8bbda70cbef348c3
Watches for package changes so it can dynamically adjust
to reflect the actual list of available activities.
Change-Id: I3a2fef3dac4d13d1b2a7ed6fc117a7b814679669
An "UpdateLock" works similarly to a wake lock in API: the caller is
providing a hint to the OS that now is not a good time to interrupt
the user/device in order to do intrusive work like applying OTAs.
This is particularly important for headless or kiosk-like products
where ordinarily the update process will be automatically scheduled
and proceed without user or administrator intervention.
UpdateLocks require that the caller hold the new signatureOrSystem
permission android.permission.UPDATE_LOCK. acquire() and release()
will throw security exceptions if this is not the case.
The "is now convenient?" state is expressed to interested parties
by way of a sticky broadcast sent only to registered listeners. The
broadcast is protected; only the system can send it, so listeners
can trust it to be accurate. The broadcast intent also includes a
timestamp (System.currentTimeMillis()) to help inform listeners that
wish to implement scheduling policies based on when the device became
idle.
The API change here is a tiny one: a dump(PrintWriter) method has been
added to the TokenWatcher class to facilitate getting information out
of it for dumpsys purposes. UpdateLock itself is still @hide.
Bug 5543442
Change-Id: Ic1548dd43935f45d4efc67f970abdc290a45f715
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
Remove the right-to-left cascade effect from action mode menu
items. Animation time is now fixed at 300ms for scaling in menu items.
Change-Id: I8eef2ed9f93c2af804663dd5e6b3f4915ed45cb1
This adjust various paths through InputMethodManager so that the flow
in switching focus from one application to another is cleaner, resulting
in less work being done, resulting in it being able to happen quicker.
Some of the changes here avoid doing stuff when not needed, such as when
we are told to unbind but are not currently the active input. A big part
is also a change to the flow when a window receives input. Previously
this would first do a checkFocus() which would tell the input method to
switch focus to whatever view has focus in the window, followed by the
windowGainedFocus() call telling it the window had gained focus. This
would result in extra work because the input method service would first
handle the focus switch, seeing the IME is currently displayed, so the IME
would remain up and reset its focus to the new view. The app would
immediately then tell it about the window, causing the service to find out
the IME should be hidden and telling the IME, but the IME couldn't hide
itself until it had first take care of switching its input.
There is the definite potential of this breaking IME showing/hiding in
cases depending on the order things may be relying on them to happen. I
haven't seen any problems with a brief trip through the UI.
Change-Id: I8494cbd6e19e2ab6db03f2463d9906680dda058b
