The button to view the log is now below the status info. And since the
IMC results are just below that we don't need a special handling for
that anymore.
This can happen on systems (e.g. Android 7.x) where Always-on VPNs are
triggered right after booting before the KeyChain is unlocked by the user.
Retrieving the certificate chain or private key then fails with
"KeyChainException: IllegalStateException: keystore is LOCKED" until the
user unlocks the screen once.
The built-in client actually also fails in this situation (e.g. with XAuth
RSA), it tries three times then stops and shows an error notification.
With Android 8.1 this isn't triggered after a reboot until the device
has been unlocked once (solving the issue with the key store) and traffic
may optionally be blocked by the user until the VPN is established.
There are still some issues (e.g. password prompts and fatal errors), and we
might need some workaround for older Android releases.
Only if there is no currently active (or previously active) profile does
this currently operate on the configured (or stored most recently used)
profile. This way it's possible to use a different connection and
quickly disable and re-enable it again. When unlocked the profile name
is shown, when locked a generic text is used (this detection doesn't seem
to work 100% reliably). To disconnect, the user is forced to unlock the
device, connecting is possible without, if the credentials are available
and no fatal error occurs (it even works with the system credential store,
at least on Android 8.1).
Note that the tile is not available right after a reboot. It seems that
the system has to be unlocked once to activate third-party tiles (will
be interesting to see how this works together with Always-on VPN).
Unfortunately, setLockscreenVisibility() doesn't seem to have any
effect. So the full notification is shown unless the user manually
configures the notification settings.
This allows us to add tiles to Quick Settings and enabling the Always-on
VPN feature in the VPN settings (both require API level 24, but 26 will
be required as targetSdkVersion later this year).
Unless there are profiles created with old versions of the app (< 1.8.0)
that were never updated since, all profiles should already have a UUID
assigned. If not, we do that now with a DB migration.
This is either because a third-party VPN app has the always-on feature
enabled, or because the user denied the permission in the system's confirmation
dialog.
If the always-on feature is enabled for a connection of the built-in VPN
client we get an IllegalStateException, for which we show an updated and
clearer error message.
armeabi has been superseded by armeabi-v7a and the MIPS ABIs were removed
with the latest NDK (r17), after being marked deprecated for a while.
By not specifying APP_ABI we build for all non-deprecated ABIs.
In scenarios where the server accepts client certificates from dozens or
even hundreds of CAs it might be necessary to omit certificate request
payloads from the IKE_SA_INIT response to avoid fragmentation.
As it is rarely the case in road-warrior scenarios that the server
already has the client certificate installed it should not be a problem
to always send it.
Tobias Brunner