Doing this from the main UI thread (which delivers the broadcast) might
cause an ANR if there is a delay (e.g. while acquiring a mutex in the
native parts). There might also have been a race condition during
termination previously because Unregister() was not synchronized so there
might have been dangling events that got delivered while or after the mutex
in the native parts was destroyed.
The file format is documented on the wiki.
URLs to .sswan files may be intercepted and downloaded files with a media
type of application/vnd.strongswan.profile may also be opened (the file
extension doesn't matter in that case). Whether downloaded files for which
the media type is not correct but the extension is .sswan can be opened
depends on the app that issues the Intent. For instance, from the default
Downloads app it won't work due to the content:// URLs that do not contain
the file name but when opening the downloaded file from within Chrome's
Downloads view it works as these Intents use file:// URLs, which contain
the complete file name (the latter requires a new permission).
This avoids triggering additional errors via e.g. ike_updown() that
might cause the error message displayed in the GUI to change if the
status fragment is recreated.
References #2134.
When certificates are imported via Storage Access Framework we did handle
the selection directly in onActivityResult(). However, at that point the
activity might apparently not yet be resumed. So committing
FragmentTransactions could result in IllegalStateExceptions due to the
potential state loss. To avoid that we cache the returned URI and wait
until onPostResume() to make sure the activity's state is fully restored
before showing the confirmation dialog.
onSaveInstanceState is apparently called after pausing the fragment and after
that committing any FragmentTransactions causes an IllegalStateException.
We could use commitAllowingStateLoss() but that's not really necessary
as we don't need to update when we are not active anyway. We also don't
update the view directly after registration as this happens
asynchronously, i.e. we might be paused when it finishes.
Because the support library creates its own layout manually and uses
different IDs than the list_content layout we can't use the method we
used previously (and which is actually recommended in the docs).
For instance, onAttach() with an Activitiy as first argument was deprecated
with API level 23. However, the overload with a Context as first argument
does obviously not get called on older API levels. Luckily, the classes
provided by the support library handle that for us.
This adds a workaround for an issue on older platforms where the list is
not properly styled with colorAccent. Similarly applies to borderless buttons.
The term "gateway" is unfamiliar for most new users (or they confuse it
with the default gateway of their network) but they usually know that
they want to connect to a "server".
This mainly changes the color of the appbar (colorPrimary), the color
of the status bar (colorPrimaryDark) is black like the default.
The accent color (colorAccent) used for controls like buttons and check
boxes is a slightly toned down version of the default.
There is no AppCompatProgressDialog class as the use of ProgressDialog
is discouraged (instead progress bars should be placed in the layout directly).
To display the current ProgressDialog instances correctly on systems < 21 we
modify the window background color.
While building against this level in general would break our app on
older systems, the NDK will automatically use this level for 64-bit
ABI builds (which are not supported in older levels). So to build
against 64-bit ABIs we have to support this API level.
In Java all integer types are signed, when a negative integer is casted
to a larger type (e.g. int to long) then due to sign extension the upper
bytes are not 0. So writing that value to a byte array does not produce
the expected result. By overloading the putX() methods we make sure to
upcast the values correctly.
Tobias Brunner