Split out of #732, where these turned up while checking whether the lockdown case is already covered. Both are small and independent of that issue's proposal.
1. The enable-time check is SDK_INT < S only.
ActivityMain.java:294-317 reads always_on_vpn_app / always_on_vpn_lockdown from Settings.Secure and, if TC is the always-on app with lockdown on, un-checks the switch and shows msg_always_on_lockdown. That is the strongest signal we give — it refuses to enable at all.
It is guarded on Build.VERSION.SDK_INT < Build.VERSION_CODES.S, because those keys are restricted to system apps from S onwards. So on every reasonably current device the check silently no-ops, and the only remaining coverage is the onboarding slide (ActivityOnboarding.java:181-198), which a user may have clicked through months earlier — possibly before enabling lockdown at all.
Detecting lockdown on S+ is not directly possible; the usual proxy is inferring it from excluded apps having no connectivity, which is more machinery than the problem is likely worth. Worth deciding whether we want any S+ signal at all, or whether onboarding plus the troubleshooting page (strings.xml:82) is deliberately where this stops.
2. title_lockdown_enabled is defined but never referenced.
strings.xml:391 defines title_lockdown_enabled ("Traffic is locked down") and nothing in app/src uses it. Meanwhile troubleshooting_alwayson_desc (strings.xml:82) tells the user "A notification will appear if this is detected." No such notification is posted, so the troubleshooting text promises behaviour we do not have.
Either wire up the notification or correct that sentence — but the two should agree, and the string is dead weight as it stands. Note that on S+ we cannot detect the condition to notify about (see 1), so correcting the text is the cheaper of the two.
Split out of #732, where these turned up while checking whether the lockdown case is already covered. Both are small and independent of that issue's proposal.
1. The enable-time check is
SDK_INT < Sonly.ActivityMain.java:294-317readsalways_on_vpn_app/always_on_vpn_lockdownfromSettings.Secureand, if TC is the always-on app with lockdown on, un-checks the switch and showsmsg_always_on_lockdown. That is the strongest signal we give — it refuses to enable at all.It is guarded on
Build.VERSION.SDK_INT < Build.VERSION_CODES.S, because those keys are restricted to system apps from S onwards. So on every reasonably current device the check silently no-ops, and the only remaining coverage is the onboarding slide (ActivityOnboarding.java:181-198), which a user may have clicked through months earlier — possibly before enabling lockdown at all.Detecting lockdown on S+ is not directly possible; the usual proxy is inferring it from excluded apps having no connectivity, which is more machinery than the problem is likely worth. Worth deciding whether we want any S+ signal at all, or whether onboarding plus the troubleshooting page (
strings.xml:82) is deliberately where this stops.2.
title_lockdown_enabledis defined but never referenced.strings.xml:391definestitle_lockdown_enabled("Traffic is locked down") and nothing inapp/srcuses it. Meanwhiletroubleshooting_alwayson_desc(strings.xml:82) tells the user "A notification will appear if this is detected." No such notification is posted, so the troubleshooting text promises behaviour we do not have.Either wire up the notification or correct that sentence — but the two should agree, and the string is dead weight as it stands. Note that on S+ we cannot detect the condition to notify about (see 1), so correcting the text is the cheaper of the two.