Historically, we havent held a lock on ForceClearCache and
ClearCacheIfNecessary. This is not thread safe because kAllPullAtomInfo
must be accessed in a lock, especially now that pullers can be
registered/unregistered.
Test: atest statsd_test, wrote a repro cl.
Bug: 168156854
Bug: 173552790
Change-Id: I47d53a6d9d274bca4c78dbfd87e0097091b7b8cb
Merged-In: I47d53a6d9d274bca4c78dbfd87e0097091b7b8cb
(cherry picked from commit f9a4bb18ff)
As per requested in b/176940932#comment3 and b/156260178#comment32,
extending the valid font size scale range to [0.25, 5].
Existing CTS tests still pass.
BUG: 156260178
Test: atest android.provider.cts.settings.Settings_SystemTest
Test: atest android.app.cts.ApplicationTest
Change-Id: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
(cherry picked from commit df8852a0b5)
Merged-In: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
As per requested in b/176940932#comment3 and b/156260178#comment32,
extending the valid font size scale range to [0.25, 5].
Existing CTS tests still pass.
BUG: 156260178
Test: atest android.provider.cts.settings.Settings_SystemTest
Test: atest android.app.cts.ApplicationTest
Change-Id: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
(cherry picked from commit df8852a0b5)
Merged-In: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
As per requested in b/176940932#comment3 and b/156260178#comment32,
extending the valid font size scale range to [0.25, 5].
Existing CTS tests still pass.
BUG: 156260178
Test: atest android.provider.cts.settings.Settings_SystemTest
Test: atest android.app.cts.ApplicationTest
Change-Id: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
(cherry picked from commit df8852a0b5)
Merged-In: Icff82d727d63da4353342b0f9a5ca3c2ae1671c1
mUidFieldIndex, mExclusiveStateFieldIndex,
mAttributionChain{Start|End}Index are stored using int8_t.
These values can overflow when mValues.size() exceeds INT8_MAX.
Add proper bounds checking to ensure these values don't exceed
INT8_MAX.
Bug: 174488848
Bug: 174485572
Test: m
Test: statsd_test
Test: TreeHugger
Change-Id: I416e2de06ca2935017e15d4e91000652831e6b6c
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
Auto verification of app links requires that an intent filter declare
action=VIEW, scheme=HTTP(S), category=BROWSABLE. However,
PackageManagerService was not taking that into account, missing the
category requirement.
But the app info Settings UI did take category into account, so it was
possible for a user to set an application to automatically open web URIs
without understanding that this also granted domains that were not
visible in the app info UI.
To resolve both this, this change makes it so that both auto
verification and the Settings state can only consider the app as
"always" open only if the Intent contains both BROWSABLE and DEFAULT.
Bug: 175139501
Bug: 175319005
Test: manual, see bug for reproduction steps
Merged-In: Ib957258735893bf2779bed19bd400c6726ee6478
Change-Id: Ib957258735893bf2779bed19bd400c6726ee6478
(cherry picked from commit 4266f938c6)
In Androird 10 access to device identifiers was limited to apps with
the READ_PRIVILEGED_PHONE_STATE permission, carrier privileges, the
READ_DEVICE_IDENTIFIERS appop set to allow, or those that pass a
device / profile owner check. TelephonyManager#getSimSerialNumber
was guarded behind these new access requirements, but the same value
is still accessible as the cardString from the SubscriptionInfo.
While getCardString is a hidden API SubscriptionInfo#toString can
be used to obtain this value.
Bug: 152057778
Bug: 173421434
Test: atest SubscriptionControllerTest
Change-Id: I9b8786a321b1ba79d81b74c3041589f30df8e9c8
Merged-In: I9b8786a321b1ba79d81b74c3041589f30df8e9c8
In Android 10 access to device identifiers was moved from a runtime
permission to the privileged READ_PRIVILEGED_PHONE_STATE permission.
One of the non-resettable identifiers missed was SubscriptionInfo#
getIccId. The contacts provider currently uses this ID to upgrade
to version 1003 of the database; to ensure there are no issues with
this upgrade this permission is being whitelisted for the contacts
provider.
Bug: 131909991
Bug: 173421434
Test: atest ContactsProviderTests
Change-Id: I7574f787a7e55aa0337237b9fe916ee143a2f697
Merged-In: I7574f787a7e55aa0337237b9fe916ee143a2f697
In Android 10 access to device identifiers was limited to apps with
the READ_PRIVILEGED_PHONE_STATE permission, carrier privileges, the
READ_DEVICE_IDENTIFIERS appop set to allow, or those that pass a
device / profile owner check. TelephonyManager#getSimSerialNumber
was guarded behind these new access requirements, but the same value
is still accessible via SubscriptionInfo#getIccId. This change
updates the documentation to reflect that the getIccId will no
longer be accessible if the caller does not meet the new access
requirements.
Bug: 131909991
Bug: 173421434
Test: Builds
Change-Id: I03072c65e1c7101538a7a20541d2ac59a2d213e3
Merged-In: I03072c65e1c7101538a7a20541d2ac59a2d213e3
