From Marino Meneghel:
When updating to core version 9.8.0 (PR#263) the "flow" tests started
failing with the following error:
> Could not launch intent Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x14008000 cmp=ch.protonmail.android.dev/ch.protonmail.android.MainActivity } within 45000 milliseconds. Perhaps the main thread has not gone idle within a reasonable amount of time?
which resulted being caused by the splashscreen
`setKeepOnScreenCondition` blocking the UI thread due to being
continuously evaluated. This somehow prevented the `Launcher` composable
from retrieving any state updates from its ViewModel, which in turn
caused the redirect to the "login" activity not to happen.
While the root cause for this to start failing was not pinpointed
with confidence, the main suspect is the update / addition of some compose
dependencies (compose 1.2.0-rc02 -> 1.3.2, compose-foundation 1.3.1 and
compose-material 1.3.1 added).
The fix consists in changing the behavior of the splashscreen to only
stay visible while the `LauncherViewModel` is being initialised
(represented by the `Processing` state) and remove it afterwards.
This seems to be a better behavior than the previous one, as instead
of leveraging the fact that launching the Login activity would pause
`MainActivity` (effectively freeing the UIThread from the splashScreen
stalking) it actually only keeps the splash screen shown for the minimun
needed time and then delegates to the "Launcher" the responsibility of
choosing what to show.
When the pinned key has no valid encryption key, the app
should not use it to send mail, instead it should warn the user
that the pinned key is invalid.
Because of third-pary signatures, like the ones from ProtonCA,
comparing full keys would be problematic when the signature changes.
We revert to comparing fingerprints for now, in the future we will
need to strip third-party signatures before comparing keys.
The send preferences should check the full keys, because a key
could have changed its subkeys or encryption preferences, but
kept the same fingerprint.
So far mail clients were supposed to encrypt by default if the server
returned untrusted encryption keys (usually retrieved from WKD).
The web client will add a feature to allow users to disable encryption
for those untrusted keys, in which case the message would be sent in
plaintext.
This is signaled by adding the 'x-pm-encrypt-untrusted: false' flag to
the signed part of the contact.
MAILAND-3015
In the case of internal keys or wkd keys, we encrypt and sign email by defaults.
The contact encryption flags will only be relevant when using a pinned key.
Mail web has a bug when creating contacts from WKD clients, which means
that the android client was ignoring the encryption key.
We fix it by encrypting by default if the encryption flag is not set in
the vcard.
Zorica Stojchevska
Neil Marietta
Zorica Stojchevska
proton-ci
Marin Thiercelin