When device is provisioned, we delete all files from /data/preloads
except file_cache. We should do best effort to keep file_cache during
the first config_keepPreloadsMinDays. After that,
persist.sys.preloads.file_cache_expired is set to 1, which indicates
that cache can be deleted when additional storage space is requested.
Bug: 34690396
Test: Manual + RetailDemoModeServiceTest
Change-Id: Ie584a9dd6689bcc5e6b3cb448e95dfe5f73d2eeb
The real dexopt maintainance job is
com.android.server.pm.BackgroundDexOptService, and not
com.android.server.BackgroundDexOptJobService
Partial revert of commit 096d304ae3d85c1bfcda1a1d9cd4eb13d0815500.
Test: manual inspection
Bug: 36140426
Change-Id: I983ac91117f107282095fa7eefdbce08e0dcfce3
Exposing actions from the PIP InputConsumer to accessibility,
stripping all actions from a covered PIP app, and adding the
InputConsumer's actions on the PIP app's root view.
We were also using an "undefined" accessibility ID to mean
three different things: a root view, a host view of a virtual
view hierarchy, and a truly undefined view. I've introduced
new values for cases where the id could be defined.
Also gathering all window IDs into one place to reduce the
chance of collisions.
Bug: 34773134
Test: In progress. Current cts passes.
Change-Id: I97269741a292cf406272bf02359c76c396f84640
Add a priviledged permission NOTIFICATION_DURING_SETUP which together
with the existing Notification.EXTRA_ALLOW_DURING_SETUP will allow a
notification to be shown during setup.
Test: Added NotificationDataTest
Bug: 34705874
Change-Id: I7215acf4017ad897294c69abf63a7f2e5d556f31
This change will affects 2 types of apps: autofill service implementations
and apps that use autofill APIs.
Since just the former is known to be used at the moment, we're not trying
to keep backward compatibility with the latter.
Bug: 35956626
Test: CtsAutoFillServiceTestCases pass
Test: android.provider.SettingsBackupTest pass
Change-Id: Ia720083508716deae9e887f9faa7ae7c5a82f471
Non-system apps could send these, and accept OPP transfers without user
interaction.
Test: run POC code, see that it crashes instaed of accepting
Bug: 35258579
Change-Id: I37bf2e17b4d612258f9dbaa879727ac7c72e5969
The package verifier needs to be able to see Instant Apps in order to do
its job. It already sees them on first install so no new information
about what Instant Apps are installed is leaked.
Test: builds
Change-Id: I5d892b2d7aa820a9c0c00ac357f20a3210cf3395
This exposes an API to answer a ringing call, as well as a corresponding
runtime permission and appop
Test: Grant the permission and ensure the call gets answered.
Deny the permission, and ensure that the API call throws an exception.
Bug: 30932767
Change-Id: I4c33fcea6b95a30469fa6c0c37090be32b0ad52e
The Shell application needs access to change which overlays are
enabled in OverlayManagerService.
Test: Manual: invoke adb exec-out cmd overlay enable some.package.name
when shell is not root (adb unroot on eng builds).
Change-Id: I1849f68e244cfc9b1e13eb0e673dde7be03cba6d
Allows the user to associate alert windows with specific apps
and revoke the permission if they want.
Test: manual
Bug: 33256752
Change-Id: Ie28325b6bb799b3df253770ebe655f97ebbadd90
This currently integrates with installd, but not with
any framework API to expose this information to apps.
The first pass, as per the design doc, adds a service
which polls for large changes in the file system free space.
If enough spaces changes, it begins a recalculation of the
cache quotas and pipes the information down to installd.
This calculation is done in the updateable ExtServices.
Further enhancements in later patches include integrating this
to listen to package install and removal events, caching the
last computed quota values into an XML file on disk to load
on boot, and exposing the information to apps.
Bug: 33965858
Test: ExtServices unit test
Change-Id: Ie39f228b73532cb6ce2f98529f7c5df0839202ae
Companion apps can declare they want background access and
background execution exceptions via dedicated permissions
in their manifest. If such a permission is requested we
auto-grant the corresponding exception after the user has
chosen a device from the companion UI. These permissions
are appop ones allowing us to use the app ops for gauging
whether the user has made a change after we auto-granted
the permission since we would like to revoke these special
privileges when the app disassociates itself from the
companion device if the user did not make an excplicit
choice otherwise.
While at this auto-grant fixed location permission to the
companion device discovery service.
Test: manual
Change-Id: I46ee4291e5e5a8f7613f0dd75eb61d6b9341f306
Now that we're giving apps better guidance around how much cached
disk space they can use, we also need to provide a way to help clear
some of those cached files. The final logic is coming in a future
CL, but it will be designed to prevent abuse.
Test: newly added CTS tests
Bug: 34690590
Change-Id: I1e46ade0cdabbc33162fc7bfa76abec711992f92
Foreground services could potentially be abused to get around the
lifecycle requirements of Instant Apps, so limit that behavior with a
perission that will need to be granted by the installer.
Test: Manually verified
Change-Id: Ia162077971e914960ebdb8293a33faa8038ed850
This introduces an API for apps that support companion devices to provide a
more streamlined flow for pairing and setting up the device
Bug: 30932767
Test: Using a toy app, invoke the newly introduced API (CompanionDeviceManager),
and go through the flow. Ensure filtering works, and device is returned to
the calling app. Ensure the calling app can pair to the selected device.
Change-Id: I0aeb653afd65e4adead13ea9c7248ec20971b04a
This change adds APIs for instant apps to store cookie data
that is presisted across instant installs and across the
upgrade from an instant to a standard app. Standard apps
can use the cookie APIs but when they are uninstalled the
cookie is also deleted. The cookies are kept longer than
the instant apps as they are much smaller - 16KB by default.
We can change the cookie size via a system setting i.e.
after we ship we can increase size if needed.
We also add internal APIs to surface information about
installed and uninstalled instant apps which should be
used for showing them in the UI. For this puporse we store
the icon, permissions, and label of uninstalled apps. If
the app is re-installed we drop this meta-data but keep
the cookie around. If we have cookie data stored and the
signing cert of the app changes when it gets re-intalled
we wipe the cookie.
Test: CTS tests pass; hiddent APIs tested manually
Change-Id: If145c0440cc61a5303e2cbb70228d235d36037a5
Add a new system service to manage Runtime Resource Overlays. This will
offload the PackageManagerService and allow administration of overlay
packages while affected packages continue to execute.
Overlays can be enabled or disabled during runtime. Running applications
will re-create their ResourcesImpl objects and restart their activities
via the usual activity life cycle.
The order in which a set of overlays is loaded may also be changed
during runtime. The underlying mechanics are the same as for when an
overlay is enabled or disabled.
When an overlay changes state, e.g. becomes enabled, the
OverlayManagerService will broadcast one of the new intents
android.intent.action.OVERLAY_ADDED, *_CHANGED, *_REMOVED or
*.OVERLAYS_REORDERED.
Clients that wish to read information about overlays for users other
than themselves are required to hold the
android.permission.INTERACT_ACROSS_USERS_FULL permission. This mirrors
the protection level of PackageManager.getPackageInfo.
Clients that wish to change the information are required to
hold the permission android.permission.CHANGE_OVERLAY_PACKAGES.
Each pair of overlay package and corresponding target package is
respresented by a new OverlayInfo class. This class mirrors the
existing PackageInfo class.
Overlay packages are handled per Android user. The data is persisted in
/data/system/overlays.xml.
Co-authored-by: Martin Wallgren <martin.wallgren@sonymobile.com>
Signed-off-by: Zoran Jovanovic <zoran.jovanovic@sonymobile.com>
Bug: 31052947
Test: run tests from 'OMS: tests for OverlayManagerService'
Change-Id: I15325e173193df3240b8dc0a58c852fd7a3d5916
Some apps may want to check whether they are trusted to install apps on
the device, so they can prompt the user to go to settings and mark them
as trusted before they do an intensive operation like downloading an
apk.
Test: cts-tradefed run cts -m CtsExternalSourcesTestCases
Bug: 31002700
Change-Id: Icd9d04daa157e6733decba245ec251ce4acd4122
Adds support for dynamic ImsService Binding (change 1/3). Included
in this change:
- AIDLs for ImsServiceController
- ImsFeature/ImsServiceBase definitions
- KEY_CONFIG_IMS_PACKAGE_OVERRIDE CarrierConfig option
Test: Unit Tests in opt/telephony
Bug: 30290416
Change-Id: Ic4cb1d85a29681b08a6a525c588a72209862dcc3
The DevicePolicyManagerService currently supports delegation of
certificate installation and application restriction management, both
of which are individually handled by DPMS.
Upcoming framework features will add four more delegation types,
namely: block uninstall; app permission management; app access
management; and system app enabler. At this moment it makes sense to
refactor the underlying delegation system in DPMS so that current and
future delegates can be handled in a more generic way.
Bug: 33099995
Test: DPMS unit tests
Change-Id: I9e350143572c6690febdd59d1ed5149af8ee4388
If the media key listener is set, the listener will receive the media key
events before any other sessions, but after the global priority session.
If the event is handled by the listener, other sessions cannot get the event.
Privileged app needs permission android.permission.SET_MEDIA_KEY_LISTENER
to set the listener.
Bug: 30125811
Change-Id: I2b2cf4ac7873b70899194701c6921990dcb9de02
If the volume long-press listener is set, the listener will receive
the volume key long-presses instead of chaging the volume.
Privileged app needs permission
android.permission.SET_VOLUME_KEY_LONG_PRESS_LISTENER to set the listener.
Bug: 30125811
Change-Id: I5e8fafbb950e5e11522da0f14004648d0877bf3e
This change adds support for static shared libraries that
emulate static linking allowing apps that statically link
against the same library version to share a common
implementation. A library is hosed by a package in a standard
APK.
Static shared libraries have a name and a version declared
by a dedicated manifest tag. A client uses also a new tag
to refer to the static library it uses by specifying the
lib name, version, and the hash of the signing certificate.
This allows two apps to rely on two different library versions
and prevents impersonation of the shared library by a side-loaded
app with the same package name.
Internally apps providing static libs use synthetic package
name generated from the manifest package name and the library
version. This allows having different "versions" of the same
package installed at the same time.
An application cannot be installed if a static shared lib it
depends on is missing. A used shared library cannot be uninstalled.
Shared libraries can rotate certificates like normal apps. The
versions of these libs should be ordered similarly to the version
codes of the hosting package. Such libs cannot use shared user
id, cannot be ephemeral, cannot declare other libraries, cannot
rename their package, cannot declare child-packages. They must
target O SDK. Also they cannot be suspended or hidden or their
uninstall blocked. Generally, speaking policy regarding code in
static shared libs should be applied to the packages using the
library as it could have just statically linked the code.
We now have APIs to query information about the shared libraries
on the device in general. To clients static shared libraries are
presented as multiple versions of the same package which is how
they are declared and published. Therefore, one can have two
versions of the same package which means we need way to query
for and uninstall a specific version of a package. Also static
shared libs can depend on other static shared libs which are
versioned packages. To ease representation we add the concept
of a versioned package which should be used in the case of
static shared libs.
A client can see only the static shared libs it depends on and
more specifically only the versions it depends would be retrieved
by using the standard package manager APIs. There is a new
dedicated API to get info about all shared libraries which
would provide data about all static shared lib versions. Also
these libraries must use v2 signing scheme.
Test: CTS tests pass
bug:30974070
Change-Id: I4f3d537ee7a81f880950377b996e1d9d4813da5c
