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
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
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
No longer used by Settings as the logic was wrong.
Test: gts-tradefed run gts -m GtsOemLockServiceTestCases
Bug: 65124732
Change-Id: I44e5f697aabd2b5eefecf64060502b5c9ef5f911
(cherry picked from commit d37fe2d3e1)
TextView#performLongClick() calls View#performLongClick which
calls View#performLongClickInternal() which, if handled, performs
the longpress haptic feedback and returns handled. TextView
looks at this return value and if it is true then makes another
call to perform longpress haptic feedback. Remove the duplicate
call in TextView as the one in the parent (View) is sufficient.
Bug: 65397911
Test: manual
Change-Id: Ic73a86637486d5382b63f1c1b37783e238452841
Bluetooth scanning requires holding these permissions for results
to be delivered.
Bug: 65013767
Test: N/A
Change-Id: I0b5fa9efa7fc8d5cff25319fbd7719cedee6a4aa
