While combining the actions could cause duplicates (while the SA is
initiated, traffic might trigger the trap and the initiation of another
CHILD_SA), the previous commit should avoid most duplicates. If reuse_ikesa
is disabled, duplicates can't be prevented, though.
This is required when targeting Android 11 (API 30) in order to see all
packages, which we use to allow selecting apps ex-/included from VPN
profiles and for the EAP-TNC use case.
As suggested by the Android docs, we use a global thread pool and handler
to avoid recreating them repeatedly. Four threads should be more than
enough as we only use this to load CA certificates when the app starts
initially and to load user certs when editing a profile.
This will be mandatory for new apps in August and for existing apps
in November. However, several classes like AsyncTask are now deprecated
so this needs some work to avoid warnings and problems in the future.
The lint version used on our GitHub build hosts reported these errors:
Error: Value must be ≥ 0 [Range]
db.update(TABLE_VPNPROFILE, values, KEY_ID + " = " + cursor.getLong(cursor.getColumnIndex(KEY_ID)), null);
That's because get*() expect a valid index >= 0 but getColumnIndex()
can return -1 if the column name doesn't exist.
If the peer deletes the CHILD_SA, we recreate it due to the close
action. However, if we create a new TUN device, we do so with a new
VpnService.Builder object and on that the DNS servers were never applied.
The latter happened only on the fly in the attribute handler when an
IKE_SA was established. Now we do this explicitly when creating the TUN
device, like the virtual IPs and routes. While we could avoid the
recreation of the TUN device if the CHILD_SA is recreated, there is the
theoretical possibility that the remote traffic selectors change. This
way we also avoid adding stuff to the builder in different places.
Fixes#3637.
For apps targeting Android 10, where a method to change this was added, the
default changed so that all VPN connections are marked as metered. This means
certain background operations (e.g. syncing data) are not performed anymore
even when connected to a WiFi. By setting this to false, the metered state
of the VPN connection reflects that of the underlying networks.
The parser is quite picky and e.g. doesn't accept UUIDs without dashes.
Even without a specific error, this at least points the users into the
right direction.
Fixes#3583.
If the activity is not active when the service connection is
established and handleIntent() is called, the activity's state is already
saved and any fragment transaction would result in an illegalStateException
due to state loss. We just ignore this and wait for another initiation
attempt (via onNewIntent()).
With the flag set, we basically ignore the resent intent, which is not
ideal if we have not yet actually started another activity. The information
dialog we show first would disappear when closing and reopening the app
or even just rotating it (we hide all dialogs when receiving an intent),
but since the flag was restored, the dialog was not shown again even
when attempting to start other connections.
Tobias Brunner