PermissionMonitor check permission by each package name but only
update the uid permission to netd. It's better to check
permission by uid directly. Thus, use
ActivityManager#checkUidPermission to check permissions for each
uid.
Bug: 132784544
Test: atest FrameworksNetTests
Change-Id: I057d34383b4dc408b2773e4c6b146774ba0c5eb2
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
Avoid recording negative data by doing integer-based
math as much as possible, but switch to double-based
math if we detect that we'd end up causing an overflow.
Test :
- Builds, Boots
- High data throughput scenarios
- NetworkStatsHistoryTest, NetworkStatsCollectionTest,
NetworkStatsTest
Bug: 119527458
Change-Id: I55d4aa649bea3ae201ad513074ff2b71cb918dad
No change to logic, only docs. This removes non-inclusive terminology
("whitelist") from our API javadoc, with the exception of references to
setSafeBrowsingWhitelist() (which we plan to deprecate soon, in favor of
an inclusively named API).
This rephrases one paragraph to be a bit clearer as well.
Bug: 160928306
Test: m offline-sdk-docs -j4
Change-Id: If249be8a70b01c01390ebfeb418fd7c5e119f1f2
It's a situation that:
1) An app process is killed;
2) A new instance of this process is created right after it
3) The bindeDied handling happens after 2)
During 2), while creating the new ProcessRecord, the old ProcessRecord
will be removed and this makes the total num of processes in this
UidRecord to be 0, then the new ProcessRecord will bump that number
by 1, in the meanwhile the new ProcessRecord will be kept in the
process name map,
During 3), while doing the cleanup for old ProcessRecord, it tries to
remove itself from the process name map, which actually has the
new ProcessRecord, so the total num of processes in the UidRecord
will become 0.
Now the fix is to make sure we are cleaning up the right ProcessRecord,
so in step 3) we will see it's already cleaned, thus we won't mess up
with the UidRecord.
Bug: 161466248
Test: see b/161466248#comment17 for detailed test steps
Change-Id: I2685e3f0162098b9b95f6b248b67aeb498e50c8e
Inline APIs.
* limitations with multiple locales.
* limit on max number of suggestions.
* guidance on managing the order of inline suggestions when inflating.
Fixes: 161486684
Test: atest android.autofillservice.cts.inline
Change-Id: Ia560d48f95730d79bc340ff9eb0cf4a5909bf0d3
Delete libplatformprotos since its not used.
Test: m -j
Bug: 147599928
Merged-In: I80203756d714bf123978d26bbe81351a1abdc967
Change-Id: I80203756d714bf123978d26bbe81351a1abdc967
Update current.txt and removed.txt to be created with metalava.
Test: m android_uiautomator
Test: m uiautomator-stubs-docs
Test: m checkapi
Bug: 144248501
Bug: 143136634
Change-Id: Ie1c52530dd03a05e244ebfd47bf9acf4448c5794
This resource has moved to CarrierConfig to support dual
sim devices and MVNOs.
Bug: 148483577
Test: Manual
Merged-In: I494cb93a2c72ff3df2ef45ad737c5606132e32d1
Change-Id: I494cb93a2c72ff3df2ef45ad737c5606132e32d1
Sim based customizations should not be resources because
of two reasons:
1. The MCC/MNC value in AssetManager for Dual sim devices is undefined
2. There is no support for MVNOs.
For dual sim devices there is only one value for MCC/MNC in
AssetManager and that value is updated from multiple places without
deciding if it should be the default voice sim card, the default
data sim card or whatnot.
This means that when frameworks is trying to decide what resource
to use there is no guarantee that the resource that arrives is for
the particular subscription we are asking for.
MVNOs cannot be separated through only MCC/MNC but need more
parameters like service provider, imsi, GID1 etc. MVNO support
is available in CarrierConfig.
When we now have support for ADCP updates of customizations and
start using carrier id this is better placed in CarrierConfig,
we then get support for MVNOs at the same time.
Bug: 148483577
Test: Customize for sim card x and not for sim card y, insert both
sim cards in a dual sim device and see the difference.
Merged-In: I067d55b9ae5e1346dd3b3cd50a0097b05b100055
Change-Id: I067d55b9ae5e1346dd3b3cd50a0097b05b100055
Do not set referrerUri on SessionInfo for non-owners
This change leaves the referrerUri field null when the caller leading to
its production is not the owner of the session.
Bug: 142125338
Test: atest SessionReferrerUriTest
Change-Id: I84679ea0636aa2097e25e23813c48134c9cc1d75
Address API Council feedback for CellLocation#requestLocationUpdate
-Update the summary string to indicate the functionality
for pre-SDK31 behavior.
-Clarify that this API is only useful in power-saving modes.
-Remove justification for deprecation leaving a simple link to
a superior alternative.
Bug: 161207204
Test: make offline-sdk-docs && make (docstring only change)
Change-Id: Ib931906323fe1ec2c730271cefd0d46aee60d963
With the goal of reducing log spam, print only a summary 'Found stale
backup journal' messages instead of logging within the inner loop.
Previously, over 12k messages could be printed at a time from this
function.
Before this CL:
- a backup was scheduled for each packageName from each stale
journal
- one (or two, if MORE_DEBUG) message was logged for each
packageName in each journal file.
After this CL:
- packageNames are de-duplicated before scheduling backups or logging
(it's not clear to me whether duplicate packageNames previously
occurred, in practice).
- one message is logged for the number (if > 0) of stale journals.
- one message is logged for the number (including their names, if
MORE_DEBUG) of packages.
Bug: 161940947
Test: fewer 'Found state backup journal' messages printed
Merged-In: Ia1343e4cea31feb1eba9da561d20736eb5df0a14
Change-Id: Ia1343e4cea31feb1eba9da561d20736eb5df0a14
With the goal of reducing log spam, print only a summary 'Found stale
backup journal' messages instead of logging within the inner loop.
Previously, over 12k messages could be printed at a time from this
function.
Before this CL:
- a backup was scheduled for each packageName from each stale
journal
- one (or two, if MORE_DEBUG) message was logged for each
packageName in each journal file.
After this CL:
- packageNames are de-duplicated before scheduling backups or logging
(it's not clear to me whether duplicate packageNames previously
occurred, in practice).
- one message is logged for the number (if > 0) of stale journals.
- one message is logged for the number (including their names, if
MORE_DEBUG) of packages.
Bug: 161940947
Test: fewer 'Found state backup journal' messages printed
Merged-In: Ia1343e4cea31feb1eba9da561d20736eb5df0a14
Change-Id: Ia1343e4cea31feb1eba9da561d20736eb5df0a14
(cherry picked from commit 112e3c2d04)
