Symptom:
Media volume bar shows non-zero value even during the mute state.
Root cause:
A request for updating progress of ProgressBar has 2 kind of updating
ways, animated and non-animated. If a non-animated request is invoked
before completing an animated request, the visual progress can be
overwritten by the old animated request. As a result, the visual
progress value becomes different from the actual value.
Solution:
A running animation on the primary progress should be canceled
before handling a new non-animated request.
Bug: 148759348
Test: atest CtsWidgetTestCases:ProgressBarTest
Change-Id: I569dbea4c6346ecfff8141d8378b4952fb1fa530
Merged-In: I569dbea4c6346ecfff8141d8378b4952fb1fa530
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I41e12e425284e74561c6b61663241df364ae54a1
Merged-In: I41e12e425284e74561c6b61663241df364ae54a1
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I5be7335b23a92b8ac80d2fd890198273b66ad644
Merged-In: I5be7335b23a92b8ac80d2fd890198273b66ad644
go/cleanup-greylist-txt
These have already been greylisted, however due to bugs/omissions in the tooling have been kept in go/greylist-txt instead of being annotated in the code.
Bug: 137350495
Test: m
Change-Id: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Merged-In: Id6c1f5e403a0e66edb1102ee45f3bf19f244fb09
Issue:
TextClassifierService failed to invoke the callback to send the result back to client
occasionally because the callback object may be GCed.
And thus smart selection failed occasionally, as the client doesn't get a response
back when it hits this issue. It won't fallback to local textclassifier due to the
timeout specified in TextView.
Cause:
We thought that ITextClassifierCallback is a "cross process" reference, and
so we only store a weak reference of it to avoid leak.
And it turns out that it is wrong. As soon as the weak ref gets GCed in
the service, that counts as dropping the callback. The service doesn't
know about any strong references the client has.
Bug: 138865849
Test: Try smart selection over 30 times, make sure smart action is shown
for every single time.
Merged-In: Ia9218cf67e8d67697a0fdff22c7918a55efc39ca
Change-Id: I4d89518dfff777ba5d999d9ba89d7f4cf7598e75
The example ImageView at the beginning of the class description now
includes a content description attribute. Also updated the links in
the first paragraph where code fonts aren't necessary.
Test: make ds-docs -j32
Bug: 138856073
Change-Id: I33a75dc31d68289d955979d2fe8afe2ae3d4770e
Sys UI runs on user 0. This can lead to the TextClassifier (TC)
running for the wrong user. Consequencies are user A can launch apps
in user B via the TC's predicted actions and selected text being
unintentionally shared from user A to an app running in user B.
This fix ensures that the correct user id is passed and verified for
every TC request going across process boundaries (i.e. via SystemTC).
- Sys UI sets the appropriate user id in the TextView
- TextClassificationManager (TCM) system service is constructed using
a context generated from this user id
- SystemTC sets this user id before querying the TCMService
- TCMService validates the user id before forwarding the request to
the TCService belonging to that user id.
Bug: 136483597
Bug: 123232892
Test: atest android.view.textclassifier
atest android.widget.TextViewActivityTest
(manual) See I2fdffd8eb4221782cb1f34d2ddbe41dd3d36595c
Change-Id: Ibe68bc9e257521de97cbb014176b2b8ba23547d1
