In the absence of mocks, the silder is shown in the
'normal' position if the user hasn't yet
chosen an importance value.
Bug: 22854014
Change-Id: I51594959412775fe89b29af66ddcb13bafa67255
-Re-format CellInfo to a Table
-Improve performance on several blocking calls
-Add IPv6 ping test
-Re-order layout to improve logical grouping
-Semantic changes/cosmetic improvements to a few strings
-Expand list of selectable network types to include recent RATs
Change-Id: I02d15987e7cb79fe0bbd13e5d1eb734e3531f11f
Add a gear on Settings menu, and move a bunch of stuff from
overflow and advanced screen to there. Also move add network
to be the last item in the list rather than in overflow.
Also fix WifiP2p breakage.
Change-Id: I5c84c25e5ba9224f77dcd988b0b2850ae6e71168
The privilege for an app to write to the system settings is protected
by an app-op signature permission. App-op permissions are special: if
the app-op is deny/allow we deny/allow write access; if the app-op is
default holding the permission determies write access. The settings
code assumes that CHANGE_NETWORK_STATE is an app op permission
(system|appop) while it is a normal permission which any app gets by
declaring it used in the manifest.
The side effect is that the state of the toggle in the UI for write
system settings will initially be in the wrong state if the app uses
both WRITE_SETTINGS and CHANGE_NETWORK_STATE. However, the code in
the public API an app uses to check write settings access would return
the opposite since it checks the WRITE_SETTINGS permission and its
app op. Hence, if an app requires write settings to start the user
will see in the settings UI it has access but the app will not have
access, so the app would prompt the user to allow write settings.
The non-obvious fix is for the user to toggle the setting off and on
to get the app op in the right state and be able to launch the app.
bug:25843134
Change-Id: I2da4eec1c3574bd6aef9ab968c9deb148536cb0a
Moved the area info handler from CellBroadcastReceiver to
CellBroadcastAreaInfoReceiver.
bug: 25628456
Change-Id: I2c7c6bb83245fcb6d9cc7b5dce7496e906160bab
When the home screen selected by the user isn't encryption aware, we
still need to put something on the ActivityStack. For now, let's use
an empty activity that knows how to dismiss itself when the
credential-encrypted storage is unlocked; that's enough for the
system to re-resolve the home intent and find the real home screen.
Also follow method refactoring.
Bug: 22358539
Change-Id: Iebc4ad8d2dd62ada079cab03d5765f7631fd4beb
