| Age | Commit message (Collapse) | Author |
|---|
|
Add an overloaded version of Context.sendBroadcastMultiplePermissions() that can
specify BroadcastOptions, it is called by com.android.bluetooth package.
Bug: 182816627
Test: atest AdapterServiceTest
Test: atest AvrcpControllerStateMachineTest
Test: atest BondStateMachineTest
Test: atest MapClientStateMachineTest
Test: atest RemoteDevicesTest
Change-Id: I8bb2d2ed98ece70ebbe9d3a1b549b966d690de4f
|
|
Besides UI contexts, the context created via
Context#createConfigurationContext with a proper configuration
should be allowed to inflate views or obtain ViewConfiguration.
An example is that a wear device inflate views into bitmap and pass
the bitmap to the Wear OS Companion app on the phone.
Bug: 177847640
Test: atest StrictModeTest
Change-Id: Iab232a80a973f54bf0484262d45af3e4c2f0e5dc
|
|
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
|
|
am: c9e394fc27 am: 796c878352
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1491876
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: If4d6e07f92301baae6056d0891bc292cbd67450f
|
|
Bug: 177223402
Test: atest FrameworksCoreTests:ContextTest
Test: atest CtsContentTestCases:ContextTest
Change-Id: Ic85419934cf2c9df4e0f9cc287585b3296cec819
|
|
Bug: 175416931
Test: atest SplitScreenTests WMShellUnitTests
Change-Id: Id11bfef19076840e46222014e268a553bd94f2ef
|
|
|
|
Test: atest ContextIsUiContextTest ContextGetDisplayTest
Test: atest WindowContextPolicyTests
Bug: 174640742
Change-Id: I13bd07fa3a4e79fe44bce34157ee93622cbb431d
|
|
6740333528 am: 6dcc5fda31
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1530860
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: I1a5efe9503ad297cec89add2df79245a1c3264b2
|
|
Test: manual
Bug: 174932174
Change-Id: I47b7e9cee86986dfcbbb03e0d9b5abc8fa84bc2e
|
|
531ac1780d am: 053510307c
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1529960
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: I2ea01b34a52fc86fe0ebd8b9abb9b1d3cea83acf
|
|
Previously, this package was set to no owners.
However, it broke the new owner rule on gerrit.
See https://gerrit.googlesource.com/plugins/code-owners/+/master/resources/Documentation/how-to-use.md#no-code-owners-found
for details.
Test: manual
Bug: 174932174
Change-Id: I6bd2c3947cffdf7637b4c06dfb54d1b39b81e40e
|
|
dfbbd0e5d7
Original change: https://android-review.googlesource.com/c/platform/frameworks/base/+/1527819
MUST ONLY BE SUBMITTED BY AUTOMERGER
Change-Id: I0b99215f99e165cbfc0ee925878d291746d94163
|
|
Test: manual
Bug: 174932174
Change-Id: Id6a4c60734f24a3d8fdec27b11baead550296441
|
|
This CL is basically identical to http://ag/10353234, which
did the same with the sister method, "canonicalize".
Fixes: b/147705670
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: Ide93850f225cdd61779a62fc2c4666efe438b536
|
|
The java_sdk_library modules are now added with 'default_to_stubs: true'
so that their impl libraries are not used even when the clients don't
have sdk_version property set.
This will allow us to replace the direct references to the stub
libraries of the java_sdk_library modules with the references to the
modules themselves (e.g. android.test.base.stubs -> android.test.base)
in many of the CTS tests without unintentionally exposing the private
APIs in the impl lib.
As part of the change, MockContentProvider.getIContentProviderBinder()
now returns an anonymous Binder object instead of throwing an exception.
This is to eliminate the need for clients to override the now
inaccessible method to escape from the exception.
Also, InstrumentationTestRunner.addTestListener method is added to the
stub because it is used by several tests (MtpServiceTests, etc.)
Exempt-From-Owner-Approval: cherry-pick from master
Bug: 157007292
Test: m
Merged-In: I14cf217f21fd3534c920c3a6336cf2d14c02e60c
(cherry picked from commit b4e458d1063a3ece9a7f539ed6dbaeb6fb9c495d)
Change-Id: I14cf217f21fd3534c920c3a6336cf2d14c02e60c
|
|
The java_sdk_library modules are now added with 'default_to_stubs: true'
so that their impl libraries are not used even when the clients don't
have sdk_version property set.
This will allow us to replace the direct references to the stub
libraries of the java_sdk_library modules with the references to the
modules themselves (e.g. android.test.base.stubs -> android.test.base)
in many of the CTS tests without unintentionally exposing the private
APIs in the impl lib.
As part of the change, MockContentProvider.getIContentProviderBinder()
now returns an anonymous Binder object instead of throwing an exception.
This is to eliminate the need for clients to override the now
inaccessible method to escape from the exception.
Also, InstrumentationTestRunner.addTestListener method is added to the
stub because it is used by several tests (MtpServiceTests, etc.)
Bug: 157007292
Test: m
Change-Id: I14cf217f21fd3534c920c3a6336cf2d14c02e60c
|
|
Before, the documentation said that the passed context is an application context, which is incorrect to get the density, window metrics, and window manager. We should use visual context to get these instead.
Bug: 151474461
Test: StrictModeTest#testIncorrectContextUse_GetViewConfiguration
Change-Id: Iea28d727cafbb3ec8536742c6a0e594f73fe5a51
|
|
Starting in R, there is a new public API overload that delivers a
flags argument. Some apps may be relying on a previous hidden API
that delivered a userId argument, and this change is used to control
delivery of the new flags argument in its place.
There are dozens of these hidden API users are in the system UID,
either in the system process or the Settings app, so we hard-code
giving them the legacy behavior, since refactoring would be messy
between internal and AOSP branches.
Also adjust incoming and outgoing method signatures to use slightly
more flexible Collection<Uri>, which has handy methods like
contains() and isEmpty().
Bug: 150939131
Test: atest --test-mapping packages/providers/MediaProvider
Test: atest FrameworksServicesTests:com.android.server.devicepolicy.DevicePolicyManagerTest
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: If6a77449e19215cf1c60d4217e62fc04b0959bfc
|
|
with appOp as String and options as Bundle
Bug: 139077993
Bug: 146423958
Test: Build
Change-Id: I5325e08d60016741139251813a5df9b42f2efc82
Merged-In: I5325e08d60016741139251813a5df9b42f2efc82
|
|
|
|
Make obtaining a visual service from non-visual Context instance
report a strict mode violation and print the stacktrace.
Make calling getDisplay() throw an exception if called on an instance
that is not associated with a display. For existing usages introduce
a new internal method that does not perform the verification until
the usages are properly fixed.
Bug: 128338354
Test: StrictModeTest#testIncorrectContextUse_GetSystemService
Test: StrictModeTest#testIncorrectContextUse_GetDisplay
Change-Id: Id25d590eca6e10066e55d7ed6436d3bc9e433beb
|
|
Fixes: b/147699082
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I2e851839a454ad5eabc981c76774d03b57a1aa09
|
|
SystemTextClassifier that is backed by ExtServices
1. The default textclassifier is always provided by
config_servicesExtensionPackage (i.e. ExtServices)
2. OEM can specify a system text classifier by specifying
config_defaultTextClassifierPackage.
3. System text classifiers can get an instance of the default textclassifier
by calling TCS.getDefaultTextClassifierImplementation(), so that
they can add their customization on top of the default TCS.
4. If config_systemTextClassifierPackage is set, the specified package
is used to process requests from apps and the platform. Otherwise,
the default textclassifier is used.
5. For testing and droidfooding purpose, text classifier service package
can be overridden. If the overridden package is neither
the default one nor the system one, the package is considered as a
untrusted text classifier, which can only see requests from itself.
Test: m mts && mts-tradefed run mts-extservices
Test: Not setting config_defaultTextClassifierPackage. Select some text and
make sure smart selection works. Run dumpsys textclassification
to make sure the default TCS is bound.
Test: Setting config_defaultTextClassifierPackage and repeat the above.
Make sure the specified OEM text classifier is used.
Test: Set the service override config to be ExtServices.
Run dumpsys textclassification to make sure everything is unbound.
Select some text and make sure ExtServices is bound.
Test: Set the service override to be AiAi and repeat the above.
Test: Set the service to be something invalid and repeat the above.
Observe that no TC is bound and fallback to NO_OP.
BUG: 148049185
Change-Id: Ia2fb549fda49363e0d0ebc4b7e0d31cb76e11ee0
Make TCS.getDefaultTextClassifierImplementation returns a ...
SystemTextClassifier that is backed by ExtServices
1. The default textclassifier is always provided by
config_servicesExtensionPackage (i.e. ExtServices)
2. OEM can specify a system text classifier by specifying
config_defaultTextClassifierPackage.
3. System text classifiers can get an instance of the default textclassifier
by calling TCS.getDefaultTextClassifierImplementation(), so that
they can add their customization on top of the default TCS.
4. If config_systemTextClassifierPackage is set, the specified package
is used to process requests from apps and the platform. Otherwise,
the default textclassifier is used.
5. For testing and droidfooding purpose, text classifier service package
can be overridden. If the overridden package is neither
the default one nor the system one, the package is considered as a
untrusted text classifier, which can only see requests from itself.
Test: m mts && mts-tradefed run mts-extservices
Test: Not setting config_defaultTextClassifierPackage. Select some text and
make sure smart selection works. Run dumpsys textclassification
to make sure the default TCS is bound.
Test: Setting config_defaultTextClassifierPackage and repeat the above.
Make sure the specified OEM text classifier is used.
Test: Set the service override config to be ExtServices.
Run dumpsys textclassification to make sure everything is unbound.
Select some text and make sure ExtServices is bound.
Test: Set the service override to be AiAi and repeat the above.
Test: Set the service to be something invalid and repeat the above.
Observe that no TC is bound and fallback to NO_OP.
BUG: 148049185
Change-Id: Ia2fb549fda49363e0d0ebc4b7e0d31cb76e11ee0
|
|
* changes:
Exempt-From-Owner-Approval: Fix usages of WindowManager.getDefaultDisplay() in f/b
Add bundle options to Context#createWindowContext API
|
|
Add Bundle parameter to createWindowContext method to allow
passing window-related options.
Bug: 128338354
Test: Build, auto test
Change-Id: I19cf9335068ecf94c9d94a99be0e8f1021f78e34
|
|
Fixes: b/147646960
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I04c15ac008fe14b215f954af150226dc94f22232
|
|
Test: atest WmTests CtsWindowManagerDeviceTestCases
Bug: 128338354
Change-Id: I9c9dfc5e7f4edd4c968e60d2ffcbb19b5c72a853
|
|
Context.getCrateDir() creates and returns the File for the
root of the crates for the application context. Any child directories
under the crates root in Context.getDataFile() is called
the crate directory.
For example:
/data/user/0/com.exmaple.app/crates/IAmCratedFolder/decentFiles
/data/user/0/com.exmaple.app/crates/IAmCratedFolder/decentDirs
Context.getCrateDir return the crate dir
--> /data/user/0/com.exmaple.app/crates/IAmCratedFolder
The crate dir
--> IAmCratedFolder
The decent directories or files are not crated folders
--> decentFiles, decentDirs
Test: atest CtsOsTestCases:android.os.storage.cts.StorageCrateTest
Bug: 141660526
Change-Id: If3ec1e121fb8f72bab5571d6190378e3ae208832
|
|
with appOp as String and options as Bundle
Bug: 139077993
Test: Build, GsmInboundSmsHandlerTest, CdmaInboundSmsHandlerTest and WapPushOverSmsTest
Change-Id: I60e21c7202d1bc7c5d28dfad2e2edde902f28a15
|
|
A few releases ago we added ContentResolver.QUERY_ARG_* constants
to query() as a new best-practice that will help wean us off raw
SQL arguments. (For example, a provider could add their own
custom arguments like QUERY_ARG_INCLUDE_PENDING to cause the query
to reveal pending items that would otherwise be hidden.) This
change expands update() and delete() to accept those arguments.
This change also expand insert() to accept extras too, as part of
preparing to support an upcoming MediaProvider feature that will let
apps place new media "adjacent" to an existing media item. (Sending
that adjacent item through extras is cleaner than trying to send it
through escaped query parameters.)
Bug: 131643582
Test: atest CtsContentTestCases
Change-Id: I436296155b9b5f371b4cbe661feaf42070285fcc
|
|
MediaProvider makes heavy use of Uri change notifications, which
currently need to be delivered one at a time through the Binder
interface. To optimize this, allow callers to provide a collection
of multiple Uris to notify with a single Binder call.
Bug: 134170767
Test: atest cts/tests/tests/content/src/android/content/cts/ContentResolverTest.java
Change-Id: Ifef778e88bb772b5580f70929c6f2e9c166d1c0e
|
|
Bug: 141193711
Test: make
Change-Id: Ie692d2ac27474b9fe11f5548bc504aa00c5ad53c
|
|
Bug: 143100231
Test: atest ContextTest#testSendOrderedBroadcastWithAppOp
atest ContextTest#testSendOrderedBroadcastWithAppOp_NotGranted
Change-Id: Ia75d0db11f337769eaf3cf5436e09a7d38b0564c
|
|
This takes the Context#getFeatureId from the calling context and pipes
it all way through to the noteOp calls done by the content provider.
Bug: 136595429
Test: atest CtsAppOpsTestCases (new test added to capture this case)
TelecomUnitTests:CallLogManagerTest
ContentProviderClientTest
TelecomUnitTests:MissedCallNotifierImplTest
TelecomUnitTests:BasicCallTests
MediaInserterTest
PreferencesHelperTest
RankingHelperTest
PinnedSliceStateTest
FrameworksCoreTests:ContentResolverTest
Change-Id: I53b1035626229c920b353509a5bece157b52fb51
|
|
Bug: 142472686
Test: atest android.content.cts.ContextTest#testCreateContextAsUser
Change-Id: Id2e3d5ffe5887a4916e0872a7e85d62cbb439744
|
|
Without it, apps (mainline modules) will need to use createPackageContext...,
which is a bit painful.
Bug: 142472686
Test: atest android.content.cts.ContextTest#testCreateContextAsUser
Change-Id: Id640e03862462724df1a4a3101f0b08faafba22f
|
|
The new MediaProvider design has an internal dynamic security model
based on the value stored in OWNER_PACKAGE_NAME, so the OS always
needs to consult the provider when resolving Uri permission grants.
Blocking calls from the system process like this are typically
discouraged, but this is the best we can do with the limited time
left, and there is existing precident with getType().
For now, use "forceUriPermissions" as a proxy for determining when
we need to consult the provider directly.
Bug: 115619667
Test: atest --test-mapping packages/providers/MediaProvider
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I1d54feeec93fbb4cf5ff55240ef4eae3a35ed068
|
|
This change adds a mechanism for restricting permissions (only runtime
for now), so that an app cannot hold the permission if it is not white
listed. The whitelisting can happen at install or at any later point.
There are three whitelists: system: OS managed with default grants
and role holders being on it; upgrade: only OS puts on this list
apps when upgrading from a pre to post restriction permission database
version and OS and installer on record can remove; installer: only
the installer on record can add and remove (and the system of course).
Added a permission policy service that sits on top of permissions
and app ops and is responsible to sync between permissions and app
ops when there is an interdependecy in any direction.
Added versioning to the runtime permissions database to allow operations
that need to be done once on upgrade such as adding all permissions held
by apps pre upgrade to the upgrade whitelist if the new permisison version
inctroduces a new restricted permission. The upgrade logic is in the
permission controller and we will eventually put the default grants there.
NOTE: This change is reacting to a VP feedback for how we would handle
SMS/CallLog restriction as we pivoted from role based approach to roles
for things the user would understand plus whitelist for everything else.
This would also help us roll out softly the storage permisison as there
is too much churm coming from developer feedback.
Exempt-From-Owner-Approval: trivial change due to APi adjustment
Test: atest CtsAppSecurityHostTestCases:android.appsecurity.cts.PermissionsHostTest
Test: atest CtsPermissionTestCases
Test: atest CtsPermission2TestCases
Test: atest RoleManagerTestCases
bug:124769181
Change-Id: Ic48e3c728387ecf02f89d517ba1fe785ab9c75fd
|
|
Allow app to control the thread where ServiceConnection methods are
called on.
Bug: 111434506
Test: Used new bindContext method in chrome and checked callbacks
are on the correct thread.
Change-Id: I480e5bd6773a530fb9e8e73e3a2a2a88b76569ec
|
|
Bug: 120879205
Test: manual
Test: atest cts/tests/tests/database/src/android/database/cts/AbstractCursorTest.java
Change-Id: If3be228dc6b08ea58d24c9209822f9d8c2348082
|
|
Entries from DownloadProvider are added to MediaStore Downloads
collection. COLUMN_MEDIASTORE_URI will be used to track corresponding
entries in MediaProvider. We can't re-use COLUMN_MEDIAPROVIDER_URI
for this purpose because it is updateable by apps.
Bug: 120876251
Test: atest DownloadProviderTests
Test: atest cts/tests/app/src/android/app/cts/DownloadManagerTest.java
Test: atest MediaProviderTests
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: Ifd252c54f4ee739a31be2866896efac6696a088e
|
|
This change adds RollbackManagerService as a new system service for
managing apk level rollbacks.
To work properly this requires additional selinux policy changes. Fails
gracefully in case of selinux denials, until we have a chance to sort
out the proper selinux policy.
Bug: 112431924
Bug: 116512606
Test: atest RollbackTest, with selinux enforcement off.
Test: atest CtsPermission2TestCases:PermissionPolicyTest
Change-Id: Id72aae9c4d8da9aaab3922ec9233ba335bc0198f
|
|
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
|
|
This will allow apps to better manage many isolated processes,
telling the system how they are grouped together (so should be
managed as one related entity within the LRU cache) and fine-tune
the ordering within that group.
The API is not yet tested... though in theory it is implemented.
But the implementation done for that also fixes a *lot* of problems
with activity LRU management that, even without groups, should
make the ordering of processes in the LRU list much more consistently
match how recently the user has interacted with it.
Also clean up some of the new dumpsys output in the activity manager:
move the new sections to before the process output (so it is still
easy to see the process state at the end of the output), and add and
document the command line options for controlling them. And add a
new "lru" section that gives a clear view of what is going on with
the raw LRU list.
An upcoming change will add tests for the new grouping functionality,
and probably some fixes resulting from that.
Test: atest CtsAppTestCases:ServiceTest
Bug: 111434506
Change-Id: I1f6b6b9de66ccde1573e1a0e9615e8c5f8e6c0d7
|
|
This allows clients to run multiple instances of the same
manifest service declaration. It only works for isolated
services, to avoid too much abuse temptation. This is part
of the "Chrome site isolation" work, to allow chrome to have
many more render processes running and help it manage them.
Bug: 111434506
Test: atest CtsAppTestCases:ServiceTest
Change-Id: I22e65758678a07075ed32ed6463082ddf846d3a4
|
|
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992694e471ddaae73f9a30977db9cdb75
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
|
|
This splits the
- review permissions
- individually control permissions
- consent to manage wireleess (wifi + bluetooth)
properties.
Almost all code cares only for the first and it is now always true.
Hence a lot of code can be simplified.
Bug: 110431654
Test: atest PermissionsHostTest
started pre-M app
Change-Id: I733cd476ccd0bf5eaa59e9a9506db34f57c6baee
|
|
Incoming and outgoing call phone numbers are visible in the phone state
broadcast and via the PhoneStateListener. To enhance user privacy, change
to require the READ_CALL_LOG permission in order to receive the call
phone numbers.
This means to see phone numbers:
1. android.intent.action.PHONE_STATE - requires READ_PHONE_STATE and
READ_CALL_LOG permission.
2. PhoneStateListener#onCallStateChanged - now required READ_CALL_LOG
permission.
To support this new behavior, added sendBroadcastAsUserMultiplePermissions
method to context to allow sending the broadcast to all users while
requiring the two permissions.
Bug: 78650469
Test: Created PHONE_STATE broadcast receiver in test app and verified that
when no permissions are granted, the phone number is empty for incoming
and outgoing calls.
Test: Granted Phone state permission to test app and verified that phone
number is not populated.
Test: Granted test app read call log permission and verified that phone
number is populated.
Test: Created PhoneStateListener in test app and verified that when no
permissions are granted, phone number is empty for incoming and outgoing.
calls.
Test: Granted read call log permission to test app and verified that both
the incoming and outgoing numbers are populated.
Change-Id: I857ea00cc58a0abbb77960643f361dd6dd9c8b56
|
|
|
