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)
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.
B. Petersen