We recently created a new GID that can be granted to critical system
processes, so that the system is usable enough for the user to free
up disk space used by abusive apps.
Define a permission for the GID so we can grant it to system apps,
and add the GID to core apps needed for system stability. (The list
was mostly derived from filling a disk and seeing what caused the
device to fall over.)
Test: builds, boots
Bug: 62024591
Change-Id: Icdf471ed3bed4eeb8c01f1d39f0b40c1ea098396
This change adds a special flag when binding to a service to request
instant apps to be considered as well (assuming the caller has the
permission to see instant apps). This flag is scoped only for the
platform to use and is intended only for development and testing.
Specifically, we have a class of CTS tests that has tests plus service
in the same APK (accessibility, printing, autofill, any other plugin
based sub-system).
Instead of doing the tediuous work split all these into one APK with
tests and one with the services where the latter exposes a remote
interface to the former, we will be adding shell commands to the
dedicated sub-system to allow temporary binding to plugins provided
by instant apps. The goal is not validating the plugin behavious,
rather a working plugin is required to test app side funcionality.
This change adds a shell command to allow the a11y manager serivce
to bind to plugins provided by instant apps. This is required to
be able to run relevant CTS test cases in instant mode.
Test: cts-tradefed run cts-dev -m CtsAccessibilityTestCases
cts-tradefed run cts-dev -m CtsAccessibilityServiceTestCases
Bug: 70978575
Change-Id: Ifced735a9a6e495747372dd8b00fdd64933a09c7
Without this change, `lowpanctl`, the command line tool for managing
LoWPAN networks, won't be able to work properly.
Cherry-picked from commit 1b730e4bd2c8e03d2a9bf041a4acd6fd6c0467f1.
Bug: b/65490659
Test: Manually
Change-Id: Ie44bac5c3bdc956dc2b1e79284ad18eae6931a32
This is needed for calling AM.registerUidObserver.
Fixes: 64400666
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases -t \
android.app.cts.ActivityManagerProcessStateTest
Change-Id: I4f500d0d8d516b6b8961ea2f8c083add3ae949a9
Add wifi-related permissions to the shell's manifest.
Bug: 64683466
Test: manually verified wifi can be toggled when airplane mode is active
Change-Id: I790ab5fc01f5c76fd98dedae4b9bfe88ecb48f69
1. Added permission ACTIVITY_EMBEDDING which allows apps to launch
activities on virtual displays.
2. Allow owner of display to launch activities from same app without
permission check to owned display.
3. Added permission checks for launching on secondary displays to
more target task/stack resolution paths in ActivityStarter.
Bug: 63117330
Test: android.server.cts.ActivityManagerDisplayTests
Test: go/wm-smoke
Change-Id: If169a77fb56241e06f7de20168dc38c4b0a217f5
(cherry picked from commit 7158764983)
It already has CLEAR_APP_USER_DATA to clear everything inside app
storage, and clearing cached data is a subset of that.
Test: cts-tradefed run commandAndExit cts-dev -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.StorageHostTest
Bug: 36731175
Change-Id: Iefc5be6c80e2562a95424fd6fe413bdb018201a9
Some of the Vr APIs in VrManagerService need to be accessed via shell to
be used for testing and for easy access. Add
android.permission.RESTRICTED_VR_ACCESS to shell uid.
Bug: 36071574
Test: adb shell vr set-persistent-vr-mode-enabled true
adb shell dumpsys vrmanager
>> Persistent VR mode is currently: enabled
adb shell vr set-persistent-vr-mode-enabled false
adb shell dumpsys vrmanager
>> Persistent VR mode is currently: disabled
Change-Id: I486fa19f93d5c6999aa479fdf7e5f2f48f765240
Signed-off-by: Karthik Ravi Shankar <karthikrs@google.com>
- The task overlay activity should only exist when there are activities
present in the task. When the last such activity is finished, we should
remove the whole task entirely including the task overlay.
- Exposing the task overlay apis to CTS
Bug: 36507456
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: #testFinishPipActivityWithTaskOverlay
Change-Id: I1dabe7782fb6769a90d832664e8052be158041e1
Shell needs to have this permission in order for the deviceidle
tempwhitelist shell command to exist.
Bug 34715096
Test: cts-tradefed run cts -m CtsAppTestCases \
-t android.app.cts.ActivityManagerTest#testBackgroundCheckService
Change-Id: Ic1fdd87b6020649705ba0c9349dd00dd096037f3
BluetoothManagerService for some reason leaks the Android's Bluetooth
MAC address via Settings.Secure which is normally readable by all
apps. This lets apps bypass the restriction on access to Bluetooth MAC
address from apps.
This commit fixes the issue by restricting access to bluetooth_address
secure setting (Settings.Secure). Only packages which hold the
android.permission.LOCAL_MAC_ADDRESS permission retain access.
This commit accordingly grants LOCAL_MAC_ADDRESS permission to the
system Shell app because a number of scripts (including Android CTS)
use "adb shell settings get secure bluetooth_address" as a convenient
way to query the device's Bluetooth MAC address over ADB. This is
acceptable because the user of the device can see the Bluetooth MAC
address and thus it's fine for shell to be able to see the address as
well.
Test: See CTS test added in the cts project in this topic.
Test: "adb shell settings get secure bluetooth_address" returns the
Bluetooth MAC address of the Android.
Test: "adb shell settings list secure | grep bluetooth_address"
returns the Bluetooth MAC address of the Android.
Test: Bluetooth works (toggling off/on, pairing, file transfer)
Bug: 33701414
Change-Id: I17b110b96eb3794b25c1661e93d29a7a003e3c9a
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
Change-Id: Ib8afa05ccab4e2db558f89ce4423983c086bb61a
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'
Hand over ownership of overlays to OverlayManagerService.
Changes to a package's overlays are propagated using the activity life
cycle. Affected activities will be recreated as needed. This provides a
well-defined point to modify an application's assets while the
application is paused.
Consolidate how overlays targeting the system and overlays targeting
regular applications are handled. Previously, system overlays were
handled as a special case. Now, everything is handled identically. As a
side effect, the call to idmap --scan during Zygote boot has become
obsolete and is removed.
Information on what overlays to use is recorded in
ApplicationInfo.resourceDirs. The PackageManagerService is responsible
for the creation of ApplicationInfo objects. The OverlayManagerService
is responsible for informing the PackageManagerService in advance about
what resourceDirs to use.
When launching an application, the ApplicationInfo is already populated
with up-to-date information about overlays.
When enabling or disabling an overlay for a running application, the
OverlayManagerService first notifies the PackageManagerService about the
updated resourceDirs. It then tells the ActivityManagerService to push
the new ApplicationInfo object to the application's ActivityThread.
Finally the application requests its ResourcesManager to create new
ResourcesImpl objects based on the updated paths.
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: Idc96dae6fc075d5373aa055bbf50e919136d7353
This CL provides the initial, skeleton implementation of the Auto-Fill
Framework classes:
- Defines the system service and app-based
AIDL (IAutoFillManagerService.aidl and IAutoFillService.aidl respectively).
- Defines the 'adb shell cmd' interface.
- Defines the permission required to access the service.
- Registers the service on SystemServer.
- Adds the code to bind the app-specified service to system_server.
- Defines the service class (AutoFillService) required by providers.
- Implements the initial startSession() method.
This is still a very early, "work-in-progress" change:
- It has many TODOs.
- It does not have unit or CTS tests yet.
- It does not provide a callback method to auto-fill the fields.
- In fact, it has a lot of TODOs.
Despite these adversities, it can be tested by following the steps
below:
1.Create an app with a service extending AutoFillService
2.Implement the onNewSession() method
3.In the manifest:
- Listen to android.service.autofill.AutoFillService intents.
- Require the android.permission.BIND_AUTO_FILL permission.
4.Explicitly set the app as an autofill-service by running:
adb shell settings put secure auto_fill_service MY_APP/.MY_SERVICE
5.Start a session against the top activity:
adb shell cmd autofill start session
BUG: 31001899
Test: manually built and ran it
Change-Id: I00f4822159b31ddddba8f513e57c4474bc74eb89
By using DeviceDefault instead of Material, this UI is now
resilient to any platform-level theme changes.
Change-Id: I43ce61b36f4c089ee07f754088abe2dfe6700877
Fixes: 30173174
Remove MANAGE_USERS permission from shell and whitelist it for
some specific functionality.
Bug: 29189712
Change-Id: Ifb37448c091af91991964511e3efb1bb4dea1ff3
But make sure that we don't allow Shell or other apps
to disable an active profile or device owner.
Also limit exactly what states Shell can switch apps
between, similar to Settings UI.
This is required for some CTS tests
Bug: 27924655
Change-Id: I958f0d1de7f0bc1f5a0cbf853d57dfdeb2f9ad59
Mostly consists of removing the word "encryption" from most APIs,
since we can't actually make promises about the data being encrypted.
Bug: 27531029
Change-Id: Iace9d7c4e64716abf86ed11847c40f3947e1d625
Second attempt. Still need to add strict mode violation checks and
logging.
Bug: 21901286
This reverts commit bf33bd4d31.
Change-Id: I5d73343544c32ce4fc4c377ba44db8e677a1287d
After receiving android.intent.action.REMOTE_BUGREPORT_FINISHED
in newly created RemoteBugreportReceiver, Shell will generate URI
to the bugreport zip file and send the broadcast
android.intent.action.REMOTE_BUGREPORT_DISPATCH.
Bug: 26152603
Change-Id: I058d626e021b488c9347b45467a4e3505134e79c
Currently, the bugreport screenshots are taken by dumpstate and passed to
Shell as a path on BUGREPORT_RECEIVED; this change not only delegates the
screenshot taking to Shell, but also allows user to take more
screenshots while the bugreport is being generated.
As a result of this change, the final ACTION_SEND_MULTIPLE intent might
contain multiple screenshot attachments, all of them named
"screenshot-PREFIX-NUMBER.png", where PREFIX is the bugreport
name (either initial date provided by dumpstate or a name entered by the
user) and NUMBER is the sequential number of the screenshot as taken by
the user.
The screenshot is taken using screencap, which not only is simpler than
using Framework APIs, but also faster and less intrusive. The only
drawback is that it might fail if an OEM is not providing screencap; if
that happens in the field, we'll need to add fallback option to do it
using such APIs.
Prior to this change, all work done on BugreportProgressService was
executed in one single thread (through the ServiceHandler class) but the
code was guarded by unnecessary synchronization. Now there is another
thread (ScreenshotHandler) that will be used just for taking the
screenshot (so it doesn't handle the main thread). Despite the addition
of a new thread, the code was simplified to remove most synchronization
locks, excepted for the areas touched by both threads.
Once this change is submitted, the bugreport service will be changed so
it does not ask dumpstate to take a screenshot.
BUG: 26274653
Change-Id: I1df883e3c0ca6e3e3cad2522a6a99585f71abb75
The old workflow was:
1. dumpstate starts.
2. When dumpstate finishes, it sends a BUGREPORT_FINISHED intent.
3. Shell's BugreportReceiver receives the BUGREPORT_FINISHED and issues a
system notification so user can share the bug report.
The new workflow is:
1. When dumpstate starts, it sends a BUGREPORT_STARTED with its pid and
the estimated total effort.
2. When Shell's BugreportReceiver receives the BUGREPORT_STARTED, it:
2.1 Issues a system notification so user can watch the
progresss (which is 0% initially).
2.2 Starts a service (BugreportProgressService) responsible for
polling the dumpstate progress (using system properties and the
pid) and updating the system notification.
3. As dumpstate progress, it updates the proper system property.
4. When dumpstate finishes, it sends a BUGREPORT_FINISHED event.
5. When Shell's BugreportReceiver receives the BUGREPORT_FINISHED, it:
5.1 Finishes the service if necessary.
5.2 Issues a system notification so user can share the bug report.
This CL handles the Shell changes only, the dumpstate changes will be
changed in a separate CL.
BUG: 25794470
Change-Id: Icbd0b42dd48e8db376b60544348b6818c6374338
Although this Change doesn't modify the workflow logic itself, it paves
the way for upcoming changes where the overall bug report progress will
be monitored by this service.
BUG: 25794470
Change-Id: Id0c867b04b595b5d31d11531405408f3423dd68b
These tests rely in the UI Automator to interact with the UI and
follow the workflow below:
* creates the bug report files
* generates the BUGREPORT_FINISHED intent
* emulate user actions to share the intent with a custom activity
* asserts the extras received by the custom activity
It still have some limitations, like requiring the phone to be unlocked
and having the bugreport warning already checked, and those will be
addressed in future CLs.
BUG: 25752530
Change-Id: I01d7fad9f94daf156b728cbb9ef228bbfa6ee0f5
Add granular StorageManager APIs for key creation/destruction and
unlocking/locking. Start passing through an opaque token as part
of the unlock command, but leave it empty for now. We now have a
separate "prepare" method that sanity checks that user directories
are correctly setup.
Define a handful of system properties used for marking devices that
should be operating in FBE mode, and if they're emulating FBE. Wire
a command to "sm", but persisting will come later.
Start using new "encryptionAware" flag on apps previously marked with
coreApp flag, which were apps running in the legacy CryptKeeper
model. Small tweaks to handle non-encryptionAware voice interaction
services. Switch PackageManager to consult StorageManager about the
unlocked state of a user.
Bug: 22358539
Change-Id: Ic2865f9b81c10ea39369c441422f7427a3c3c3d6
Also clear identity when measuring ASEC sizes to relax a second
permission requirement.
Bug: 23600574
Change-Id: Ib3a104426758e0e8f35dff0e504fe874bed7311f
Do not go gentle into that good night,
Old age should burn and rave at close of day;
Rage, rage against the dying of the light.
Though wise men at their end know dark is right,
Because their words had forked no lightning they
Do not go gentle into that good night.
Bug: 21854466
Change-Id: I0b7cd116c23f7df88e94f31b3aee7dd22a102804
These are needed for adb shell telecom commands to work on
non-eng builds.
Also fix a couple of typos in telecom documentation.
Change-Id: Ia219ff78f5d65878e43e6b9216f979185495ce7f
Since user builds can't setprop, add an explicit "sm" verb to change
the force adoptable state.
Bug: 21191915
Change-Id: I719d9b18c1a98c97442a5ddb1cc5512e8e4d3d3f
