Research spike on running in the background continuously on Android

[holmesworcester]

Goal: The Android app runs in the background well enough to send files, reliably receive notifications without a push notification service, and provide “liveness” to the network.

We should do some research to see how we can achieve these things. The end result of this ticket is a list of approaches we have proven do not work and a proposal for how to proceed.

User story 1: “The Manager”: a manager wants to be able to provide quick responses to her team when they mention her. If the notification does not always arrive quickly, she cannot use Quiet. Quiet should always receive incoming notifications, without a push notification service.

• If someone sends a message to a channel and notifications are enabled, she should see a notification within 3 seconds.
• When she restarts her phone she should see notifications, whether or not she opens Quiet. These notifications should appear within seconds or, if not possible, minutes.
• Whenever Quiet is not able to receive notifications for some reason, she should see some indication of this, e.g. a notification saying “Quiet not connected–reconnect?”

User story 2: “The Always-on Phone”: a team wants to make sure there is always a place to sync messages, but they don’t have a spare computer to use, so they join the network on an Android phone and leave that phone plugged in 24/7. That phone should remain reliably connected to the network.

• There should be something the user can do to ensure Quiet will stay connected 24/7 for multiple days, syncing messages.
• Phone stays connected for 7 days (indefinitely)
• This works on any phone that runs Quiet

User story 3: “Sending an image”: a user takes a photo, sends it with Quiet to others in their team, and puts their phone in their pocket. The photo is important and must be delivered to all online users.

• The photo is always delivered
• The app is not killed while the photo is being delivered

User story 4: "Never opening the app again": a user installs Quiet, joins a community, but restarts their phone and forgets to open the app ever again. Someone else sends them a message in the community. Will they ever see it?

• They see the notification at some point again, even though they never open the app
• Ideally they see the notification fairly soon after it is sent

IDEAS FROM BRAINSTORM:

1. @siepra has set up workers with the goal of seeing when the backend is running, but they aren't working as expected, because they aren't firing a notification. Get more logs so we know whether they are working.
2. Get logs on when workers run
3. Figure out how to get existing workers to fire a notification when the app UI has been killed.
4. Log data locally about when Tor is running, when we have connected to a peer
5. Try to get workers to run backend and see if a worker can connect and replicate data (right now workers only check if it is running) ... then confirm that data replicated by worker is visible in app.
6. Try another path to achieve above goals, e.g. foreground services.
7. These issues might be helpful, but we shouldn't rush in to them: Developers should have informative "liveness" logs (desktop, mobile) #933, Developers should have community-level data on online status #934, User should be able to see her online status #506

[holmesworcester]

Relevant docs:

1. https://developer.android.com/guide/components/foreground-services
2. https://developer.android.com/reference/androidx/work/Worker
3. https://developer.android.com/reference/androidx/work/WorkManager
4. Anything else...?

[siepra]

see TryQuiet/ZbayMobile#93

[holmesworcester]

Our ideas for things to look into:

• Workers that run periodically (for 1 and 4)
• Foreground services that monitor and tell user when they are offline (for 1 and 3)
• Foreground services in their most aggressive form that keep our threads alive somehow if the phone is charging and not being used for anything else (for 2, maybe?)

[siepra]

I think we should start with getting more information and control over our Threads - I've got some ideas on how to achieve that

[siepra]

I set up workers which runs every 15 minutes (starting in 10 minutes from the app start). They display information about backend process status. If data port is no longer occupied, worker should trigger a push notification informing that app no longer works

[siepra]

We want to confirm workers works in a desired way (they are capable of performing some work when backend thread is dead) and then find a way to gather similar information about tor process status within the same worker

[siepra]

Notifications triggered from worker may need access to UI thread as they appear randomly when the app is being re-started or phone being unlocked. It'd be good to check that by reading documentation...

[siepra]

I received the notification but app seemed to keep working so maybe checking data server port occupancy is not good enough

[siepra]

I think the good idea may be to dump workers logs into a file and gather them for some time to have the overall picture of what happens to the app and it's threads

[siepra]

I added dumping worker logs to a file. To upload this file from android device to your local file system run adb -d shell "run-as com.zbaymobile.debug cat /data/data/com.zbaymobile.debug/files/worker_logs.txt" > Desktop/worker_logs.txt

[siepra]

According to documentation, workers should work under every circumstances but in practise it's not so straightforward https://stackoverflow.com/questions/50682061/android-is-workmanager-running-when-app-is-closed

[siepra]

Force stopping the app (which is basically killing its process) results in erasing queued works, which means workers won't work until user starts the app again. Usually it's user's decision to perform a force stop, but different manufacturers provides their own practises of managing resources...

[siepra]

Workers seems to run reliably every 15 minutes but the question is are there situations where workers run but backend and tor are dead? (edit: yes) If so, we may be able to bring them back with the help of workers

[siepra]

I've been testing workers during the night and those are my observations:

• Workers worked reliably (I collected all of the logs - 4 logs per hour for 17 hours)
• Data server closed around 2 am (workers remained alive)
• Sometimes I didn't know if I'm not connected to anyone or if the app is broken (missing network state info)

[holmesworcester]

Can we run backend in workers? Or start it with workers?

[siepra]

Note: we treat user story 4 as a separate issue #985