When targeting Android 15, edge-to-edge is the default and when targeting
Android 16, apps can't opt-out from this anymore. So we update our views
and enable edge-to-edge also for older versions (avoids the black bar
behind the system UI at the bottom). For most views we just use automatic
margins via android:fitsSystemWindows (or programmatically via
setDecorFitsSystemWindows). However, for the profile lists and log views,
we take some extra measures that allow the lists to go behind the bottom
system UI. Appropriate padding is applied at the bottom of the lists so
the last item(s) can be scrolled into full view.
Also removed on Play so the app does not show up when people search
for these keywords (they tend to not read the actual description and
then are surprised that neither protocol is supported).
Newer NDKs have RISC-V as experimental ABI (not enabled by default, see
next commit). If we don't have a mapping for a specific target, OpenSSL
falls back to 'android-arm', so that won't really work (interestingly,
it does build).
These sockets are closed immediately again, so no need to re-protect them
during roaming events.
References strongswan/strongswan#1691
Fixes: 6d87a86510 ("android: Use new sockets to determine source IP")
The callbacks provided via ProcessLifecycleOwner are only triggered when
Activities are started. However, when Android triggers the Always-on
VPN it directly starts our VpnService subclass, no Activity. So the
configs were not loaded and the VPN couldn't be initiated with a managed
profile. This ensures the config is loaded right from the start of
the app. And by registering for modifications in onCreate() we can also
use the correct config if the app is never started in-between changes to
the managed profiles and triggering the Always-on VPN.
Besides being clearer, this fixes issues with GCC 15. The latter uses
C23 by default, which changes the meaning of function declarations
without parameters such as
bool return false();
Instead of "this function takes an unknown number of arguments", this
now equals (void), that is, "this function takes no arguments". So we
run into incompatible pointer type warnings all over when using such
functions. They could be cast to (void*) but this seems the cleaner
solution for this use case.
The service implementation with its handling of reauth callbacks and
no-DNS TUN device etc. can't handle make-before-break reauthentication
at the moment.
Unspecified settings should be set to null, while some MDMs might send
them as empty strings, which could cause issues (like an empty password
or trying to parse an empty DNS server address).
This can happen with empty strings, which might be set for managed
profiles, which caused the refcounting to be askew and the resolver not
to work after connecting once because it was flushed and disabled.
Tobias Brunner