TYPE_TEXT_FLAG_NO_SUGGESTIONS is just a hint and does not mean
IME should never show a UI to display suggestions.
This CL makes that point clear in JavaDoc.
Test: checkbuild
Bug: 35875399
Bug: 38139781
Bug: 38184682
Fixes: 65693181
Change-Id: Id0c3b6bc05689a5f1c8b52637664f59d45850a60
RPM = resource power manager.
Fetching the rpm stats (specifically, the subsystem low power stats) is
slow... too slow to reasonably do each time the screen state changes.
Therefore, it is disabled until fetching this information can be done
more quickly. Consequently, the screen-off RPM values will be incorrect
until it is re-enabled; they are therefore not printed.
Bug: 65164435
Bug: 62549421
Test: manual
Change-Id: I54d54f244c69ee372f22ecd99f32570db4aeb222
RPM stats are expensive to fetch. However, updateRpmStatsLocked can
get called over and over again. E.g. if
BatteryStatsService.getStatistics is called multiple times in quick
succession, the RPM stats would be fetched repeatedly. Because it is
expensive, if therefore makes sense to throttle it to ensure that the
fetching is not done too frequently.
The data last fetched is cached. When asked to update, it will only
actually do so if it is sufficiently old.
Bug: 62549421
Bug: 65629008
Test: manual
Change-Id: I6b7530d203deb9ad5bfb3415336a0de6a55bd89b
Bug: 65354043
When an empty AnimatorSet is used in a fragment animation,
it can end immediately. This CL properly detects this
case and handles it properly.
Test: manual, ran fragment CTS
Change-Id: I63bee3818106f9c8e86cdc94af61d6bc8407c789
Currently Resource Power Management (e.g. VMIN time) is reported in the
batterystats history each time the battery level changes. We need this
information in the batterystats checkin, and need to be able to
differentiate time spent in each power state/voter, total as well as
when the screen is off.
The RPM information is obtained via a JNI call to the appropriate HALs.
Batterystats report version is increased to 26.
Bug: 62549421
Test: manual
Change-Id: I0c384eb3950714d8a0aa1353a4bf965330ebc8c1
Line height calculation with maxLines set to zero displayed a single
line when BoringLayout was used. This CL fixes it to show zero lines.
Test: Added related CTS tests to TextViewTest and EditTextText
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 65435738
Change-Id: Ic21eb50b31666b2dcc2398278010fa072ea1ff67
This logs when the selected text is changed e.g. by typing on
the hard or soft keyboard.
Bug: 64914512
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Merged-In: I82b3b2157856c607d08a82c0a3d9fb938af4c06a
Change-Id: I82b3b2157856c607d08a82c0a3d9fb938af4c06a
- Fix count with selection start index inside a word
- Properly handle whitespace characters
- Set the model version tag
Bug: 64914512
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: Manually tested that logs are correct. Will follow up with automated tests.
Merged-In: Ib73b52ebce999f2cb6e5734e556cd09e47c89a29
Change-Id: Ib73b52ebce999f2cb6e5734e556cd09e47c89a29
No change to logic, docs only.
This documents shouldInterceptRequest request behavior when Safe
Browsing is enabled, with recommendations for how this can be avoided
depending on the application's needs.
Bug: 65555402
Test: make docs (manually verify links all work)
Change-Id: I055254bfae3a06061402c519e8740ec4d9779e8f
This CL reverts my previous CL [1] that aimed to get rid of
a nasty compatibility hack that was introduced for Bug 36345857.
For those who are interested in, what happenned are:
1. @hide method SurfaceView#setWindowType() was removed [2].
2. It broke some app (Bug 36345857). We had to work around
it by re-introducing SurfaceView#setWindowType()
temporarily [3].
3. Some app switched to the correct implementation when
running on Android O devices.
4. We removed that compatibility hack [1] (Bug 62054282).
5. Android O MR1 is set to be "REL" [4].
6. It broke some app, probably because of some unfortunate
mistake in the version check logic in that app.
7. We end up introducing the same hack again for O MR1.
[1]: Icee198c554de558cfa4ffe0b264064969839654e
7a1ad6d97c
[2]: Ie56b6f7ab16f32d7fc459b8eba26594337ad55de
d5c7dd6da8
[3]: I5217f6417a73690ae8a978754218b7b089070fdd
3b5011afc9
[4]: I054e3ecff49803e61e7741753fe6764a567d72c4
62a835d0ef89e51f4a97fecf8576224551b545a5
Bug: 36345857
Bug: 62054282
Fixes: 65508814
Test: Manually verified that Bug 65508814 is not reproducible
Change-Id: If8a3f726789daa22f73e1962e938f071d3c09414
...and screen was flickering badly
Don't crash if we get a bad pointer ID, just log a wtf
for us to find in APR.
Bug: 65333586
Test: manual
Change-Id: I6f522e05735a64b672c011012c3e3514d454dd8f
Bug: 65268614
When an activity transition was used with the top activity being
translucent, and the top activity calls finish() instead of
finishAfterTransition(), the transitioned views were not being
drawn properly. The source of the problem was that
setTransitionVisibility() was being used instead of setVisibility().
Transitions normally use setTransitionVisibility() to modify
the view's visibility without triggering an invalidation. But
when we want the view to be invalidated by the visibility change,
setTransitionVisibility() prevents the invalidate() from
actually invalidating the view.
Test: manual
Change-Id: I250ea232052d1a1309d3341504cba77543a94eec
