summaryrefslogtreecommitdiffstats
path: root/tests/src/com/android/settings/SettingsHookTests.java
Commit message (Collapse)AuthorAgeFilesLines
* Refactor Bluetooth settings for readability and performance.Jake Hamby2011-03-011-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor settings top level activities to use fragments.Amith Yamasani2010-08-181-6/+6
| | | | | | | | | | | | | Added a base class SettingsPreferenceFragment from which the settings activities should be derived so that they can behave like fragments. It contains some commonly called utility methods and dialog conversion to DialogFragment. Some of the top-level activities can be launched directly without the left pane. Settings.java acts as a proxy activity that contains just that settings fragment without the left pane. There are still a lot of second and third level activities that need to be fragmentized. This is just the first pass to test the 2-pane layout.
* Settings: Add a hook for operator or vendor specific settings.Anders Hammar12010-06-111-0/+137
The Settings application now provides a hook that can be used by an operator or a vendor specific application to add an activity of choice in the settings menu. Change-Id: Id55da9fd4262bbfc6a5abf863799c747b0d75b24