Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Icc19b2fbc05f40dcf8c3fc4abf718c373dc8d4f6
When an ApplicationInfo object is updated and we want to update
code paths without restarting the app's process, we need to make
sure that we only update the paths that have changed. This means
diffing between the old paths and the new paths.
Test: watch /proc/<pid>/maps for dex entries before and after
running adb exec-out am update-appinfos all <package>
Change-Id: I6855d860478ade3184bbb578a5483d8548396daa
ag/1633903 added config_allow3rdPartyAppOnInternal flag to specify
whether 3rd party apps are allowed on internal storage. We need to
respect the flag when moving apps between storages.
Bug: 30980219
Test: Added ApplicationPackageManagertest
Change-Id: I0f8e76467b5071d70f40da28c2087e689c049c06
This cl adds a new requestBackup API to
BackupManager that takes in an int flag
to indicate whether the caller wants the
entire key value set to be passed to the
transport and not just a diff.
Change-Id: Ia225797a58c4431fe742f2f116b257d006b30cd1
Bug: 33749084
Ref: go/request-backup-api-changes
Test: GTS Test at ag/1774002
- Only happens when the caller is not from the same package.
Bug: 33754261
Test: Open a PIP activity, try to launch it again from launcher
Change-Id: I3c364ebe31a7626b9133d9c4c1fafc718c2eecf9
It was trying to interact through null, which could throw an exception. Example:
01-18 18:28:12.609 862 2038 W Binder : Binder call failed.
01-18 18:28:12.609 862 2038 W Binder : java.lang.NullPointerException: Attempt to get length of null array
01-18 18:28:12.609 862 2038 W Binder : at android.app.Notification$Action$Builder.build(Notification.java:1289)
Test: manual verification
Change-Id: I84fda80ebd12df7d90730b17fa77d4b9ce5f58d2
Add extras keys and methos to Notification and RemoteInput for notifications
whose contents have an audio representation and whose RemoteInputs
can accept data results (useful for, e.g., voice messaging
applications, photo results, etc).
This motivator for this change is it enables an end-to-end flow for
audio messaging including
* System receives the audio message
* Replying to the message with the user's voice
* App receives the audio reply data
Note that this CL just adds the capabilities, but does not
add any UI or implementation to perform the above flow.
Test: As agreed, this will be tested both with a set of unit tests,
and with an "end-to-end" test that simulates two apps, one
creating an audio message with audio reply action, and a
second app that executes that action, providing an audio
result.
Change-Id: I55779ac4b781d8273c13c69fded0b56ee639cf01
Apps that target O+ are always subject to background restrictions.
Legacy apps' background restriction is subject to the OP_RUN_IN_BACKGROUND
app op.
Apps with these properties are exempted from background restrictions:
- persistent process
- currently on the idle battery whitelist
- global whitelist for things like bluetooth services
Bug 30953212
Change-Id: Ib444829a2d222125f64ff19e8218823fa78373f9
During testing, sometimes it's sufficient to know that intent is being
triggered and no need to actually launch the target activity as part of
the test. Currently, ActivityMonitor solves this problem but we have to
know all the intents that will be triggered during the test and provide
ActivityMonitors for each of them. So, this change adds a new api
ActivityMonitor.onMatchIntent which can be used for intercepting any
outgoing intents during tests.
Bug: 31810293
Test: cts-tradefed run singleCommand cts-dev --module CtsAppTestCases -t \
android.app.cts.Instrumentation_ActivityMonitorTest
Change-Id: I46ba4b9a21da000492f9e7b242c01999ebc54423
To inform the user which apps were granted permissions by the admin,
the Settings app needs to access this information without being a DO/PO.
Bug: 32692748
Test: FrameworksServicesTests unit test
Change-Id: I3770ec6343b85be9c6f7655675ed6db5cb50612c
Bug 34163850
onFindViewById is only valid once the Fragment's View
has been created, but the child fragment manager
can be used prior to its creation. This protects
the use of onFindViewById from use by fragment
transitions.
Test: Ic72cd7dae8d7982b78258116e7910c4f07d75d50
Change-Id: I67e3b2d5f59c2e741f29211d08ab07476c78a0ca
Since we start recents before we take the snapshot, we need to add
a mechanism to inform recents about task snapshots changes.
We add a new method to TaskStackChangedListener,
onTaskSnapshotChanged, which gets called whenever a task snapshot
changes. Then, SystemUI registers such a listener and updates the
task thumbnail view for the specific task.
Test: Open app, press recents, make sure thumbnail is up-to-date
Bug: 31339431
Change-Id: I01e81b9cd11886da734da671c68d5732aa51009f
Bug 34125817
It appears that some developers rely on fragment views containing
other fragments without using the fragment's child fragment manager.
This CL executes all unoptimized add operations separately to make
sure that this continues to work. Pop operations continue to be
executed together as they did previously.
Test: Ia0333ac1c09e18a6d9b08fe56b1e5c080652ab5b
Change-Id: I832fe631d05dbf8e9712899fef797da1f5747f5e
Also destroy snapshot when we remove the AppWindowToken.
Test: runtest frameworks-services -c
com.android.server.wm.SnapshotCacheTest
Test: Open app, go home, kill app, make sure snapshots are
destroyed.
Change-Id: I532c2d7499a86164175f9fcbc8b77c6eb6bfeae6
Teach running applications to refresh already loaded ApplicationInfo
objects without resorting to restarting the application process.
Activities will be scheduled for restart via the regular life-cycle.
This is similar to a configuration change but since ApplicationInfo
changes are too low-level we don't permit apps to opt out.
This change is intended to be used with runtime resource overlays and
split APKs.
Test: Manual - command to update application via ActivityManagerShellCommand
Change-Id: Ice10a1691cced90eee95e3278fd784b8a9206d87
Introduce a parameter object to reduce the amount of method overloading
we need to do now and in the future.
Bug: 30876804
Test: manual
Change-Id: I4242140835d440d910a2e2e0ee79af2271e1c046
Currently, those features are available on single user devices only
(since they collect privacy sensitive data device wide). Now making
them available as long as all users are affiliated.
It'll take a certain amount of time between user creation and the DPC
of that new user setting the appropriate affiliation ids. The DO won't
be able to access the logs during that time (and won't get any "logs
ready" callback). Once the affiliation ids are set, if they match,
logs become available again - this includes logs collected while the
user was being setup. Some logs might be lost though if the amount of
data exceeds the internal limit.
Test: runtest -c com.android.server.devicepolicy.DevicePolicyManagerTest frameworks-services
Test: cts-tradefed run cts -a armeabi-v7a --module CtsDevicePolicyManagerTestCases --test com.android.cts.devicepolicy.DeviceOwnerTest
Bug: 32326223
Change-Id: Idfe881dd6497d3ad2bead10addfd37b98b8a6e2b
The GraphicsEnvironment class is given information during application
start, and makes it available to EGL/GLES/Vulkan loaders that don't
have easy access to the VM or to the application Context. Currently
only the driver path is handled, but the existing support for setting
library paths (for Vulkan extensions) and cache directory information
should move here.
Bug: 33531483
Test: various apps w/ and w/o driver package installed
Change-Id: I5820d3d1301d5461e10706f551b268c54d4f8926
Bug: 30972434
Change-Id: Iccdaa6253fd5a118893f2869bfb876b1d1e015c7
Test: No tests yet. Want to get a preliminary OK for the new API. Will add a test before submitting.
This CL allows a reason to be specified when installing a package. The
install reason is a sticky piece of metadata: When a package is e.g.
installed via enterprise policy and an update is then manually
installed or sideloaded, the install reason will remain "policy."
The install reason is tracked separately for each user.
With this CL, two install reasons exist: "policy" and "unknown." Other
install reasons will likely be supported in the future.
Bug: 32692748
Bug: 33415829
Test: Tested manually with "adb install" / "adb uninstall"
Change-Id: I0c9b9e1b8eb666bb6962564f6efd97e41703cd86
