Having consistent import order will reduce chance of merge
conflict between internal and external master
Test: rebuild
Change-Id: I0b1a170967ddcce7f388603fd521f6ed1eeba30b
This CL only changed AlertDialog imports.
So, reviewer can review it easily.
Change-Id: I097bc44394195b14287f4f920c570ac8653f356a
Fixes: 111413092
Test: This CL can't pass Robo test.
1. There is no way to disconnect VPN after 'Clear credentials'
without removing whole Internet connection because VPN profile to
disconnect is removed when Clear credentials.
2. This commit checks whether VPN is being established or not when
Clear credentials and disconnect VPN if VPN is being established.
Lastly, this shows a toast message to inform VPN disconnected.
Test: manual - took a photo
Signed-off-by : Sungmin Lee <insight.lee@lge.com>
Bug: 29093779
Change-Id: Id5ea01c8731b3b0fca2a31d9d84e8c103952b377
Allows Settings to control whether always-on VPN is required for the
connection to complete, or if it is offered on a best-efforts basis.
Change-Id: I5eb273a99e7559adc66b05e647c9130a819f99d4
Test: runtest -x tests/app/src/com/android/settings/vpn2/VpnTests.java
Fix: 32420810
Lockdown is now the default option, not best-effort mode. It's easier
to shoot oneself in the foot now so we'll show a warning to explain that
before switching it on.
Bug: 29052115
Bug: 29076208
Test: com.android.settings.vpn2.AppSettingsTest
Change-Id: Ia6845e6a7d57baa5476b8a021fb1255fd74aabea
Failing to disconnect but deleting the keystore entry anyway makes
it difficult to do anything about a still-running connection.
Also switching over from prepareVpn(x,x) to prepareVpn(null,x) which
helps avoid race conditions where in between the getLegacyVpnInfo and
prepareVpn calls a 3rd-party app started a connection, which would break
the disconnect but still register as success.
Bug: 23529835
Bug: 29032008
Change-Id: Iedce784cb0eafbf75fe015dd2b3d355fcd887abf
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ic2c25b79d8a17917025eb37be7de929fe156e2a3
A little more consistent with the new app VPNs' dialogs. To make this
work it was also necessary to restart the lockdown VPN every time it is
edited, which makes sense because the expected action after editing a
VPN is that it reconnects with the new settings.
Bug: 28072644
Change-Id: I4b6a6f0a6ed96d2ec6f62889fdae4abb60d0646c
- Move always-on option for legacy vpn into the legacy vpn config page
- This implementation doesn't show dialogue when replacing existing always-on vpn
- Continue to disable lockdown option for legacy vpn when "persist.radio.imsregrequired" is true.
Not applying to vpn app
- Force to save account info when legacy vpn is always-on
- When legacy vpn is always-on, don't try to connect. (Otherwise, an exception is thrown)
TODO: Remove EXTRA_PICK_LOCKDOWN in LockdownVpnTracker in framework
Bug: 26950700
Change-Id: Ia80669359c0b7cdb955c84937156c020ac6e9af5
This does not include certificates, private keys etc. which are still
saved in the KeyStore with the encryption the user requested for them.
Makes connecting to lockdown vpn before user unlock possible.
Bug: 26108660
Change-Id: I56c1672c7a41e761c2791584b99900aff51b59e4
Currently, if the user clicks "forget" on the configuration
dialog for the profile that is currently being used by the
always-on VPN, we don't disable the lockdown VPN, and we crash
on next boot because ConnectivityService tries to start
LockdownVpnTracker with an invalid configuration.
Fix this by removing the LOCKDOWN_VPN variable in the keystore
(which disables the always-on VPN), and notifying
ConnectivityService.
Bug: 23625458
Change-Id: I3545286c9fc23517306aa94607a4b2cb55cc56c4
VPN apps are shown alongside configured VPNs now. The requirement that
a password is set is now only enforced when setting up a configured
VPN as this is not necessary for apps.
Some UI redesign.
Bug: 19573824
Bug: 17474682
Bug: 19575658
Change-Id: I02bd977136929647d65b9784fb4cc5df24b45428
