Device ID attestation was failing in AOSP and GSI images due to
properties mismatch in Build.java and actual device properties.
(For example, the value of Build.DEVICE on a Raven device running
an AOSP build would be 'aosp_raven', but KeyMint was provisioned
with the value 'raven'.)
To fix above issue, properties ro.product.*_for_attestation were
introduced in AOSP build files (eg. aosp_raven.mk) only. But this
was not sufficient for both AOSP and GSI. The same solution does
not work for GSI images: GSI images are generic and so we cannot
set device-specific properties in them.
So, if ro.product.*_for_attestation properties are empty or unknown,
they are read from ro.product.vendor because these values are not
changed after flashing GSI images also. This fix will work for
both AOSP and GSI images. Device ID properties preferences for
eg. Build.BRAND_FOR_ATTESTATION = ro.product.brand_for_attestation ->
ro.product.vendor.brand -> UNKNOWN.
Bug: 268294752
Bug: 110779648
Bug: 259376922
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/0_android_hardware_security_keymint_IKeyMintDevice_default
Test: atest VtsAidlKeyMintTargetTest:PerInstance/NewKeyGenerationTest#EcdsaAttestationIdTags/1_android_hardware_security_keymint_IKeyMintDevice_strongbox
Test: atest CtsKeystoreTestCases:android.keystore.cts.KeyAttestationTest CtsKeystoreTestCases:DeviceOwnerKeyManagementTest
Change-Id: I574eca430cd2022cb9c270ca23ad33f6e5423cd4
API council has requested that the recently added BroadcastOptions
APIs be modified to better match API guidelines.
Bug: 267646347
Test: treehugger
Change-Id: I7e4e649b6fc46212fbfad53b32cbcee1b5a2efa7
API council has requested that the recently added BroadcastOptions
APIs be modified to better match API guidelines.
Bug: 267646347
Test: treehugger
Change-Id: Ia466a1a3428fa25b6e677bbf29bad0c74e469f54
Merged-In: I28456b5f1e155cef1e8fc3f4f9f500c9d8dc26f4
This allows moving the droidstubs modules into a subdir of
frameworks base. The paths would otherwise fail to resolve when
doing so.
Bug: 271563074
Test: m
Change-Id: I3472b37d8f4739d5018d9bb36b06f03b84f99e9a
These don't need to be defined in the top level Android.bp. Move
them into the directory where the files live.
Bug: 271563074
Test: m
Change-Id: I104374e49ba62de50016aa4a22173d5dbd00c257
The new interface is used for system components and 3rd party apps
to monitor carrier config changes, replacing the current carrier config
change broadcast receivers which has known performance issue.
Bug: 244087782
Test: atest CarrierConfigManagerTest
Merged-In: I782e3aa2312886279cc7f449fa3a8238b4115407
Change-Id: I782e3aa2312886279cc7f449fa3a8238b4115407
(cherry picked from commit c5e36e1c1f83cc130a96498f3117090065fa0531)
The feature only applies to non-DDS. If enabled, we automatically switch to the non-DDS for data traffic when it has better availability than the DDS.
Test: cts
Bug: 244064524
Merged-In: Id827b3e253b637273504d87c8db64893c7b70924
Change-Id: Id827b3e253b637273504d87c8db64893c7b70924
Current CarrierConfigManager APIs only allow to retrieve
ALL supported carrier configs at once. It may be as many
as hundreds of keys/values in one bundle which is not only
slow but also consumes unnecessarily more resources.
Clients study shows that the majority of the clients actually
only care about one or few of carrier configs.
The new APIs allow clients to specify a single or
multiple configs they care about. The performance profiling
shows that it is not only much faster but also consumes much
less resources.
Bug: 244087782
Test: atest CarrierConfigManagerTest
Change-Id: I436b9ad1d7e928d628c0103144cd345e8c4c4e3c
Merged-In: I436b9ad1d7e928d628c0103144cd345e8c4c4e3c
(cherry picked from commit 365825e2c587d7c6a8e324a90a022f94b5ab2aeb)
This intent was never exposed as a proper API and the developer should
use a TelecomManager API instead.
Test: Make/run cts/unit tests
Fixes: 148361587
Change-Id: I058490ceed809d3e4c0d32b300463fffed1a2dac
Currently, API text file does not include type parameter list for
constructor item. This change reformats the api text file to include the
missing type parameter list, with respect to the change in the behavior
of metalava.
Test: m update-api
Bug: 269135125
Change-Id: I46d364291615eabe071eab2dfc28796448f3139e
Read batteryStateOfHealth from HealthData with access control
Bug: 251427118
Test: m update-api ; m
Change-Id: Ida87ef9f59c32cf52b036f37c7c261d03d3b4c37
Signed-off-by: AleX Pelosi <apelosi@google.com>
These are going to be public:
- Battery state of health
- Battery cycle count
- Charging status
These are going to be system API
- BATTERY_PROPERTY_MANUFACTURING_DATE
- BATTERY_PROPERTY_FIRST_USAGE_DATE
- BATTERY_PROPERTY_CHARGING_POLICY
Bug: 251427118
Test: m
Change-Id: If74b96d7657611934d293df8376296e373ec9b35
Signed-off-by: AleX Pelosi <apelosi@google.com>
Signed-off-by: Jack Wu <wjack@google.com>
