The restriction on system property key length has been lifted.
Update the invoke-with code to first check the full-length property.
Then fall back to the truncated version for backwards-compatibility.
Bug: 37276041
Test: m
Test: manual with long package name (Maps)
(cherry picked from commit 4c88a8c684)
Change-Id: Ic27a26a676f7ac5a998a9bea14259725e89b7e37
This reverts commit 8f7bebca36.
We now want multiple channels so the user can disable which ever ones they like.
Change-Id: I6015cd5f1e3f37a8a01e1db42b57a94087780304
Fixes: 38428796
Bug: 37422870
Also includes some minor code clean ups.
Fixes: 38465735
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: Ie87cc256b77b3ec5732f49c000ce4845130fc91c
Since we hide the navigation bar background during resizing, we
need to fill it with the fallback background.
This was always an issue but somehow in OC we are displaying
garbage instead of black.
Test: Open Contacts/Dialer, resize, make sure no underdraw is
happening. Also test a couple of other apps.
Fixes: 36206155
Change-Id: I6b02060ef4acf36c2529d49063a61034f9261696
Currently, the time for each partial wakelock was tracked. If one
wants the total time that a uid held partial wakelocks (over all of its
wakelocks), they could sum over all the uid's partial wakelock
totalTimes, but this would underestimate the value because totalTimes
are pooled amongst all uids. Alternatively, they could sum over all the
uid's partial wakelock totalDurations, but this would overestimate the
value because totalDurations are not pooled within the uid (so there
will be double-counting if two wakelocks are held simultaneously). This
cl adds a new timer that specifically tracks the actual total time that
the uid spent holding wakelocks, and also provides the ability to see
how much time the uid was in the background when doing so.
Bug: 38198272
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Change-Id: I20ea3546338c44ffdf06859bc840d9059fb18321
The MessagingLinearLayout and the ImageFloatingTextView tests were
broken.
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/widget/MessagingLinearLayoutTest.java
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/widget/ImageFloatingTextViewTest.java
Change-Id: Ife32b600e2082400a8ee2f86310a51fd88c1b80c
Fixes: 38182087
- Fix MenuItemImpl setShortcut bug caused when method signature was
changed after API review
- Remove outdated MenuItem coretests and move others to CTS
Bug: 38114634
Test: Run `cts-tradefed run cts-dev -m CtsViewTestCases -t
android.view.cts.MenuTest`
Change-Id: Iebb7e314cbb3f812fcfeb3f95797f1cf1bcfbae2
(cherry picked from commit d70d2e6efc)
Because we were relying on the output to go in the right direction
already, this could be wrong. We're now only following the given
lightness direction if it is even possible to satisfy contrast.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java
Change-Id: I06d934a6b5c328ebbf0cf707030b0d707ccb5ab4
Fixes: 38182819
There would likely be too many BLE scan result calls for batterystats to
be healthy. Therefore, the caller can supply a count by which to increase the
counter, instead of doing it one result at a time.
Bug: 37720787
Test: runtest -x frameworks/base/core/tests/coretests/src/com/android/internal/os/BatteryStatsTests.java
Change-Id: Ib8b2e8d250036be24c6c3dac477bc8d34fe498a6
Currently we have total user and system cpu time spent by the uid
in the batterystats. This change will add times spent by the uid
at each different cpu frequency to the batterystats dump which will
help in better understanding the battery usage.
Bug: 34133340
Test: manual
Change-Id: I567dc75875eb58543c0e71572d0b440e87dbb4b9
Due to views being offset during the ChooserActivity animating in
direct share targets, it was possible to touch down on the sheet
attempting to tap, but have it be interpreted as a fling downward as
the relative touch position within the parent was moving. Lock the
dismiss gesture during animations to prevent this.
Bug: 36032762
Test: manual
Change-Id: I18b6f03148cbf402efc23e873262927e412ea7b7
For 464xlat scenarios on IPv6 networks, the clatd interface setup
introduces double counting of apps ipv4 traffic. NetworkStatsFactory was
accounting for this on the tx path, but not on the rx path. Also it did
not accounted for the 20 bytes added by the IPv6 header.
This patch subtract correctly the rx and tx traffic from the root uid on
the underlying interface, and also adds correctly the 20 bytes cost per
packet on the stacked interface for 464xlat traffic.
Test: added several new unit tests, based on synthetic data and real
data also.
Bug: 33681750
Change-Id: I4867fe181938d94b5594b3d88896a3c4e01d895c
Merged-In: I2675643b220acbc6110179fa937d4c313b6f5e32
(cherry picked from commit e1bb3a14d1)
- Construct the NETWORK_AVAILABLE NotificationChannel in
SystemNotificationChannels
Bug: 37794067
Test: make
Change-Id: I27aa69f8d038af238343eabc706147a02cad7330
we have a link to the client which is enough to find the views.
Also there was some cases where the windowToken was not updated
properly. This is moot now.
Also: Read a array of views from the client to speed up the
client<->AutofillManager communication.
Fixes: 38070352
Test: CtsAutoFillServiceTestCases
1 Started autofill, saw fill UI
2 Home button
3 Kill activity in background
4 Recents -> back to activity
5 Saw fill UI restored
Change-Id: I7c2c9411204fa5d65867efae9b7296399121c3a2
This CL gets rid of unnecessary operations from
LocaleUtils.filterByLanguage() to speed it up, especially for the case
where there is an IME that has many subtypes.
ULocale.addLikelySubtags(ULocale) is known to be slow. Given an IME
that has N IME subtypes, LocaleUtils.filterByLanguage() calls it no
less than N times even when the only one system language is selected.
This has contributed to device boot time (Bug 32343335) time and user
switching time (Bug 28750507) since Android N where IME support
started taking multi-locale into account.
With this CL, LocaleUtils.filterByLanguage() no longer calls it
for a subtype unless its language part of the locale matches one of
user-selected system locales.
The only assumption we made here is
for any Locale objects l1 and l2
TextUtils.equals(l1.getLanguage(), l2.getLanguage())
and
TextUtils.equals(ul1.getLanguage(), ul2.getLanguage())
are equivalent, where
ul1 = ULocale.addLikelySubtags(ULocale.forLocale(l1)) and
ul2 = ULocale.addLikelySubtags(ULocale.forLocale(l2))
This should be reasonable assumption, at least for locales we want to
care about for IMEs. Under this assumption there is no behavior
change at all.
Test: bit FrameworksCoreTests:com.android.internal.inputmethod.LocaleUtilsTest
Bug: 37647204
Change-Id: Ic96900fcaf3db8b7046a50b3fe6ad65aceada369
The low priority notifications had their contrast calculated
against the white background and weren't satisfying
our contrast requirements.
This also aligns the case where the app had no colors better,
and ensures that it's actually using the secondary text
color there.
Test: existing tests pass
Change-Id: Ic11e9d06783e60998f35e0eb7f6f29fb1d86c7df
Fixes: 37444266
