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.
the startIo() call after scanning a burner account was just missing,
putting the app for a second to background fixes the issue,
so it was maybe not that visible.
the issue was probably introduced on the switch to async,
before, startIo() was not existant.
B. Petersen