This should help make sure the two stay in sync, and that the values
don't get rearranged.
Bug: 67013665
Test: N/A
Change-Id: I43f617b69d8c8107755c13dbfa8f071ef2c7c554
Want to be able to support allowing a Slice to specify some keywords
associated with it; need a new hint to identify these.
Bug: 74086214
Test: make
Change-Id: I79d3f1806eecf416f5e3ae09451b90507b382c24
We only stop scanning on timeout but don't limit the time the
user has to select a device.
So timeout != failure. Cleaning that up from javadoc to avoid confusion
Fixes: 74080737
Test: proofread
Change-Id: I36b2d96f85c3c15c20742b954a0b34956f23d6f8
Id65a7e36487375f0e3a2c2da44ad8d7c5ea49734 changes the typeface
associated with the TextView. It used be null if no attribute was set,
but after above change, it is now Typeface.DEFAULT.
The typeface is null means Typeface.DEFAULT but there is an expectations
in CTS that getTypeface must return null if no attribute was set.
To keep this behavior, call setTypeface with null if no font weight value
was set.
Bug: 74080879
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
Change-Id: Ic91827bbeed8a3a4b148dd8d305c78e384407ab0
Recently we successfully removed the restriction that up to one
SpellCheckerService can be active at the same time [1]. This still
makes much sense at high level, but at the ecosystem level there are
still some products / components that depend on the previous behavior
that child profile users can use parent profile's spell checker
service, which was originally introduced as a stopgap solution for
Android N MR1 [2].
Our decision for Android P for now is to revert back to the previous
behavior only when the calling process is running under work
profile.
At the implementation level, we can summarize the new behavior as
follows:
* When TextServicesManager APIs are called from work-profile
processes, those API calls will be evaluated with parent-profile's
user ID to match the previous behavior [2].
* If the currently selected spell checker is not a pre-installed
one, then API calls from work profile will fail to match the
previous behavior [2].
* When TextServicesManager APIs are called from non work-profile
processes, those API calls will continue being evaluated with
calling user ID, as we planned for Android P [1].
* TextServicesData will not be created for child profile users.
[1]: I06c27ef834203a21cc445dc126602c799384527b
06a2624049
[2]: Iae9045ba5baccd04ed68906e7afb9160677ec4a5
095fa37164
Bug: 63041121
Bug: 64718412
Bug: 70922751
Bug: 73609140
Fix: 73862883
Test: atest FrameworksCoreTests:com.android.internal.textservice.LazyIntToIntMapTest
Test: Manually tested with Test DPC as follows:
* When AOSP Spell Checker is pre-installed and the current spell
checker, both main profile and work profile can use AOSP spell
checker.
* When SampleSpellCheckerService is side-loaded and the current
spell checker, only main profile can use
SampleSpellCheckerService.
Change-Id: Ic046f832f203115106409a53418a5746eb6d4939
In NotificationManagerService#cancelToast we have been calling
WindowManagerService#removeWindowToken with 'removeWindows'=true. This
is allowing for Surface destruction without any sort of synchronization
from the client. Before the call to removeWindowToken we are emitting
a one-way hide call to the Toast client. As a solution to the lifetime
issue we have the client callback to let us know it has processed the
hide call (and thus stopped the ViewRoot). On the server side we also instate
a timeout. This mirrors the app stop timeout. All codepaths I could find
leading to this sort of situation where a client is still rendering
in to a toast following the total duration expiring seem to indicate a hung
client UI thread.
Bug: 62536731
Bug: 70530552
Test: Manual. go/wm-smoke
Change-Id: I89643b3c3a9fa42423b498c1bd3a422a7959aaaf
The AudioManager now handles all calculations for volume stepping now
and no longer uses adjustAvrcpAbsoluteVolume.
Bug: 68812037
Test: Compile
Change-Id: I9cbf7989e49738c7a43fe3142aced5803111271e
