provided ConnectionManager method to do that, instead of changing
it directly using Settings.Global.putInt() - because that doesn't
case ACTION_AIRPLANE_MODE_CHANGED intent to be broadcast.
This breaks Google Search App (GSA) code that relies on the above
broadcast to do a variety of things.
Change-Id: I2aa61643ed23b373aa362a59af83427a4548c492
For settings disabled by user restrictions show
the user a lock icon and allow them to click to
find more info.
Bug: 22543585
Change-Id: Ie8b02ac26f2b22db386a9044f3c6570098f6e14b
L10N team requested that the text might not fit within the
CHAR_LIMIT=35 in some languages. Rather than increasing the limit,
I think it's better to simplify the original text so that
its translations are unlikely to break the limit of chars.
Bug: 26123263
Change-Id: If9b338d2f051c161a71e8b20c9526be2d10e0cc1
Also cleans up unnecessary 0s and moves tint to the proper place in
relevant vector drawable XML files.
Preview layout is still WIP pending UX input, but I wanted to get this
CL in place so that we can test/demo the feature ASAP.
Bug: 22450672
Change-Id: Ic3f1500006c763df99fba2d1d16782b89d6fcae1
'bugreportplus' is more user-friendly (it shows a system notification
with the progress, allow user to cancel, etc...), at the cost of
consuming more resources. As such, the "Take Bug Report" UI will be
changed to offer the user a combo with these 2 options, but for now it's
always going to be 'bugreportplus'
BUG: 26034608
Change-Id: Idbb325fe7cd18e487197b2fb79cfc264e9859570
The old way was garbage-heavy. To add to that some changes to the way
PreferenceScreens are redrawn was leading to some artifacts with items
fading in/out every tick.
Bug: 25588385
Change-Id: Idabf7546ab519bf196ad3b8582caa2ec6bf9e084
This CL adds Managed Profile Location Access control in the form of a switch
preference.
Bug:22541939
Change-Id: I1a2140c54e7386cda83ef0305f0840e4f8f9a6d1
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
