Came to learn recently that not all Android apps respect the OS’s wifi network configured proxy settings. And a workaround is to use an app like Drony to locally proxy to actual proxy over the network for apps that don’t respect the OS proxy config.
And sounded like there might some way as app developer to expose app-specific proxy configuration maybe? Or making app programmatically aware of proxy config existence or not?
So I was wondering if anyone here has some background context around this topic. I’ve only found the following relevant articles, others are just more about Drony, etc.:
and lastly, came across this issue with a (corporate) customer PoC project. Corporate/enterprise deployments tend to use proxies, assuming can’t control app awareness or proxy support at the app level, may have to using something like Drony if to keep app usable over corporate proxy/firewall. I’m just wondering if there are actual corporate/enterprise users/customers (i.e. IT/departmental deployments, not just individual users of BYOD) that make use of Drony for their Android devices + apps to go through their corporate proxy.
Sounds like a Stackoverflow QA overflow question really. It completely depends on the business value, and opens you to a rabbit hole of device wifi/4G roaming pain compatibility if you are relying on a behaviour that will inevitably change over time.
If the app I was testing did not use the OS proxy config correctly, I would be simply raising a ticket, and then getting on with my day-job. Because, so many paint points, like perhaps my app will probably not work in a “test-farm” hosted by a test provider either for example.
Yes, good point Conrad. The context of this post is to see if others have come across this issue, from a viewpoint/context beyond QA rather as a team/company. And how they’ve come to address the issue.
From online search, it isn’t a one-off issue, but also looks like not common enough to be a pain point for many people. Which makes it a pain point if you are one of the few that encounter the problem.
I assume possible resolutions would be:
add app-specific proxy support into the app - if that’s possible
make app OS proxy aware - if that’s possible
use Drony in tandem with the problem app & hope that customers are ok with using Drony in their deployments
say this is Android ecosystem limitation and up to customer to figure out what to do themselves
It’s going to be a problem if you are writing a system app, VPN, antimalware, etc. Neither the Apple not Android ecosystems make it easy to design and test because these applications by nature run in a hardened context. I only briefly had to deal with this many years ago. So, I budgeted for more equipment to cover each configuration and space for “devices”, to allow easier testing of the combinations you want.
I’m not sure you can force customers to use an extra app, it will long term create a chance you loose those customers. Hope you can find an alternative to this “Drony” app in your ecosystem. To me it looks like it’s a problem with apps using outdated authentication transports/protocols.
You might be right. Or I also suspect it’s an issue with (native) (and secure) websockets protocol (WSS communication. It piggybacks on HTTPS to negotiate handshake (same for the unsecured one over HTTP), but then goes direct with a socket/TCP connection thereafter. It may be that Android OS only factored in the proxy design for only HTTP/HTTPS and not all other network protocols, even ones built to complement those ones. It’s too bad it’s not well documented (or publicized) the proxy behavior/implementation.
We have developers looking into it. Most likely we’ll build the proxy support into the app, hopefully that is doable.