- New TextToSpeechService methods are no longer protected.
- s/getRequiresNetworkConnection/isNetworkConnectionRequired
- New TextToSpeec#play.. methods use a Bundle instead of a HashMap
- New synthesizeToFile(), addSpeech(), addEarcon() methods
take a File instead of a String with filepath.
- TextToSpeechService#s/isValidVoiceName/onIsValidVoiceName
Bug:17389935,17253934
Change-Id: Iec76f59015c34104683c050fe1ff1ceccd604134
This is a follow up CL for Ia8cbb9f6b41cd9509fc0147fd68763dfde
and Ic8c6fab58c01206872a34e7ee604cdda1581364d.
BUG: 17365414
BUG: 17200900
Change-Id: Ib2371849d32bb44da9ef59f05e648a476e03699a
In touch exploration mode an accessibility service can move
accessibility focus in response to user gestures. In this case
when the user double-taps the system is sending down and up
events at the center of the acessibility focused view. This
works fine until the clicked view's center is covered by another
clickable view. In such a scenario the user thinks he is clicking
on one view but the click is handled by another. Terrible.
This change solves the problem of clicking on the wrong view
and also solves the problem of clicking on the wrong window.
The key idea is that when the system detects a double tap or
a double tap and hold it asks the accessibility focused node
(if such) to compute a point at which a click can be performed.
In respinse to that the node is asking the source view to
compute this.
If a view is partially covered by siblings or siblings of
predecessors that are clickable, the click point will be
properly computed to ensure the click occurs on the desired
view. The click point is also bounded in the interactive
part of the host window.
The current approach has rare edge cases that may produce false
positives or false negatives. For example, a portion of the
view may be covered by an interactive descendant of a
predecessor, which we do not compute (we check only siblings of
predecessors). Also a view may be handling raw touch events
instead of registering click listeners, which we cannot compute.
Despite these limitations this approach will work most of the
time and it is a huge improvement over just blindly sending
the down and up events in the center of the view.
Note that the additional computational complexity is incurred
only when the user wants to click on the accessibility focused
view which is very a rare event and this is a good tradeoff.
bug:15696993
Change-Id: I85927a77d6c24f7550b0d5f9f762722a8230830f
- add the noInternetAccess field
- add stats about user triggered wifi state disabling requests
- Wifi SSID can change even though we don't loose connection, hence it must be looked at with each Network State Change
Bug:17348200
Change-Id: Ic956e11e7d61faf472a7332f84a46a746922455a
This CL introduces CursorAnchorInfo.FLAG_IS_RTL for better
RTL support. This CL also renames *CharacterRect() with
*CharacterBounds() so that they can look more consistent
with other existing APIs.
Rationale:
CursorAnchorInfo.FLAG_IS_RTL addresses following issues.
1. There is no way to associate the RTL information with
the insertion marker.
2. Returning mirrored (right < left) RectF for RTL in
CursorAnchorInfo#getCharacterRect() is turned out
to be bug-prone. Such usage of RectF is not fully
supported. For example, RectF#isEmpty() always returns
false when right < left.
3. There is no reliable to provide the RTL information
when CursorAnchorInfo#getCharacterRect() returns an
empty (right == left) RectF. Perhaps we could use +0.0
and -0.0, but I'm afraid that it is also bug-prone.
BUG: 17365414
BUG: 17335734
Change-Id: Ic8c6fab58c01206872a34e7ee604cdda1581364d
When the top activity is finishing we don't want to be comparing
it for matches to launching activities. This was keeping curTop
from matching itself when launching a lower task.
Fixes bug 17383648.
Change-Id: I837ac087ef965d99d12c98ab1c779de46716e204
The requirement that the top app be resumed in order to request
background visibility was too strict. In particular when the
background app is pausing the top app will be stopped waiting for
pause to complete. This is an appropriate time for the background
app to request visibility but we were rejecting that request.
Also, there is no need for the top app to have an active thread
except to notify it of the changed state.
Fixes bug 17383876.
Change-Id: I52f910baf6c109565694e053445516e1e5fd1c48
Bug 17412818
Bug 16398271
The Visibility Transition must not run against children that
are already disappearing or there will be, for example, a double
fade-out effect. Before this change, if a parent matched another
view, it would prevent its child from disappearing.
This change also removes using the overlay for children that have
been removed from the view hierarchy indirectly. This prevents
ListView and RecyclerView children from being added to the overlay.
Change-Id: Iac0610f0939da8643b98812ee1ec1c8d1d70a215
TV input services are now required to call these methods to
unblock/block the screen.
Bug: 17364845
Change-Id: Ifb435900d7f61785198dba2e255a2d24dbf44dc6
Bug 17406204
Chrome needs to be notified when the shared element
should be hidden. The alpha setter can be overridden,
but setTransitionAlpha cannot. By setting alpha as
well as transitionAlpha, we get the immediate effect
from transitionAlpha along with enabling a trigger
for Chrome's shared element to hide.
Change-Id: I6ecb44872fd237afe89dbb36e43aa50c98693b52
Surfaces were being modified after destroy(). The check for mSurface
being null was not done while holding window the window manager lock.
This change adds locking to the surface modification methods.
Fixes bug 17383628.
Change-Id: I12ebbddc0f2cd7b43659370fac2c4fb053999bb5
Make changes to Telecomm API per review guidelines in bug:
* Rename componentName to packageName and getComponentName to
getPackageName in StatusHints
* Hide "ROUTE_ALL" and fix misspelling in AudioState
* Change getHandle to getAddress and remove getHandlePresentation in
ConnectionRequest
Bug: 17329632
Change-Id: I8b3666cc22d24f470c940825c77a7b4d0701dc16
Default device and carrier disabled.
Device to be overlayed in device/<xxx> dirs.
Carrier overlayed in this project.
Bug: 17365969
Change-Id: I95d58e934fc85506287069ddd71af4a5b7594bfb
Also include capture format in recognition event
if capture is available for streaming. It was only
included if trigger was contained in event.
Bug: 17409062
Bug: 16731718
Change-Id: I5bf566e6bda57f23c870b4a1293e9b6d15d51e5a
Add a new activity attribute, resumeWhilePausing, that allows an
activity specifying it to immediately start running without waiting
for the previous activity to pause. The recents activity is updated
to use this.
The implementation of this is ultimately fairly simple -- if we are
in the path of resuming such an activity, and find that we first need
to pause the existing activity, then within the activity manager we
do the regular pause flow but act like it has immediately finished
pausing right then so that we can immediately go on to the resume.
To make this clean, we tell the activity when asking it to pause that
it should not come back and tell us it is done, because we aren't in
any way waiting for it.
One potentially important change I needed to make here is the pause
callback no longer provides the saved persistent state, because we
now can't count on that callback happening. I don't think there was
really any utility in this anyway -- all modern apps will have their
save state flow happen as part of stopping, not pausing, so we'll
only capture that saved state when the stop is reported back anyway.
And since we do send the saved state back when stopping, it would
always blow away whatever we had gotten at the pause.
Finally, update the documentation for AppTask.startActivity(), and
fix the implementation handling that to be cleaner -- we need to
deal with inTask first before getting in to "oh noes add NEW_TASK
if this isn't coming from a calling activity" flow.
Change-Id: Ia1da0fac90d7bdbaafdda2e34850d795ce17a39f
Don't restore it too soon, because the rarely-needed fallback path
will need to be executed as system, too.
Bug 17394246
Change-Id: Ic5e662d4eae331b016fc91ffd08647bd8d4d6ff3
Dumb, dumb, dumb mistake.
Also fix battery stats wakeup reason tracking to use a SamplingTimer
(like kernel wake locks) so we can track both the duration and count
for each wakeup reason.
Change-Id: I89d69661006dc533622b1b7e68a139166d3a6975
