1. Used SSID to be a wifi network identity can't separate wifi
data usage when there are two different network with same SSID.
Use a new usage key from WifiInfo to replace wifi SSID to solve
this issue.
2. To support to query wifi usage per configured Wifi network.
Adding matchWifiNetworkKeys in NetworkTemplate to support querying
multi networkKeys wifi data usage since each configured Wifi
network configuration might be used to connect different Wifi
network. (Replace mNetworkId with mMatchWifiNetworkKeys)
3. Updated callers who were using NetworkTemplate constructor.
4. Fixed SortedSet null order case. The null subscriberId is a
valid input for matchSubscriberIds.
5. Replaced ArrayUtils with CollectionUtils.
Bug: 197520752
Bug: 126299427
Test: atest -c NetworkTemplateTest
Test: atest -c NetworkStatsServiceTest
Test: atest -c NetworkPolicyManagerServiceTest
Test: atest -c NetworkPolicyTest
Change-Id: Ie20e7fb56597817901be4ce1d2a7afcbc9ded0c6
Since the NetworkTemplate serialization is done in the platform
code. To decide whether the template is persistable should be
also inside the platform along with the serialization logic.
Test: atest NetworkPolicyTest
Bug: 204830222
Change-Id: I15d17dda77e6a3e1ae11275915e3d2f6e2888639
Since NetworkTemplate will be moved into the mainline module.
It is necessary to remove hidden BackupUtil usage from
NetworkTemplate. Also, it is also a hazard to maintain
compatibility for byte buffer interfaces.
Thus, move out these cloud backup functions to NetworkPolicy
to address these concerns.
Test: atest NetworkPolicyTest NetworkPolicyManagerServiceTest
Bug: 204830222
Change-Id: I3ec55f7e419ea13db535acff2457d8e7aaebdce8
Made BluetoothCodecConfig and BluetoothCodecStatus public,
added Builder to BluetoothCodecConfig, added accessor for
SOURCE_CODEC_TYPE_MAX and changed Arrays returns to List.
Tag: #feature
Bug: 200202780
Bug: 170678351
Test: BluetoothCodecConfigTest & BluetoothCodecStatusTest
NoNonSdkCheck: Only user actually requested the changes
Change-Id: Ic61b7087f53f45781f7e0eecca8b6d983093a22d
1. Rename function getHwOffloadEncodingFormatsSupportedForA2DP
to getHwOffloadFormatsSupportedForBluetoothMedia
2. Add audio format for LC3
3. Add public class BluetoothLeAudioCodecConfig to store the
codec for LE audio
4. Add test case for BluetoothLeAudioCodecConfig
Tag: #feature
Bug: 203535499
Bug: 150670922
Test: atest BluetoothLeAudioCodecConfigTest BluetoothInstrumentationTests
Change-Id: I5f64d9078ca2c07e13cffd83b879dd95468ed313
Merged-In: I5f64d9078ca2c07e13cffd83b879dd95468ed313
To be used by lazy value. Now, we also remove getValueParcel() that was
copying the section of the parcel since we don't need that anymore.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: Ic8a0d1b6a268a81df7a1e56fa1e4b307a25210b6
APEXes can already contain RRO APKs by using the 'rro' apex Soong
module field. However, these RROs were not being loaded properly by
Zygote or PackageManagerService.
For all RROs inside APEXes, the RRO uses the same overlay config that
is used for other RROs on the APEX's preinstalled partition.
For RROs targeting 'android', which are installed by Zygote
using AssetManager:
1. OverlayConfig looks for active APEXes in the apex-info-list file,
which is already accessible to Zygote.
2. OverlayConfig passes the APEX module names to OverlayConfigParser,
for each preinstalled-partition.
3. OverlayConfigParser uses OverlayScanner to scan the
each /apex/<APEX>/overlay directory.
For other RROs:
1. PackageManagerService already parses and provides RROs inside APEXes
to OverlayConfig.
2. RROs inside APEXes used to have no config rule applied because their
path prefix (/apex/) did not match any partition rule. Now, their
preinstalled path is used instead.
Bug: 199200417
Test: Define a static RRO targeting 'android' inside a /vendor APEX.
Define a static RRO for settings provider inside a /vendor APEX.
Observe APEXes are enabled by default.
Test: Make a change to an RRO inside a /vendor APEX.
m <apex>; adb install <apex artifact>; adb reboot;
Observe change has taken effect.
Change-Id: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
Merged-In: I2bce9bc704789329b8c6aac6d476f17ff6718e0f
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
Commit e5ad1297165888eb5eef24c1985e64b18b8fb88b combined with pending
reviews demonstrated the OWNERS syntax has quirks and it is not working
as intended.
Documentation used:
https://android-review.googlesource.com/plugins/code-owners/Documentation/backend-find-owners.html#syntax
The syntax guide recommends that patterns like sub-dir/* aren't used as
they can cause problems when renaming directories; better to have OWNERS
in the sub-dir. The pattern sntp/* didn't appear to be working (perhaps
because of spaces).
Test: None
Bug: 199481251
Change-Id: I193744eaaad529b9680d3ccf905b86d68f62f7ff
This changes owners files based on latest org changes and changes
links to improve maintainability.
Changes:
+ It removes a specific owner from most to reduce future maintenance.
+ It adds indirection so android/app references the associated service
code, tests reference the OWNERS of the code under test.
+ services/core/java/com/android/server/timezonedetector/OWNERS is the
single list of time / time zone detector maintainers.
+ Code associated with time zone rules moved to libcore/ ownership
+ It adds one new file for an upcoming commit.
+ Added documentation around API purpose to API OWNERS files, since
there are multiple similar-looking package names with different purposes
/ clients.
Test: None
Bug: 189810551
Change-Id: I948d4b8eff59f3cd5ff63018949e49679795a5c0
Bytes matcher has been moved to frameworks/libs/modules-utils in this
CL: aosp/1821533
Bug: 200202780
Tag: #refactor
Test: atest cts/tests/tests/bluetooth/src/android/bluetooth/cts/ScanRecordTest.java frameworks/base/core/tests/bluetoothtests/src/android/bluetooth/le/ScanRecordTest.java
Change-Id: I4d374217100635a49918f8e88f2cb5327e758e9f
Replaced hidden API usage in Companion by public
methods.
Tag: #feature
Bug: 200202917
Test: atest CompanionTests
Change-Id: Ifc7cdcbf40e23d1c8870e4dcd44772dcae55120a
With lazy bundle, exceptions thrown by deserialization of custom items
moved from being thrown in initializeFromParcelLocked() (when the bundle
is first touched) to being thrown in getValueAt() (whenever the item is
retrieved), which means they were escaping the defuse logic that caught
those exceptions. So, now also catching these exceptions in
getValueAt(), however, here we can be much less drastic, instead of
erasing the bundle, we can simply remove the bad element.
This also means we don't need to log wtf in initializeFromParcelLocked()
if sShouldDefuse = true but the bundle is not marked as defusable, since
touching the bundle doesn't carry the same consequences as before
go/lazy-bundle. So, I moved that log to unparcel(itemwise = true), ie.
whenever the entire bundle is deserialized on purpose.
Now, 2 types of defusing can happen:
1. If the (custom) item we're retrieving caused the exception, we'll
remove the item and return null.
2. If the exception was raised during partial deserialization, that is,
during the read of the map and its basic types (while skipping custom
types), the map will be left empty. I believe only manually written
parcels would cause this type of exception and if an exception is
raised here it will also be raised in the final destination too,
afaict. Because of this, we can now touch app-provided bundles
without fear of clobbering the data on its way to the final
destination.
Following conversation on previous CL, narrowed exception raised in case
of unknown type to be BadParcelableException.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I4746140f63482a9ea475aac25897a447737393e4
Log mismatches as wtf to be able track those. Also added unit tests
around kindofEquals() and r/w mismatches.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I361dd144b23975eedc8b19ed65457a1c5405936e
The mainDexClasses script is obsolete, pass the rule to d8 with
--main-dex-rules instead.
Test: mma
Change-Id: Ia88660550c3e57749b8ccb154e97c31aaf2fcf3a
If the lists of custom power components do not match, a crash will occur.
Instead of causing a crash, simply skip incompatible snapshots.
Bug: 196040329
Bug: 200511361
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryUsageStatsProviderTest
Change-Id: I87ba605371a5f3119dcff33f6109e94ee46ab57d
(cherry picked from commit a1ea9ecd56fce8bb84fc673650b6be7282ea0e99)
