How to help improve Android client?

1

Hi,

I find the Android client on mobile phone almost usable:

  • Impossible to call a contact. Calls do not reach recipients. I need to reboot the phone to start a call. And to call by phone them first to tell them that I’m going to call them with Jami!
  • Receiving multiple invitations for existing contact.
  • Conversations don’t update for days. Or duplicate contacts in the list.
  • The application is non reactive. Sometimes the camera starts, sometimes it doesn’t.
  • Application closes unexpectedly in a call. Following call is without video…
  • Default settings on Android let the application in deep sleep and calls don’t awaken it.
  • etc.

Is it possible to capture and store the application logs on the phone when such strange behaviours happen? It seems we have to start logging before using Jami but this setting does not stick between crashes, and you can’t have multiple log files.

How can we help improving this situation to get the Android client reliable and usable?

–
Pierre Métras

2

First of all, I’d encourage you to stick with Jami. It is an excellent piece of software. I run it on Android and Linux. Having got the various Android settings right, I can report it works well and consistently.

Next, I think that your issue is possibly centred around settings in Android, as you’re using Android. All power saving for Jami must be disabled, and connectivity to the internet retained as much as possible. Jami must be “awake” in the background.

The users I know of on Apple phones have almost no chance of it working well. It seems there is no way to keep Jami awake and backgrounded.

Regarding duplicate invitations, this is probably related to this.

I don’t find an issue with the camera, but then again I rarely use it.

There is indeed a log capture facility. It’s in the settings of Jami.

Do remember… there is no central server with Jami. You are the server, so if you’re offline for any reason, things won’t happen.

2 Likes
3

Ideally you can get the logs and report these issues using Gitlab:

https://docs.jami.net/user/bug-report-guide.html

Just remove your personal data from the logs (your Identifier,etc.)

4

The problems with Android are

  1. [strike]the log setting does not seem persistent and it is not generally enabled when a problem occurs[/strike].
    [EDIT]
    What I wrote is not correct. I just went to the log settings on my phone and I was suggested to disable it. When I accepted it, I saw the log content starting from the time I enabled it. But when I re-enabled it, it started anew… Probably because the log file was big, the display was empty with only the Disable logging prompt
    [EDIT]
  2. the Android app seems unresponsive most of the time. Or perhaps I don’t understand the user interface. For instance, I had an audio call+chat with a contact a few days ago, but the Android app says that I received the invite from that contact 37s ago. This message has been displayed since the call (I don’t remember if it was the case before). And this contact is part of my address book for a few months…
5

My Android phone is always on. Like most of my contacts that I convinced to install Jamy on their Android phones. So ideally, it should work; but that’s not the case…

My contacts are not technically inclined, and they use the default Android configuration (app downloaded from Google Play). I can’t see them online though they most probably are. My conclusion is that their Jamy app is deep sleeping, and that the default Andoid configuration is not correct.

Though other Linux devices on the LAN are turned on or off, their status on the Android phone and the conversations are not updated…

I’ve changed my configuration a few times while doing tests between Android and Linux. In the end, here are my settings (the wording could be different as I have to translate from the French version on my phone):

  • Account shared with 4 devices
  • Profile online
  • Advanced network parameters
  • System
    • Pushed notifications from Google servers: On
    • Run at start: On
    • Run as background task: On

What would be the optimal (default no-brainer) settings so Android phones can see each others? I can work with my contacts to use these settings and check if that configuration really works.

6

Hi there.

When I said “…if you’re offline …things won’t happen”, I meant your Jami instance.

I find that this works for me:

Android:

  • Jami = no battery optimisation
  • Anything else in your particular Android flavour which might affect the “being online” status of Jami = off

Jami:

  • network - everything off, except TURN, which is on (I think this is the default setting)
    Note that with DHT off, I understand you don’t need pushed notifications.

As for account sharing, I tend to avoid this. I’ve found that synchronisation, probably due to communication outages (for whatever reason), can be an issue, and cause knock-on problems. My workaround is to have a separate account for each device, eg:

  • (device 1) “fred’s phone”
  • (device 2) “fred’s other phone”
  • (device 3) “fred’s desktop”
    … and so on.

This is not ideal, I grant you, but it works for me.

I hope this is helpful, but do feel free to reply if you need more.

:smile:

Edit:
One other thing, I have “run in background” enabled within Jami settings, too.

7

Hi guys, unfotunately I have to confirm pmetras report here…

1st, thanks for all hard work on this project - theoretically, I love jami (20 years experience in FOSS networking/coding here).

To quote James:

First of all, I’d encourage you to stick with Jami. It is an excellent piece of software.

During the last 3 years I collected most frustrating user experience with jami on Android.
The concept behind jami is excellent, but at least on Android, I was never able to use/deploy with Family&Friends.
Formerly, it was running in an Android Sandbox on SailfishOS - that’s why I haven’t started seriously investigating all my issues back then.
These days I switched to GrapheneOS - kind of hardened AOSP, which runs all other Android Apps flawlessly. So to my understanding, I can rule out being too special on my side.

I can only confirm almost every single issue pmetras lists - beside the one with the cam - I simply never tried…

I started reading Technical overview — Jami documentation - understanding what is written there.
To make things easy, I kept almost all defaults - only disabling UPnP.; N/A here.
So bootstrap, DHT proxy und TRUN in on and set to it’s defaults and Firewall grants non-terminated TLS connections. I didn’t expect any difficulties with this setup, besides it depends on centralized services provided by Savoir-faire Linux Inc. - the very opposite of what you want if you’re looking for utilizing the actual strenghs of the design of jami, no matter which single instance/organisation is providing these services - which one can easily change; which is why I like the concept.

This is my first time inspecting jami behaviour from the network point of view

What bothers me most is that “partner” state doesn’t seem to reflect reality - the green online dot absolutely has no meaning for me and most times seems to be “stuck”, in what ever state the last one was.
Likewise “messages” - You/the user gets no hints if transmittion is in progress/success/failed state - neither sender nor receiver know anything about what’s happening.
Most annoying is the ridiculously wrong timespan state information in the android version:
image

This will stay forever - whenever you look at it, you will see 0 sec, 14h or whatever it once was. No way to refresh, no auto-refresh. I cannot emphasize how stupid I think it is to display it this way - make it simply a timestamp, not a delta! It’s needless wasted resources to take care about a correct delta information - timestamp is cheap and fine.

More important, the “green-dotted” peer account was put offline on all devices yesterday!!!

What I haven’t found/understood so far is what actually happens behind the scenes. I know SIP signalling and the P2P via TURN, but I 1st need to understand how states are recorded. I don’t know/understand DHT yet. Most likely, the state is DHT backed. But what are “conversation messages”??? RTP media, like calls, or transmitted via DHT too?

I have to understand the DHT-proxy traffic first (which I currently don’t) to get an idea what really is broken here.
Currently I suspect the root cause is roaming networks/gateways, especially due to very strange IPV6 behaviour and differences in active paths.
In one of my test LANs, I don’t advertise for SLAAC, but use DHCP6 (but android doesn’t utilize dhcpv6!). There I see LinkLocal originating internet traffic - fe80::/10 for jami TURNv6 destination! No idea how much this violates IPv6 standards, but it’s a well known Android (mis-)behaviour for me. For upcoming tests,I changed the firewall to TCP6-RST (instead of ICMP6 net-unreach)…
But I have no idea what happens if I use 5G iinternet connection. Device does get global-reachable IPv6 and a CGNAT IPv4 addresses.

If somebody knows any links helping me to speed up filling my knowledge gaps, please share. Unfortunately I have only very limited time to do tests - and do build environment to do more than tests curently (for android).

Sorry for jumping across topics here - basically I want to emphasize that on android, jami isn’t usable at all for me and I’m trying to find out why it is for me and for pmetras apparently too. I guess Android is primary target for this kind of application - hopefully at least the technically versed ones can use it one day, to focus on the rest of the userbase afterwards :slight_smile:

Br, Tobi

8

Actually the green dot does NOT always mean that a peer is online:

9

I’ve opened a bug report on this yesterday. This bug can easily be corrected, but the Android client suffers from more serious ones more difficult to diagnose.

10

I have a conversation, swarm with 8 people, that used to synchronize ok for a long time (no missing message but regular notifications of new messages that weren’t new) but it stopped updating 6 days ago.

Is there any use to start logs now to track that? (not so sure).

I am also using XMPP and my contacts using Apple phones use an app called Monal, which seems to get around the problem successfully for receiving messages (since my contacts always get notified of my XMPP messages immediately).

On the Monal website, there is a presentation that explains the problem of Apple phones, saying any process is interrupted within 30s and there are some explanations on how Monal deals with that problem. I did not follow the details, they say it is not easy but doable.

Perhaps Jami could have a look a that?

11

I’ve checked the default configuration of the Android client, for my usual recipients. Jami was installed from Google Play on their phone, last year, and the configuration was never changed.

Here is what I had to change in order to see them on my phone and have a better on-line reliability.

System > Pushed notifications from Google servers: On
This option is not available on one of the phones. I have to investigate the reason…

System > Run as background task: On
This option was never set by the Jami default configuration

Advanced parameters > Use DHT proxy
Not sure if this option is really useful, but I set it.

Apart from DHT proxy option that is questionable, and possibly the first one that uses Google servers and should be replaced by a UnifiedPush one from SavoirFaire Linux, why are these options not set in the default Android configuration?

12

Do you use the GooglePlay version (you can also use the AuroraStore) or the F-Droid version?

13

Hi

I don’t have DHT proxy enabled. Otherwise I use the setting you have (How to help improve Android client? - #5 by pmetras).

I also have made sure that battery optimisation is off for Jami and ntfy.

Jami works well for me on Android. I use the install from F-Droid.

14

Thanks! I also created some bug reports, but absolutely no response at all.

For the last three releases jami simply crashes on Android when trying to call (SIP).
Jami also ignores TURN/SSTUN in SIP.
It registers with private IP, no matter what TURN/STUN is in use.

At least for internal SIP calls jami was usable on android, but that changed recently :cry:
What a pity nobody cares about android upstream. It never reached a usable state and now the partially working things don’t work anymore.
And the ‘running in background’ notification vanished some dozend releasea ago too. I guess by intention. Very bad decision.
But I don’t know how to get in contact, won’t waste my time filing problem reports which will be ignored anyways.

15

Even if nobody answer they are useful to keep track and better than a random conv.
There is actually only one dev working on android with a long todo and SIP is not the main priority for Jami.

https://git.jami.net is the main entry point for submitting issues. To my knowledge there was no change in the SIP stack for months

2 Likes
16

It’s not the SIP stack which makes the app unusable, it’s the UI.
New masterpiece:
SIP dialogs seem to be completely removed, while still registering.

So I can ring the phone, but I can’t answer any call nor can I initiate any calls. Congratulations to Astarte 2024-0620-01. It will lower userbase faster than ever before.