VCN has already known its underlying network, so set it into
NetworkCapabilities directly.
Bug: 191918368
Test: atest FrameworksVcnTests
Change-Id: Ibfe4f12bc5f3a8b7679d8a2c3b1b2f2161b9c9e5
setShouldAlwaysRespectAppRequestedMode() is called from tests to make
DisplayModeDirector.getDesiredDisplayModeSpecs() to ignore non-app
votes. However, the set boolean will have no effect until something
triggers a call to that getter.
This caused MatchContentFrameRateTest#testMatchContentFramerate_Auto to
fail on devices with a lower-than-max peak_refresh_rate setting (or the
fallback resource config_defaultPeakRefreshRate): its setFrameRate()
call doesn't trigger a call to updateRefreshRateSettingLocked() or any
other vote update, so the lower peak value is still in effect in parts
of the system.
Notify the 'desired specs' listener when changing the bool will allow
the new mAlwaysRespectAppRequest value to properly take effect.
Any multi-refresh-rate device should be able to reproduce like so:
$ adb shell 'settings put system peak_refresh_rate 60'
On userdebug, you can overlay config_defaultPeakRefreshRate instead:
$ adb root
$ adb shell 'settings put system peak_refresh_rate ""' # remove setting
$ adb shell cmd overlay fabricate --target android \
--name DefaultPeak60 \
android:integer/config_defaultPeakRefreshRate 0x10 60
$ adb shell cmd overlay enable com.android.shell:DefaultPeak60
$ adb shell stop
$ adb shell start # so system_server loads the new resource value
$ adb shell cmd overlay lookup android \
android:integer/config_defaultPeakRefreshRate # should output "60"
Bug: 204048977
Test: run cts -m CtsGraphicsTestCases -t android.graphics.cts.MatchContentFrameRateTest#testMatchContentFramerate_Auto
Change-Id: Ic6c2024ab1067ad7ba821190fe05009dac79b929
Grant this by default with the other nearby permission.
Bug: 197776854
Test: compiles
Change-Id: Iff1894a545889230c08578d8ae163116152ab28a
Merged-In: Iff1894a545889230c08578d8ae163116152ab28a
... to point to owners of health HAL. BatteryService
contains large usage of the health HAL.
Test: pass
Bug: 177269435
Change-Id: I38e7ec9e2ab25dec67ab674e9f169360f4690f1e
(cherry-picked from internal master)
This will be part of nearby devices permission group
Bug: 197776854
Test: compiles
Change-Id: I6002edfd951322d959cd8f4c7a06381badfd1660
Merged-In: I6002edfd951322d959cd8f4c7a06381badfd1660
(cherry-picked from internal master)
This will be added to the nearby devices permission group.
Bug: 197776854
Test: compile
Change-Id: I3f827be6219b5bb1595744e20b316d2b968e022d
Merged-In: I3f827be6219b5bb1595744e20b316d2b968e022d
Fix warnings introduced by previous commits and add @RunWith annotation
to new tests for consistency with existing tests.
Bug: 199481251
Test: Treehugger only
Change-Id: Iaec4caa80b15112bce84268adc6d763198f0ff61
Fix issue with SntpClient after the end of NTP era 0 (2036).
This is the second of two commits. This commit makes the actual fixes
and makes tests pass.
Before this change SntpClient converted to Unix epoch times too eagerly.
NTP 64-bit timestamps are lossy: they only hold the number of seconds /
factions of seconds in the NTP era and the era is not transmitted. The
existing code assumed the era was always era 0, which ends in 2036.
As explained at https://www.eecis.udel.edu/~mills/y2k.html,
the lossiness of the type is not an issue providing that the maths is
implemented carefully: the NTP timestamps are only ever subtracted from
each other, are always assumed to be in the same or adjacent NTP eras,
and are used to calculate offsets that are applied to client Unix epoch
times.
This commit:
+ Switches to use a dedicated Timestamp64 type, avoiding the use
of the Unix epoch.
+ Switches to use a dedicated Duration64 type for holding the
32-bit signed difference between two Timestamp64 instances.
+ Simplifies the readTimeStamp() and writeTimeStamp() methods.
+ Adds missing validation covered by a TODO. The code was randomizing
the lower bits of the client transmit timestamp, but then not checking
the result as it should, presumably because it was difficult to know
what value was sent. Easily fixed with a dedicated type.
+ Stops randomizing the lower bits of various other timestamps
unnecessarily.
+ Fixes some naming to add clarity.
Bug: 199481251
Test: atest core/tests/coretests/src/android/net/sntp/Timestamp64Test.java
Test: atest core/tests/coretests/src/android/net/sntp/Duration64Test.java
Test: atest core/tests/coretests/src/android/net/SntpClientTest.java
Merged-In: I6d3584f318b0ef6ceab42bb88f20c73b0ad006cb
Change-Id: I6d3584f318b0ef6ceab42bb88f20c73b0ad006cb
Fix issue with SntpClient after the end of NTP era 0 (2036).
This commit is 1/2. It makes some refactoring changes, lint fixes, adds
tests and introduces types that will be used in 2/2. Some of the added
tests fail and demonstrate the issue being fixed with the current
implementation.
-----
Failures that demonstrate the bug:
android.net.SntpClientTest#testRequestTime_era1ClientEra1Server
STACKTRACE:
junit.framework.AssertionFailedError: expected=5, actual=-4294967295995, allowedSlop=1
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at android.net.SntpClientTest.assertNearlyEquals(SntpClientTest.java:502)
at android.net.SntpClientTest.checkRequestTimeCalcs(SntpClientTest.java:215)
at android.net.SntpClientTest.testRequestTime_era1ClientEra1Server(SntpClientTest.java:201)
android.net.SntpClientTest#testRequestTime_era0ClientEra1Server: FAILED (145ms)
STACKTRACE:
junit.framework.AssertionFailedError: expected=1139293696005, actual=-3155673599995, allowedSlop=1
at junit.framework.Assert.fail(Assert.java:50)
at junit.framework.Assert.assertTrue(Assert.java:20)
at android.net.SntpClientTest.assertNearlyEquals(SntpClientTest.java:502)
at android.net.SntpClientTest.checkRequestTimeCalcs(SntpClientTest.java:215)
at android.net.SntpClientTest.testRequestTime_era0ClientEra1Server(SntpClientTest.java:174)
android.net.SntpClientTest#testNonMatchingOriginateTime: FAILED (116ms)
STACKTRACE:
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:48)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertFalse(Assert.java:34)
at junit.framework.Assert.assertFalse(Assert.java:41)
at android.net.SntpClientTest.testNonMatchingOriginateTime(SntpClientTest.java:384)
------
This commit:
+ Introduces a dedicated Timestamp64 type + test for holding NTP
timestamps.
+ Introduces a dedicated Duration64 type + test for holding the
32-bit signed difference between two Timestamp64 instances.
+ Fixes some naming to add clarity / addresses lint issues.
+ Adjusts tests
Tests are NOT expected to pass with just this commit. See 2/2.
Bug: 199481251
Test: atest core/tests/coretests/src/android/net/sntp/Timestamp64Test.java
Test: atest core/tests/coretests/src/android/net/sntp/Duration64Test.java
Test: atest core/tests/coretests/src/android/net/SntpClientTest.java
Merged-In: Ifdaada39298b05c48a3207fe6c0fad71c8a0a252
Change-Id: Ifdaada39298b05c48a3207fe6c0fad71c8a0a252
Add android.net tests to postsubmit. The tests / annotations will
be added in a separate commit.
Bug: 199481251
Test: Treehugger / inspection
Change-Id: I17cb464979535c767bbb8ee22fd7456ff08bae6c
BT mainline effort to remove hidden api:
`avrcpSupportsAbsoluteVolume` only inform for a new volume behavior and
AudioManager already provide such method.
Bug: 190422401
Tag: #refactor
Test: Manual: Start bluetooth, play music and change volume from speaker/phone
Change-Id: I935df5e0f5632cd4144343bdb1bc2b9d7bc61c01
Some OEMs use test SIMs which have ICCID=FFFFFFF... In this case we
don't strip trailing F's.
Bug: 199254579
Test: manual
Change-Id: I69b40fa75e59163e8c30be77cc38e908d6dd8cd4
This will allow us to point other directories at these files for OWNERS
and make it easier to update after future team changes.
Test: N/A
Bug: 202714830
Change-Id: Iaaf5b8eb7568be4ebfd1b30abae0b757153f0391
