To support unmetered 5g, have buildTemplateMobileWithRatType take
metered parameter to build a template which could be used to filter
an unmetered network.
Bug: 183776809
Test: atest FrameworksNetTests:NetworkStatsServiceTest
Change-Id: Ia310d90eceeb572a35ce9518de02b198cae16705
Merged-In: Ia310d90eceeb572a35ce9518de02b198cae16705
In old design, only metered mobile network would be matched,
which means that only metered stats could be read if callers
query the mobile stats.
Currently, the caller in NetworkPolicyManagerService was updated
to use the NetworkTemplate constructor with metered parameter in
aosp/1563312 which means that the template will be created by a
given meteredness. Thus, the hardcode metered can be removed.
Remove the metered check from matches method will cause a
different behavior. Therefore, to keep the original behavior,
if the match rule is MATCH_MOBILE or MATCH_MOBILE_WILDCARD,
it should pass METERED_YES to the constructor to build a
metered template.
Also, if a caller creates a template by calling the constructor
with metered as a parameter, the behavior will also be changed.
Therefore, if the caller expects to get metered stats then it
should change to pass METERED_YES. If the caller expects to get
both metered and unmetered stats then it should remain METERED_ALL
and it would be a bug that been fixed by this patch.
Bug: 183776809
Bug: 202092687
Test: atest FrameworksNetTests:NetworkStatsServiceTest
manually test by generating traffic and check the data counts
from "adb shell dumpsys netstats --uid" almost equal to the
result from "adb shell cmd stats pull-source 10082"
Change-Id: I66dd51b020f6d895cd002acc05bef6b6315cd447
Merged-In: I66dd51b020f6d895cd002acc05bef6b6315cd447
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
When an app enters split-screen mode, the mAnimatingActivityRegistry of the current Activity still comes from the app's Task, but the mAnimatingActivityRegistry of the newly opened Activity comes from the split-screen Task, so there is no guarantee that the animation-leash of the transition animation will be destroyed at the same time.
So we ensure that the mAnimatingActivityRegistry of ActivityRecord under the same Task is the same after entering split screen mode, so as to ensure that the transition animation of activity opening and closing ends at the same time, thereby avoiding splash screen.
Bug: 204024254
Test: Above scenario
Change-Id: Ibf0fccecefaa8768b4e10f69a064a4b7452dcaa9
Signed-off-by: shicheng <shicheng@xiaomi.com>
The ndk_platform backend will soon be deprecated because the ndk backend
can serve the same purpose. This is to eliminate the confusion about
having two variants (ndk and ndk_platform) for the same ndk backend.
Bug: 161456198
Test: m
Merged-In: I674244ff9b873d3779d3d649822389ad441fa0af
Change-Id: I674244ff9b873d3779d3d649822389ad441fa0af
(cherry picked from commit 672b1349c86f4ae024e71587fc05bf8af046a53d)
Added typed read APIs of `readArray`, `readArrayList`,
`readParcelableArray` and `readSparseArray`.
To avoid unexpected types of objects being unparcelled,
ideally clients would use the readTypedXXX() methods that
take the parcelable creator. However, this won’t be an option
for use cases involving deserializing children objects
inherited from non-final parcelable or serializable objects.
Currently out of ~4k parcelable classes, only ~1.5k
are marked as “final” in the platform. Hence it would be
necessary to introduce new replacements that take
an extra Class<T> parameter and before deserializing
we check that the class written on the wire is the
same or a descendant from the one provided as argument.
Doing so could enhance the security of Parcel deserialization,
More details can be found at go/safer-parcel.
Test: atest -d android.os.cts.ParcelTest
Bug: 195622897
Change-Id: Iaba24c35a0c0acc77ae2d22ac77c5a90efd93329
This can be done by adding the 'special-codec' feature as a required
feature to media_codecs.xml, e.g.
<MediaCodec name="..." type="...">
...
<Feature name"special-codec" required="true" />
</MediaCodec>
This feature is not exposed to applications, and is only used to
exclude a codec from the REGULAR_CODECS list.
Bug: 197577115
Bug: 196518411
Bug: 191944087
Test: CtsVideoTestCases and manual testing with a modified media_codecs.xml
Change-Id: Ica5510bbe7e781f25ca329535d2ba771afbdb263
Grant this by default with the other nearby permission.
Bug: 197776854
Test: compiles
Change-Id: Iff1894a545889230c08578d8ae163116152ab28a
Merged-In: Iff1894a545889230c08578d8ae163116152ab28a
Fixes a regression that was introduced in aosp/1312940.
There is a critical section in requestNetworkScan after the scanId
has been generated and before the ScanInfo is added to the cache.
If during this time a callback fires on a separate thread, it will
not yet find the ScanInfo record, and due to strict checking, this
causes a RuntimeException. This CL re-expands the synchronized block
to cover the critical section, and clarifies a little bounds checking.
Note: this change is not ideal. This means that all callbacks for all
scans will be blocked while a request for a new scan is being made,
which was the motivation behind the change that introduced this
regression. But, a narrow performance hit is better than a crash, and
it's not worth the complexity of a bigger fix.
Bug: 200634560
Test: compilation
Change-Id: I4670da109256170121ceb6d8fbad0efda310335f
... to point to owners of health HAL. BatteryService
contains large usage of the health HAL.
Test: pass
Bug: 177269435
Change-Id: I38e7ec9e2ab25dec67ab674e9f169360f4690f1e
The two are almost identical, and the target using sources as input
can be deleted.
The diffs that remain are minor and as far as I can tell OK:
- A few constants are removed from the metadata.zip. It looks to
me like metalava was previously including @SystemApi constants in the
public SDK's metadata. This bug is now worked around by only feeding
metalava the public APIs.
- There are some very minor diffs in the docs of a few APIs.
Bug: 186197911
Test: build sdk before/after and diff
Change-Id: Iac7de64f353bc1467fc4b249e531f034ef702d51
(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
Make ownership of dex-related files in pm/ the same as the files in
pm/dex/.
Also grant ownership to related tests.
Test: N/A
Change-Id: I47cd50e7f5ea512e286394a77bafb02f42c8e5bb
The change in aosp/1806594 is adding a method to the binder ndk called
isHandlingTransaction, but that method behaves differently from this
method when HIDL gets involved, as getCurrentServingCall returns
HWBINDER in that case.
Test: m
Change-Id: Ie2812943d1e98e99a1c361475965a2c75214724a
