Android App problem

Hi Guys,

Have been using FarmOS for number of years now, always from a browser, found the download for the android APK, installed fine, but for some reason I cant seem to connect to my server? I enter the details and it just sits with spinning circle…

I am able to connect with http and https in the browser (after accepting security warning for https in chrome)…so think ssl is working as see the app forces it?

Its hosted locally on the network…

Any thoughts?

1 Like

Hi there, @darrenjlobb. Welcome to the forum!

You’re correct in assuming SSL is required. I’m a little concerned though if you’re getting warnings about https in the browser. Chrome doesn’t usually do that unless there’s something it doesn’t like about the certificate. Is it a self-signed certificate by any chance?

Also, I would probably recommend running the mobile as from the PWA website, instead of the Play Store APK. We’re not updating it as frequently b/c of general issues with native releases, but it’s the same app, and can even be “installed” to your home screen. More details here:

Let me know if you’re still having trouble, hope this helps!

1 Like

I did use the PWA, sorry should have said in the first post…

With regard to the certificate, its hosted here locally on the network, so as far as i’m aware, chrome will always behave like this? It works fine once you accept it and proceed…just like alot of network appliances hosted locally that use https?

Is this why the app isnt working do we think? What are others doing?

1 Like

I’ll defer to @mstenta to correct me if I’m wrong, but you may need to set up an https reverse proxy if you’re hosting on your local network and want to connect to or the Android APK:

1 Like

Hm, Just updated to latest version as wondered if that was effecting it, but sadly not…

Can anyone confirm if the reverse proxy is required given I can use the https://localhostname and browse FarmOS no problem…

1 Like

Just tried using the link in my pc browser, and then get the error saying that OAuth isn’t enabled on my FarmOS install…but when I go to the page to enable it, it is already enabled…

1 Like

Just to confirm, you’ve specifically enabled the “farmOS Client (Field Kit)” client, as shown below, correct?


1 Like

I have now… Which now means when I access via browser to the .app site, I can login…but still no good on the phone…

1 Like

Ok, that’s something. :slightly_smiling_face:

When you’re accessing in your PC browser to your farmOS server, is that the same machine that is running your server?

1 Like

No, its hosted on a virtual server in my rack…

Just been playing, If i go on chrome on my android phone, and go to…I can login / works fine…but if i use the home screen shortcut as from the apk, it doesn’t work…

1 Like

Hmm, you might just try removing the shortcut and trying “Install app” again from the Chrome main menu, or clicking the “Add farmOS to Home screen” banner, if that pops up.

1 Like

My understanding is that proceeding despite a browser certificate error is not the same as adding that certificate to your trust store - either browser or OS level.

Regardless of whether you choose to go with the PWA or APK, I’d recommend explicitly trusting the local CA certificate that you’re using to generate your certificates. For the PWA that would probably mean adding the certificate to your browser’s trust store, and for the APK it would probably mean adding it to the Android trust store. You should be able to find lots of tutorials for how to do that on various systems. e.g. FAQ/ImportRootCert - CAcert Wiki


Yea, following on what @Symbioquine said - when you “accept” the SSL certificate in your browser (to tell Chrome that you trust it, even though Chrome doesn’t recognize the issuer) - that “acceptance” only applies to the browser/session/computer you accepted it from.

Whenever a third-party application needs to connect, it will run into the same problem. This is probably why you’re having trouble in other contexts - it may not give you the option to “accept” the certificate in an APK version, and maybe the same is true in a PWA that is “installed to homescreen” (I’m not sure how the browser manages the session in that case - it may be a different session than the phone’s browser itself).

A good example of this problem is curl, which is a command line tool for sending requests. If you have a self-signed certificate, curl will not let you send the request, and will instead show an error that the SSL is insecure. The only way to send the request is to add the -k flag, which says “allows insecure connections”. That’s basically what you’re doing when you “accept” it in a browser as well. Field Kit uses a library called Axios for HTTP requests, and similarly that library provides a special flag to allow insecure connections (see How to ignore SSL issues · Issue #535 · axios/axios · GitHub). Field Kit does not include this flag (nor should it). So I’m actually surprised that it worked for you in ANY context - but that just suggests to me that your browser is remembering that you accepted it, when it was done in the same computer/session/context. That’s just a guess though, and I could be missing something… in either case I think the solution is to either:

a) create a real SSL certificate
b) add the self-signed cert to your trust store (as @Symbioquine suggested)

Hope that helps!

FYI: A reverse proxy is not required. That’s just a method for serving farmOS with HTTPS, but it sounds like you’re already doing that. So I assume you either configured Apache SSL, or you already have a reverse proxy of some kind? :slight_smile:


As a follow up to this, I removed the “app” from phone…and just went on chrome, and used the “install app” feature, and it then works just fine…

Yes, I have apache setup with SSL, but for servers hosted locally, I’m not sure that its possible to create a real SSL certificate? Unless I open it to the web, and point a domain at it?


Yeah, you have to have a real domain to have a real certificate, but you don’t have to open it up to the web to get a certificate that is automatically trusted by the majority of browsers/OSs Any strategy that allows you to provision a valid certificate for a domain you own could be used, as long as you can get the certificates onto the local server machine and some form of DNS the point the domain/subdomain at that server.

Taking things a bit further, if you want free and automated provisioning of those certificates, the ACME protocol that Let’s Encrypt uses supports something called dns01 validation. All that is required to pass the “challenge” for dns01 validation - proving you own the domain and can be granted a certificate - is some special public DNS entries that the ACME protocol will generate. This means that you can use tools like Certbot, Dehydrated, or cert-manager to provision certificates as long as the place you’re provisioning them has outbound internet access.

As a more concrete example, you could spin up a docker-dehydrated container along side your farmOS installation and manually pass the dns01 challenge by inserting some custom (public) DNS records Dehydrated will provide. After which Dehydrated should keep renewing the certificates for you - at worst occassionally requiring you to re-verify with a new DNS challenge. You could then add additional DNS entries either via the public DNS or on your local network/clients to point at the local network IP of your server.