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
When launching ChooserActivity from lockscreen, we will start it
in stopped state because lockscreen is still showing, meaning that
the activity goes through start -> resume -> pause -> stop
immediately after it was launched, and will be later resumed once
Keyguard actually goes away.
However, ResolverActivity finished itself in onStop. We add a
private extra to change this behavior for sharing bugreports.
Test: Take bugreport, double tap on it on lockscreen
Test: com.android.shell.BugreportReceiverTest$1
Bug: 33009364
Change-Id: I973b2c71587950499b7c88b16af9cf1387795e17
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
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
(cherry picked from 6387604f9e672ece85e07c4bcbd7be396867f06f)
Bug: 30188076
Test: make checkbuild
Merged-In: I13e88297731253420e4e5f5291d503f13a39a156
Change-Id: I58446eb8c45d8ac2bcdbc9fa40d1321e811bdd4b
In preparation for removing junit classes from the Android API
the legacy-test target will be removed from the
TARGET_DEFAULT_JAVA_LIBRARIES. This change adds explicit
dependencies on junit and/or legacy-android-test to ensure that
modules will compile properly once it is removed.
Bug: 30188076
Test: make checkbuild
Change-Id: I13e88297731253420e4e5f5291d503f13a39a156
Now we look at work profile too, if available, when looking for a preferred
email address.
TODO: The chooser activity should default to work profile too, but it seems
to require a lot more work, so not done yet.
Test: manual tests
Test: adb shell am instrument -w -e class com.android.shell.BugreportProgressServiceTest com.android.shell.tests
Bug 30865666
Change-Id: I9b4776d53455a23bfdc4960da25e98bd1dc1b2a1
Bug: 32849428
* goog/cw-f-dev: (98 commits)
Revert "Catch KeyStoreException for setting profile lock"
Fix createConfirmDeviceCredentialIntent for wear for CTS.
Fix default dialog background colour for watch devices.
Catch KeyStoreException for setting profile lock
Add cross-links between FINE and COARSE location permissions. bug: 25371600
Fixed a bug with the emergency affordance in multi user
Zygote: Additional whitelists for runtime overlay / other static resources.
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Zygote : Block SIGCHLD during fork.
colors: add missing accent_material_{700,50} resources.
Import translations. DO NOT MERGE
Import translations. DO NOT MERGE
Zygote : Block SIGCHLD during fork.
DO NOT MERGE ANYWHERE Revert "DO NOT MERGE ANYWHERE libhwui: make setSurface asynchronous"
...
Change-Id: I63468da5bfa21ed9ac5985bbdbf3a61d4c389aa0
BugreportProgressService used to poll system properties to get the
progress of the underlying dumpstate process, but now dumpstate provides
a IDumpstateListener and IDumpstateToken binder objects for the same
purpose.
Test: BugreportReceiverTest passes
Test: manual verification
BUG: 31636879
Change-Id: I81d551781a511cb1cc218a27452875b0bb267f7a
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
Currently, we define 4 hardcoded init services to launch dumpstate with
different command-line options (since dumpstate must be launched by
root):
- bugreport
- bugreportplus
- bugreportwear
- bugreportremote
This approach does not scale well; a better option is to have just one
service, and let the framework pass the extra arguments through a system
property.
BUG: 31649719
Test: manual
Change-Id: I1d627a73bfbdd9930c605fa4468c15282a23bb65
