The Settings app offers several Bluetooth intents, and they need to
be updated to enforce the new "Nearby devices" runtime permission
model, since the old BLUETOOTH and BLUETOOTH_ADMIN permissions have
been deprecated.
Bug: 191174082
Test: TH
Change-Id: I0d812f486bc3dadc517d5b04d3082d4f56f60ef4
Bluetooth app will indicate BluetoothOppReceiver to receive
device picker intent. But for fix the security issue we
removed the setClassName() method in ag/14111132 to avoid attack.
It causes BluetoothOppReceiver cannot receive the intent.
This CL will compare to calling package name with launch package name.
If they are not equal, the setClassName() will not invoke.
Bug: 186490534
Bug: 179386960
Bug: 179386068
Test: make RunSettingsRoboTests -j56
Change-Id: Ia51528f2a44ab73edbc86899ca0846d3262fe1f0
BluetoothPermissionActivity and DevicePickerFragment will send
broadcast to return the result to calling apps. As this broadcast
intent is from Settings with uid 1000, it will be sent to any
protected BroadcastReceivers in the device. It can make an attacker
send broadcast to protected BroadcastReceivers like factory reset intent
(android/com.android.server.MasterClearReceiver) via
BluetoothPermissionActivity or DevicePickerFragment.
This CL will not allow to set package name and class name to avoid
the attacker.
Bug: 179386960
Bug: 179386068
Test: make -j42 RunSettingsRoboTests and use test apk to manually test
to verify factory reset not started and no system UI notification.
Change-Id: Id27a78091ab578077853b8fbb97a4422cff0a158
This reverts commit 9d00364da4.
Reason for revert: This fix have a regression, for not blocking b/183344112 revert it.
Change-Id: Ic4366b51e07b43c8d64d2e145563d8a30cb0fc60
BluetoothPermissionActivity and DevicePickerFragment will send
broadcast to return the result to calling apps. As this broadcast
intent is from Settings with uid 1000, it will be sent to any
protected BroadcastReceivers in the device. It can make an attacker
send broadcast to protected BroadcastReceivers like factory reset intent
(android/com.android.server.MasterClearReceiver) via
BluetoothPermissionActivity or DevicePickerFragment.
This CL will compare to calling package name with launch package name.
If they are not equal, the broadcast will not send to launch package name.
Bug: 179386960
Bug: 179386068
Test: make -j42 RunSettingsRoboTests and use test apk to manually test
to verify factory reset not started and no system UI notification.
Change-Id: Ib8a5acde663e875912d300dd4912c4e9416f02f1
This CL before, DevicePickerFragment didn't check the
whether 3rd-party app have Bluetooth permission before
sending broadcast. It's will cause the 3rd-party app can
get Bluetooth device information without request permission.
This CL will send broadcast with Bluetooth permission that
make sure the receiver who have Bluetooth permission can get
this Bluetooth device infomation.
Bug: 161716630
Test: verify on test apk to confirm that not showing mac address.
Change-Id: I6662dc38b3491e5ee467058dd74863ecac27cdd7
notifyHierarchyChanged() is used before when we have
connected/disconnect deivce in same list. So only use it in
DevicePickerFragment.java, not other normal fragments.
Also that call will rebuild whole preference list, which is heavy.
Bug: 119479725
Test: Manual
Change-Id: I06cf221588001b38634fec9f02dee8bc1e561ea8
Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
LocalBluetoothAdapter only has a few APIs that is not supported
by BluetoothAdapter, and lots of LocalBluetoothAdapter function
pass parameter to BluetoothAdapter directly.
Do the refactor in Settings, use BluetoothAdapter instead of
LocalBluetoothAdapter.
Bug: 111769754
Test: make -j42 RunSettingsRoboTests
Change-Id: I88e5a8377b5d1106c7679e6a8c3fd1ca1a80ea6f
getPreferenceControllers() -> createPreferenceControllers() for the same
reason as in ag/3647936
Bug: 73668763
Test: robotests
Change-Id: I97670a91a2a38d1c844d1b9d37f4222c5e6f45a0
BluetoothProgressCategory will add a no device preference if it is
not scanning and no device is added to the list. Since
DeviceListFragment doesn't report its scanning status correctly, it will
show "No nearby device" even though it is scanning.
This cl add control code for BluetoothProgressCategory in
DeviceListFragment, which avoid the unnecessary no device preference.
Bug: 62492822
Test: RunSettingsRoboTests
Change-Id: Ic49f21cb58a80dcd37c5737800181263ae876ebc
* Modified DeviceListPreferenceFragment to have enable/disable scanning
methods. In ENABLE state, each onScanningStateChanged(false) will
restart another round of scanning
* Subclasses of DeviceListPreferenceFragment should call enable/disable
scanning when scanning is needed for long period of time
* Currently, BluetoothPairingDetail and DevicePickerFragment call
enableScanning() when Bluetooth is turned ON and call disableScanning
when some device is picked in their lists
* Both BluetoothPairingDetail and DevicePickerFragment will re-enable
scanning if pairing failed for selected device
* Added associated unit tests as well
Bug: 32172815
Test: make, pair Bluetooth device, send file over Bluetooth Opp
Change-Id: I99325e06aadd7b00e7a7ba6d6c282a6831859d8b
This cl splits the BluetoothSettings into paired device page and
pairing page, including small changes about:
1. Refactor the pages so they could get as much as static preference
from xml file rather than dynamically add/remove them everytime.
2. Remove creating method in BluetoothDeviceNamePreferenceController
and add it in xml file
3. Create BluetoothPairingDetail page, basically move the logic from
BluetoothSettings.
4. Make pairing preference clickable and jump to BluetoothPairingDetail
5. Add and update bunch of tests
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: Ief9e9690c612f7b46c58e866e5cecc511af642c8
Create the obsolete version of the belowing fragments, so we could
flip between old page and new page.
BluetoothSettingsObsolete and DeviceListPreferenceObsoleteFragment
contains all the old logic but:
1. Logic about BluetoothPairingPreferenceController(ag/2239482),
since this preference shouldn't be checked in without the flag :(
This cl also adds logic in MasterSwitchPreferenceController to flip
these two pages.
Following cl will refactor these fragment to make it compatible
to new framework.
Bug: 35877041
Test: RunSettingsRoboTests
Change-Id: I1cc1bc2d49d8a3e11c3127e56f6409fbc84028d8
RestrictedDashboardFragment has all the same logic coming from
RestrcitedSettingsFragment but extends from DashboardFragment.
As a result, we could use preferenceController in child class of
RestrictedDashboardFragment.
This cl also make DeviceListPreferenceFragment as child of
RestrictedDashboardFragment, which enfluences the bluetooth page.
Bug: 38041586
Test: Build
Change-Id: I01395d506176c5cc584948478f7ca16c1c7c7045
This reverts commit 457c3cbec2.
Revert with fix/test.
The fix is that we removed DevicePickerFragment#initDevicePreference(),
which incorrectly set a useless widget on preference, and removes the
gear icon from preference, preventing bind() call to go through
Change-Id: Ia70cdb51d13cca6035a4e7fe8008d195f7f00c6e
Fix: 36511169
Test: runtest --path tests/app/src/com/android/settings/bluetooth/DevicePickerActivityTest.java
Handle onDestroy in DevicePickerFragment class, which would be
called when user presses back button and does not select any device.
This will send intent to class that called DevicePickerFragment that
no device is selected.
Test: Performed the usecase overnight and see if no crash is observed.
Bug: 35626275
Change-Id: Ib3965d7dea8d59b244abdc6ffe61ef21109346fb
Bug: 30681771
Test: SettingsUnitTests
Refactor visibility logging from InstrumentedFragment into a mixin. And
apply mixin in remaining fragments.
Change-Id: Ibbb59904336254a3e4bb9e8c7d0b36e5a6bc2622
Move the non-ui bluetooth control/tracking code to SettingsLib so
that it can be shared with others.
Mostly just move classes to frameworks/base/packages/SettingsLib,
however a few things had to move around.
- Dock handling had to move back to code still in settings
- Local preference related code had to be moved back to settings
- Added an error flow from SettingsLib to Settings
Depends on I69fd888362c6dbb325f6113b32c4b15cc6a23a41
Bug: 19180466
Change-Id: Ie57fe26a27bbb0adc2ef69e042a05c7290c6a52a
When these screens are locked down with user restrictions,
it should prompt the user for the restrictions pin before allowing
access to the settings screen.
Change-Id: Iadbb087da2d9470b855ea0bea89f2da1ffb9e854
When a user has the user restriction DISALLOW_CONFIG_BLUETOOTH
- Remove all the menu items for searching and other config
- Hide "available" but non-paired devices
- Remove settings button from paired devices
- Remove ability to make the device visible to others
Change-Id: Icaebf29d3cce55d924fdd65449447b5b7a438bbe
The Bluetooth device picker was restarting the device scan after
the screen is rotated. Fix this by only starting the scan when the
savedInstanceState Bundle passed to onCreate() is null.
Also removes "No Bluetooth devices were found nearby" from list if
the user switches to a different app and then switches back to
the device picker.
Bug: 5249380
Change-Id: I8959c850649eb713fb930ee0a8a7bcb73ca7c1aa
Paired devices are listed first (from cache), followed by unpaired ones.
A scan is only started on user request or when there is no paired device
(should it be when there is no paired *connected* device?).
Wrench icon only displayed for paired devices.
Wrench click listener no longer uses mDeviceSettings which is unreliable
with ListView view recycling.
Fixed blinking ProgressCategory when the category was first in the list.
Change-Id: Ie749883426c12bd354da64733bd04b00304bc1f5
Major refactoring of Bluetooth settings classes.
- Moved all functionality from LocalBluetoothManager into new
LocalBluetoothAdapter and LocalBluetoothPreferences, and into
existing classes.
- Refactored functionality from BluetoothEventRedirector into new
BluetoothEventManager class, deleting the original version. New
version uses a HashMap from action Strings to implementers of the
BluetoothEventManager.Handler interface.
- Created new BluetoothDiscoveryReceiver to update shared preferences
timestamp for Bluetooth discovery start/finish. This is the only event
handling we need to do when the settings app is not visible, so it has
its own receiver entry in AndroidManifest.xml. Edits are written using
QueuedWork.singleThreadExecutor(), which BroadcastReceiver knows about
and will wait for completion, eliminating the need for PendingResult.
- Miscellaneous cleanups to code style and logic for readability.
- Pulled some large switch statement code blocks into new methods.
- Changed all Bluetooth state references to the new BluetoothProfile
constants.
- Changed use of deprecated Notification constructor in
BluetoothPairingRequest to use Notification.Builder.
- Moved Utf8ByteLengthFilter helper function from BluetoothNamePreference
into its own class, and moved test cases into the same package.
- Moved all LocalBluetoothProfileManager functionality related to
specific profiles into new top-level classes (A2dpProfile, etc.), all
implementing the LocalBluetoothProfile interface.
- Moved all UI-related methods from CachedBluetoothDevice into the class
that uses the method, or into the static Utils class for shared methods.
Change-Id: I6d49b7f4ae0c7d7dcf62551ee40b51ecb5fe4f47
Close the scan screen after successful pairing, and remove a
device from the list of paired devices after unpairing.
As part of the fix, BluetoothSettings was refactored into a parent
class, DeviceListPreferenceFragment, and three subclasses for each
variant type: BluetoothSettings, BluetoothFindNearby, and
DevicePickerFragment, replacing the checks against mScreenType with
custom logic in the child classes.
Bug: 3325848
Change-Id: If64fddc3ba5b4f1136451491c7d5a1139b696e47
