| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If bluetooth is started too early, it will need to be restarted to
change its gid.
By delaying the bluetooth start after the OnUserStarting we ensure the
permissions are already set
Fix: 232740613
Test: build & flash with wipe. Check log at first startup
Tag: #refactor
Ignore-AOSP-First: will be push on aosp next
Change-Id: Ifde1348baad5802276679ecc24bc8ae458d02fe6
|
| |
|
|
|
|
| |
Bug: 217736913
Test: Compile and bringup
Change-Id: I3c1e07567949dd9e503a62b65feee4c7b5e10b2d
|
| |
|
|
|
|
|
|
|
| |
Test: Build + start bt + connect & play
Bug: 195144968
Tag: #refactor
Ignore-AOSP-First: AOSP will be updated later
Change-Id: Iaa5b3f90ab4332390e4dccde3a05837aa4eb074e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just a plain refactoring: the removed methods in the changed
classes were called by default by the new methods in the superclass
(SystemService).
Test: m
Test: atest NotificationManagerServiceTest BackupManagerServiceRoboTest
Fixes: 161943081
Exempt-From-Owner-Approval: refactoring without side-effects
Change-Id: Ifd8df592eb4494cc0922b7e0b2ff20187b8a8b3e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For headless user 0 models we don't start Bluetooth Service in user 0.
We wait for the first user switch to start - call
BluetoothManagerService.handleBootPhase(). However, we also call
BluetoothManagerService.handleOnUserSwitch() which ends up restarting
the service that was started in handleBootPhase(). This leads to the
Bluetooth service not being available due to the extra restart.
Changing the loigc to
1. Handle boot phase on User switch if not done before.
2. Handle on switch user otherwise.
This saves 6-7 seconds of the time it takes for something like BLE to be
available in the automotive builds.
Bug: 137289703
Test: Make sure Bluetooth comes up only once with no restarts on boot up
and also ensure Bluetooth is restarted when manually switching to
another user.
Change-Id: I30179f4c2a3f81940258c70045a6ba8b32f315e1
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- isHeadlessSystemUserMode() returns whether the device is running with
headless system user (go/multi-user-headless-user0)
- RoSystemProperties.MULTIUSER_HEADLESS_SYSTEM_USER is replaced by
isHeadlessSystemUserMode()
Bug: 137755681
Test: Bluetooth service and Network policy manager should work fine with
headless system user. A profile user should be created with headless
system user.
Change-Id: Ic48d98426f7a5ea47dde2008ae51f78855f622e6
|
| |
|
|
|
|
| |
Test: build
Bug: 129549399
Change-Id: I42ab7daa80da62e3d754e61721b5d7297f376419
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If Headless User 0 is enabled then don't launch Bluetooth until after
user has switched out of 0. This is specifically an issue for
automotive platforms.
Bug: 118400949
Test: Boot device while headless user 0 is enabled, with a paired
Bluetooth device in a phonecall.
Change-Id: I9ea833df7ae7dc8841102ab9693f3810b31f672f
(cherry picked from commit 195a1c026fb17ab8b4fa0dd812381fe39126d213)
|
| |
|
|
|
|
|
|
|
| |
If Bluetooth was enabled at boot time, but the actual Bluetooth
package wasn't encryption aware, we need to kick off another enabled
pass once the user is unlocked.
Bug: 27326711
Change-Id: I511c4fd8567792e5bc4d49fa95929fd87edd0fbf
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason BluetoothManagerService recently has been unable to bind
to the BluetoothService, causing timeouts, which in turn could lead to
Bluetooth not working immediately after boot.
While refactoring that code, the "get name and address" code was also
removed to make the startup sequence more transparent and easier to
debug.
Bug: 25597150
Change-Id: I62ffe4589a76ea8a6db75e3c7599f149db677ea3
|
|
|
As a subclass of SystemService, BluetoothService wraps around
BluetoothManagerService to unlock Auto-enabling Bluetooth earlier by overriding
onBootPhase() and removes the need to wait for BOOT_COMPLETED message.
Bug:21705209
Change-Id: I2acc41370a750d8416e11e662e06392326741d2c
|
