the system camera has usually more features (flash, physical zoom, filter)
and is less buggy than the mostly unmaintained built-in one.
also, the system camera seems to be more supported
(isDeviceSupported() is not needed) and does not require to ask for permission.
there is still a switch in "advanced settings" to use the old built-in camera,
however, at some point we may remove the old code completely.
* add DcBackupProvider add receiveBackup() wrappers
* add 'Add Another Device' item to settings
* add android-ifaddrs
core-rust uses getifaddrs() which is not available on android ndk.
pull in the code from https://github.com/morristech/android-ifaddrs
that provides an implementation.
* add BackupProviderActivity
* make SVG-hack reusable
* add BackupProviderFragment
* prepare scanning backup codes
* Revert "add android-ifaddrs"
This reverts commit 33b1424427620396f282805d37f8e05c67758546.
* more logging
* call receiveBackup() on scanning DC_QR_BACKUP
* Fixup for recvmmsg fallback
* protect BackupProviderActivity by system secret
* show transfer progress as provided form the core; hide qr-code once scanned
* add a permanent notification for the provider
* clarify what we are waiting for
* add a permanent notification for the receiver
* ask before finishing BackupProviderActivity
* it is fine to cancel the abort question by tapping outside the alert
* remove outdated comment from 'keep screen on'
* add and check TRANSFER_MODE
* rename BackupProviderActivity to BackupTransferActivity
* use our base activity
* start/stop IO in base activity
* use BackupTransferActivity also for scanning
* add BackupReceiverFragment
* show detailed transfer progress
* show details instead of percent during preparation, for now
* launch chatlist and remove welcome when transfer is done
* redirect to chatlist automatically after transfer succeeded
* reword
* make log accessible from send and receive activities
* bump version
* show error if backup provider creation fails
* remove unneeded format()
* show some context in the errors alerts, hide QR code sooner
* calculate transfer percentage as specified
* show a 'close' instead of a 'back' button to make visually clear, things are aborted (there is a quesion anyway)
* add option to copy backup-qr-code to clipboard
* remove vague retry statement, core will show a detailed error soon
* warn about QR codes on clipboard getting invalidated
* make basic strings translatable
* add troubleshooting menu item (once help is evolved, it may be a more visible button, may be localized, may be offline)
* rename to backup_transfer_fragment.xml
* add detailed instructions
* move 1,2,3 layout to the .xml
* fix layout
* use text size used elsewhere
* do best effort to show SSID on sending device
* make SSID code reusable for receiver
* adapt to otherwise used font style
* show ssid also for receiver
* minor refactorings
* make qr code subtitle translatable
* tune down 'same network hint' on scanning device
* add progress bar to provider
* add progress bar to receiver
* bump version
* use 'Add Second Device' wording
this seems slightly catchier as "Add Another Device"
and has less "A" esp. in "Add as Another Device" :)
also at least translation to german seems nicer ("Zweitgerät"),
most ppl will use max. two devices, but even if more,
that should still be fine.
this was also the first intuition also by other devs in their mockups,
so we'll give it a try.
* use "Exporting/Preparing/Prepared Account" wording
let's give that a try - "Account" is also widely used,
so that seems to make some sense.
even if not 100% fitting,
it seems better than introducing the new term "Collection".
* refine abort question
* Update res/layout/backup_provider_fragment.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupProviderFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupReceiverFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupTransferActivity.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* Update src/org/thoughtcrime/securesms/qr/BackupReceiverFragment.java
Co-authored-by: Hocuri <hocuri@gmx.de>
* remove string duplicate
* refine 1,2,3
* simplify string ids
* focus on what matters
---------
Co-authored-by: link2xt <link2xt@testrun.org>
Co-authored-by: Hocuri <hocuri@gmx.de>
* add "developer mode" preference
* activate WebContentsDebugging also after restart
as the preference option is persisted,
we should call setWebContentsDebuggingEnabled() not only on flag changes.
* capitalize option name, shorter description
* prefer 'can' over 'may'; the latter is very formal
* add Prefs.isDeveloperModeEnabled()
Co-authored-by: B. Petersen <r10s@b44t.com>
* add broadcasts ffi
* add 'broadcast' options to menu, chat, profile etc.
* generate initial broadcast names
* reword broadcast hint
* make 'Broadcasts Lists' experimental; while on that, also add a confirmation dialog to the location streaming switch (wording taken from ios)
* Update res/values/strings.xml
Co-authored-by: Hocuri <hocuri@gmx.de>
* comment on strings.xml
* tweak 'experimental' appearing, avoid the 'test tube'-emoji that is not supported on many devices
Co-authored-by: Hocuri <hocuri@gmx.de>
* add download-ffi methods
* add 'Download' button for incomplete messages
* show 'downloading' animation
* make download_limit configurable
* set button to 'disabled' and text to 'Downloading...' on downloading; color does not really reflect that yet, but that can probably be tweaked by xml
* make 'download message body' translatable
The non-squashed original commits are available at 243bd3a56:
* First, quick and dirty version
* Basic HTML connectivity view
* Codestyle, automatically refresh
* Make it accessible from the settings
* Improve usability
I did some user-testing with my family, these are the results:
- Added an emoji to the html page (red dot for not connected, and so on)
- Adapted error messages for SMTP:
"Not started" -> "(You did not try to send a message recently)"
"🟢 Connected" -> "🟢 Your last message was sent successfully"
- "Not connected" is misleading, because they think that this means that there is no internet connection.
But "Not connected" can have other causes, like, a not responding server or a changed-but-not-updated-in-DC password
Possible solutions:
- "Not connected" -> "Not connected with gmx.de" (or whatever comes after the '@' in configured_addr). The problem: some people have an own domain for their emails, but no own servers. "Not connected with <your domain>" and might make them think that the problem is that DC tries to connect to the server <your domain>, while the server is hosted at Strato.com.
- We can ask the system whether there currently is network and then show another error message. The problem: Sometimes the system is wrong.
* Remove error_network
* Remove server_response string
* Move `getConnectivitySummary()` to `DcHelper`
* Implement the changes we agreed on
* Remove string error_no_network
* small fixes
* Remove screen lock feature, move the two remaining "App access" options into "Advanced"
Locking the app was removed a long time ago, so in "App access" in the
settings, the only two remaining items were "Screen security" and
"Incognito keyboard".
* Remove the now-unused strings
* remove app-access-category from main settings screen
Co-authored-by: B. Petersen <r10s@b44t.com>
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)
- For chat menu item, use already translated auto-delete string.
- For experimental setting, use untranslatable hard-coded string.
- Introduce a new translatable string for ephemeral dialog title
reason is that ppl are pretty annoyed by the
permanant notification, that might have been expected and that would be okay.
but, more worse, for whatever reasons, this drains more battery on some systems
than having just "allow consuming battery" enabled,
maybe some system do not go to doze mode because of the permantent-notification.
anyway, to avoid initial annoyances, we switch back to
- asking the user to "allow consuming battery"
- having a 15 mintues or so polling interval (as on iOS)
but, in contrast to 1.3, we now still have the _option_ to
enable a permantent-notification that user can enabled if everything else
described at https://dontkillmyapp.com does not work.
the "smart" permantent notification from 1.3,
that are only shown under some circumstances, however, are gone.
they are not realiable, eg. we did not use them when "consume battery"
was enabled - which is not sufficient on various "modern" systems.
but the main reason is that _if_ the user enables a permantent notification,
this can also be regarded as a hint that things are up and running.
adbenitez