for various reasons,
screen-lock will be removed completely in one of the next versions.
- if screen-lock was enabled before, add a warning
and keep the options (user can switch screen-lock on and off
until it will be finally removed)
- if screen lock was disabled before,
hide the corresponding options,
(the user will not be able to enable screen-lock anymore)
reasons for removing are:
- hard maintainability on different android versions, see discussions at
https://github.com/deltachat/deltachat-android/issues/1208 and
https://github.com/deltachat/deltachat-android/pull/1279 and
https://github.com/deltachat/deltachat-android/pull/1319 and offline.
ftr, also the used api createConfirmDeviceCredentialIntent() is deprectated,
so another set of api calls would be needed in the soon future.
- compared to the effort, few security is added,
the function is only available if the system is protected anyway,
one just have to repeat the system secret.
- might even worsen overall security - if app login secret is peeked,
and attacker will also have the system secret.
- the functions stands in the way of moving forward to a
cross-platform solution (however, not sure if this will really come)
the warning about outdated apps
was pretty unreliable in the past -
because of too short timings
and also because of the "installation date"
and the fact that an "installer" was used, is not always reliable.
also, the "installer date" could be wrong -
if the installation was done when the clock was altered badly.
as we cannot rely on the things the system provides here,
we move the whole thing to the core at
https://github.com/deltachat/deltachat-core-rust/pull/1901
which has also the advantage that this is done for all uis then.
errors that should be shown to the user
come from DC_EVENT_CONFIGURE_PROGRESS(data1=0) as data2 now;
there is no need to show the captured error any longer
(which was unreliable and hard to handle from core site).
there is some capturing-code left as needed for other parts,
but it is not used for configuration anymore.
- having this is the text has the advantage that the hint is
also in place when the log is already exported,
editing is maybe even easier later
- if needed, we can make the hint translatable at a later point,
not sure, however, if this is useful as most of the log is english anyway.
while it is more straight-forward to let the system ask the user directly -
as we do for most other permissions -
this is probably not favorable for requesting ignore-battery-optimization:
- other permissions requests are preceded by a clear user intention -
tap on the camera, record voice etc.
so it is clear to the user why a permission is needed.
this is not true at the moment after installation
(maybe the moment can be improved, btw)
- different systems have completely different text,
partly focusing on "battery drain" - it is not clear to the user
what would be the advantage of that
- some guidelines say, user interaction is needed before querying permission.
there is room for interpretation, of couse,
however, adding a rational with a "continue" button
seems to fit better to these guidelines.
unfortunately, auto-linking such as Linkify.addLinks(WEB_URLS...)
replaces custom-links set before by Linkify.addLinks(custom-pattern).
calling custom-linking after auto-linking may be too inaccurate
as in case of bot-commands such as /xkcd_123456
are treated partly as a phone number.
skipping auto-linking is hard as there are lots of things to do to get a
similar experience, see #1600.
finally, we solve the problem by replacing URLSpan by some other span after.
in fact, we do that anyway to get a different long-click behaviour.
the only important thing is that the span-replacement
must not be derived from URLSpan.
B. Petersen