Made use of the two new extras isNetworkRequired and ifWifiRequired in
deciding the ui state of the wifi setting. The CL that adds these
extras in setup wizard is here (http://ag/612291).
Added logic to update the next ("skip") button state accordingly:
(1) "Skip" button should be enabled if
- wifi is not required and network is not required
- or wifi is not required, but network is required, and we have a
valid network connection
(2) "Skip" button should be disabled if
- wifi is required
- or wifi is not required, but network is required, and we have
no valid network connection
Note that the newly added logic is only run if wifi is not connected. If
wifi is already connected, the next button will show "next" and be
enabled.
This fixes the bug where wifi settings in setup wizard does not respond
to mobile data connection change.
Bug: 18783746
Change-Id: I155dcb158f790dd96a71099339f64b64cc647da0
For multisim device when default data connection is set to 1st sim,
getDataNetworkType() returns Unknown for 2nd sim. In that case use
getVoiceNetworkType() to display Cellular nw type in sim status.
Bug: 18922147
Change-Id: Id7c39f8717737b60bde988cbd1c85ce8f6768a6f
Similar to how it is done for other legal information items --
if there is an activity that serves android.settings.WEBVIEW_LICENSE
intent, the item is shown with the title set to the activity's title,
otherwise the item is hidden.
Bug: 18729447
Change-Id: Ic5bad40c91e35fa3c8235128628413929ef111d3
Remove the enable/disable button in certificate setting dialog if restriction
has been put on the respective profile. Also catch security exception just in
case.
Bug: 18899182
Change-Id: Ia247ab264c1b2d08b58456519bf471ba8c727745
This notification is triggered when a bluetooth device that supports
the PBAP protocol. On managed profiles this functionality is not yet
available and therefore the notification and resulting acvitivity
have no function.
Bug: 18782769
Change-Id: Iaea12eee8ec4727d9448f690861f8344e2296028
The method that launches notification screen from choose lock activity
finished the original activity before starting the new activity. This
made the system think it is a backward transition instead of a forward
one. Swapping the order to start new activity first and then finish
old activity fixed the problem.
This also changes the behavior in settings. However, it seems like this
is also the desired behavior for settings.
Bug: 18723199
Change-Id: I90538fa52e0d62a2274c8e0333682035849802c6
Add a service that handles the check through broadcasts which are
defined through configs, similar to the previous configs for the
activity.
Depends on I1f6e2d954562c5a16a0de60dac625005ec3e5c50
Bug: 18453076
Change-Id: I515d72706e9ca37877e67c44427af1b75b146390
