You could squint at raw Binder transactions to try detecting calls
like these, but there are several ContentProviders inside the OS
that either call into themselves, or call into providers within the
same process, which means it's more difficult to triage slow calls
without explicit visibility.
Bug: 112080089
Test: manual
Change-Id: I4e1e026f2bdc43d179c796d892e84af6da559f3a
These sharedUserIds will be used as filenames and ext4 filesystem
has a limitation of 255 bytes on the filename length. This is the
same limit we currently use for the package names.
Bug: 111890351
Test: device boots
Change-Id: I22ca607cf4243887bd47e7803ae77a3af903da78
* changes:
Split PackageInstaller app into installation and permissions management
Copy package installer into framework/base/packages/PackageInstaller
For creating the package sandboxes, vold needs app ids and
sandbox ids for all available packages on the device.
Bug: 111890351
Test: n/a
Change-Id: Icafd27e2663f11deeb11d46592ef8f1c653dbc4f
The two components were mostly independant for a long time. Since
I1e80a3f5e63d02b3859ecf74af21ca4c61f96874 the installation flow does
not grant any permissions anymore and the last connection between these
parts was broken.
The new app "com.android.packageinstaller" in
frameworks/base/packages/PackageInstaller will only handle (side load)
package installtion and uninstallation.
The exisiting app will be renamed to "com.android.permissioncontroller"
and only handle permission granting and permission management.
This change does only minimal cleanup cleanup. In particularly it does
not move any files in the old permissions controller. This is to not
disturb other features currently in development.
This change set also updates the make files to install the two apps on
the appropriate devices.
Further the permisson policy xmls need to be updated to point to the
right packages.
Test: Installed + uninstalled packages
Granted permissions + managed permissions
GtsPackageInstallTestCases
GtsNoPermissionTestCases
GtsNoPermissionTestCases25
GtsPackageInstallerTapjackingTestCases
GtsPackageUninstallTestCases
Change-Id: I2d3796b837fc0049e712c82a990907f305c8febf
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
Allows for other services like window manager to call uri grants without
holding AM service lock.
Bug: 80414790
Test: Existing tests pass.
Change-Id: Ie5b4ddb19a2cedff09332dbeb56bcd9292fd18ac
The old name never really made sense. Now that installations get
confirmed on first start of the app, the old name doesn't make sense at
all anymore.
Test: Installed app via PackageInstallSession (gts-tradefed run
commandAndExit gts-dev -m GtsPackageInstallTestCases)
Change-Id: I3701d34068e2c30002a3b1dddf4aacead8bafaa2
Developers often accept selection clauses from untrusted code, and
SQLiteQueryBuilder already supports a "strict" mode to help catch
SQL injection attacks. This change extends the builder to support
update() and delete() calls, so that we can help secure those
selection clauses too.
Extend it to support selection arguments being provided when
appending appendWhere() clauses, meaning developers no longer need
to manually track their local selection arguments along with
remote arguments.
Extend it to support newer ContentProvider.query() variant that
accepts "Bundle queryArgs", and have all query() callers flow
through that common code path. (This paves the way for a future
CL that will offer to gracefully extract non-WHERE clauses that
callers have tried smashing into their selections.)
Updates ContentValues to internally use more efficient ArrayMap.
Bug: 111268862
Test: atest frameworks/base/core/tests/utiltests/src/com/android/internal/util/ArrayUtilsTest.java
Test: atest cts/tests/tests/database/src/android/database/sqlite/cts/SQLiteQueryBuilderTest.java
Change-Id: I60b6f69045766bb28d2f21a32c120ec8c383b917
For testing we often need to run shell commands. This can be done
today via running a shell command from an instrumentation test
started from the shell. However, this requires adding shell commands
which are not in the API contract, involve boilerplate code, require
string parsing, etc.
This change allows an instrumentation started from the shell to
adopt the shell UID permission state. As a result one can call APIs
protected by permissions normal apps cannot get by are granted to
the shell. This enables adding dedicated test APIs protected by
signatures permissions granted to the shell.
Test: cts-tradefed run cts-dev -m CtsUiAutomationTestCases
-t android.app.uiautomation.cts.UiAutomationTest#testAdoptShellPermissions
bug:80415658
Change-Id: I4bfd4b475225125512abf80ea98cd8fcacb6a1be
Combination of moving to existing public API, tagging things as
@TestApi, and bringing utility methods into tests.
Bug: 13282254
Test: atest cts/tests/tests/os/
Change-Id: Ifd24c0d048d200e8595e194890cc1dc53ddc2b3e
When an app starts becoming Direct Boot aware, it can be difficult
to track down all the places they're implicitly relying on
PackageManager filtering behavior.
For example, if the current Launcher isn't Direct Boot aware, we
hide it until the user is unlocked, which could confuse other Direct
Boot aware apps into thinking it had been uninstalled, which could
cause data loss.
This change helps apps track down places where they're implicitly
relying on the automatic filtering; they should instead carefully
choose a combination of MATCH_DIRECT_BOOT flags to decide on the
explicit matching behavior they want.
To implement this, we partially migrate the updateFlags() methods
out into ApplicationPackageManager, since the checking needs to
happen on the client side to correctly report StrictMode
violations. We don't currently mutate the flags, but we retain
the naming to keep that door open in the future.
Test: manual
Bug: 110413274
Change-Id: Iff6feba19da81ea1b4eeb3af821c3bdfbd9bf17c
This change is cherry-picked and rebased from AOSP
https://android-review.googlesource.com/c/platform/frameworks/base/+/660242
Add face recognition as an identification method, following fingerprint
design. Unlike fingerprint, only one face template can be enrolled per
user, and a vendor message is passed from the HAL all the way to the
client callback to allow GUI indication about the enrolled face
templates.
Add FaceAuthenticationManager and FaceService.
Add face authentication capability to TrustManager and Keyguard.
Modify TrustManager and KeyguardUpdateMonitorCallback fingerprint code
to support generic biometric method to eliminate duplications.
Add BiometricSourceType enum to keep track of the specific biometric
method.
Test: biometric authentication still works on the device
Fixes: 110385761
Change-Id: I5d04fe69a112c13d3ef7330b9c08c146e36c5335
Signed-off-by: Gilad Bretter <gilad.bretter@intel.com>
Applying this mechanism for system carrier apps to make visibility
reasonable from the user's perspective. In other words, before
hidden system apps have been installed, they wouldn't be listed
via APIs in PackageManager which are used at all apps list and
search in Settings and so on.
Test: atest CarrierAppUtilsTest
Test: atest PackageManagerTest
Test: cts DeviceOwnerTest
Test: gts ManagedProfileProvisioningHostsideTest
Bug: 74068582
Change-Id: I1f23aba589b98351a1871a44a3058b67c416f351
This is a do-nothing TimeZoneDetectorService that can be
populated in following commits. A temporary method has been
added so the service has one method.
Unit tests can be run with:
atest FrameworksServicesTests:TimeZoneDetectorServiceTest
Test: build / boot
Test: See above
Change-Id: I565fb5dd2f18b7aac2e5779d346bfe69e9da02af
Some permissions are getting split into foreground and background
variants. If an app only has the foreground version it can only access
the protected resource while the user is using it. Once the background
permission is added to the foreground permission the app can always
access the resource protected by the permission.
- Only having the background permission does grant anything.
- Mutliple foreground permission can share a single background permission,
but a foreground permission can not have multiple background
permissions.
- As the implementation of background permissions is based on AppOps
only the system can declare such foreground/background permissions
- A CTS test enforce that the background is in the same group as the
matching foreground permission.
Bug: 78788390
Test: Checked declared permission after boot and found new attributes
Change-Id: Ica7ba77b24345607c7467c41c982a58c39199024
If a package contains minSdkVersion="Q" targetSdkVersion="25",
targetCode will be initialized to "Q" when reading minCode,
but targetVers will be set to "25". targetCode overrides
targetVers, so this results in the computed targetSdkVersion
being "Q". If minSdkVersion were instead "28", the computed
targetSdkVersion would be "Q".
Make the computed targetSdkVersion consistent by leaving
targetCode and targetVers unset while parsing minSdkVersion,
and then setting them to minCode and minVers if there is
no targetSdkVersion attribute.
Bug: 110167203
Bug: 110353795
Test: install DeviceHealthChecks, verify targetSdk=25
Change-Id: I9547e9b4720543f0c892cbf4de92888c8eead44f
To allow an Errorprone warning to become an error.
Bug: 72451126
Test: m
Change-Id: I8733f0ee74de615e4ffc979fb9de38730c2506c6
Merged-In: Ia6856157e8813856268fba003e1e591d690cb26e
This change removes deprecated and unused Intent extra names that were
replaced in P with EXTRA_INSTANT* equivalents.
Change-Id: Idd57b9db5896eda24349d01c0d7557f2d4e820ea
Fixes: 72700831
Test: build succeeds and instant app launches with installer on system image
This makes the behavior of MATCH_ALL match the documentation by ignoring
all other match flags.
Change-Id: I8060cedd2144d0cdbc89d974f4d9f87b601d24e3
Fixes: 35176630
Test: disabled some components and ensured they are visible when querying with MATCH_ALL
This is a do-nothing TimeDetectorService that can be
populated in following commits. A temporary method has been
added so the service has one method.
Unit tests can be run with:
atest FrameworksServicesTests:TimeDetectorServiceTest
Test: build / boot
Test: See above
Merged-In: I9e4eac70b944441f34491315cd1ce7fa2b9ae150
Change-Id: I9e4eac70b944441f34491315cd1ce7fa2b9ae150
(cherry picked from commit feeee682a2)
Work on issue #109754053: Implement tri-state location in platform
- New background location permission
- New (temporary?) API level for compatibility with old apps
None of this is exposed yet as a public API, that will be
done in the future.
Bug: 109754053
Test: atest FrameworksServicesTests:AppOpsServiceTest
Test: atest CtsPermissionTestCases:AppOpsTest
Change-Id: I986dc871b9e8ed3bf592d2546eadaefb4fefe099
First step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the interfaces and service dealing
with activities and their containers (tasks, stack, display) from the
rest of AM interfaces and services. This will allow us to move the new
interfaces and services to WM when the internal states are cleaned-up.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Ide9b3f89123b768cdbd3e3878113c7a8021187f3
