Make it possible for apps to send SMS

[newtewt]

Because of restrictions to the play store and sending sms we need a way to build the android app so that the SMS sending/receiving features are removed. This should be based on flavor as some projects will need it and will have to get the app outside of the play store.

[garethbowen]

Nobody needs SMS right now, in part because of the draconian restrictions of the Play store, so I wonder if we remove the permission from the app for 3.5.0 and include in the flavour when it's needed.

[newtewt]

To test medic/cht-core#4812 we need a way to enable the permission and request access. This could be done locally instead of built and sent to the app store.

[newtewt]

I was able to build a version locally that asked for permissions using the code already there. I don't think this needs to be in 3.5.0.

[garethbowen]

I agree. Moving to 3.7.0

[abbyad]

The SMS permission android.permission.SEND_SMS is not currently in our master branch so does not need to be removed. We do however need a strategy for including the permission when needed. A suitable approach could be to include permissions on a per flavor basis, as described in this tutorial: How to Implement ProductFlavor-Dependent Permissions with Gradle.

An option to consider when the app does not have the permissions to send SMS directly would be to fall back to using the Android intents method, which would present the message to be sent in the default messaging app. There are several drawbacks to this, listed here with possible solutions:

1. Requires user to submit the message: We could make the sending of the SMS more explicit in the app UI, so that the user is choosing to send the SMS, in which case they are likely to go through with the sending via the messaging app.
2. Exposes the content to be viewed: This could be avoided by encoding the message so that it is not human readable, and decoding when the server receives the message.
3. Message content could be edited: We could have a checksum or hash to detect tampering of the content.

Although the intent method is less streamlined than with the SMS permission, this may be a suitable alternative as a fallback when data connectivity is unavailable.

[abbyad]

Just noting that the fall back to using intents should probably be split off into a separate issue, which could be scheduled separately.

cc @MaxDiz

[garethbowen]

Deprioritising this while we work out how to do SMS.

[abbyad]

After discussion with @garethbowen and @yanokwa it seems as though the best plan is to create a side loaded app that handles sending SMS via an Intent. Instead of relying directly on the default messaging app, we'd explicitly call a (side-loaded) app whose sole purpose is to relay the SMS. We could optionally fall back to sending via the default messaging app if the relaying app is not present. In this case the message content would need to be converted so that is it not human-readable and contains a checksum to know if it was altered.

Some considerations:

• The app should require very infrequent updates once installed since it will not necessarily be managed by an app store. As a result it should be as small and simple as possible to reduce complexity and defects.
• The app will need to reliably send SMS, despite Android restricting activity of background apps and services to increase battery life.
• It is preferable to not have a UI since UX should be handled by the calling app, and UI elements may require translations (and updates!). That said, a UI element like a notification would be acceptable if required to have the app/service run by Android.