+1 to John's answer... there's no easy answer here unfortunately. I'll add a few comments from a product viewpoint and then from an engineering viewpoint.
Product: You need to apply the idea of the 80/20 rule here - given the insane variety of Android phones out in the world today you're unlikely to get your app working well on 100% of them. So, you've got to conserve your efforts to focus on the most important phones. John suggests adding analytics to your app so you can see what your present users own. You should definitely do this, but from a product perspective it's not actually much of a solution: what you really care about is the hardware/OS breakdown of potential users of your app. This is not the same as the present users, since users who can't run your app are (by definition) not using it yet.
This task inherently requires guesswork; do your best, but realize this is always going to be an ongoing problem for your product team. My advice would be to focus on your early adopters - users who will be passionate about your app initially. These users tend to be correlated with newer models. Popular new hardware still varies pretty wildly geographically, so know what region you are focusing on as well. Beyond that, take time to profile people you believe are representative of your early adopters and don't be afraid to ask them what their phone setup is... People taking the time to actually complain to you about problems are gold - try to build relationships with them if you can. Most users with problems just leave and never come back.
Engineering: You need to add as much instrumentation as you can get away with to programatically detect failures (ex: Crashlytics, but you can roll some of your own too to detect specific feature usage, etc). If your product team has user flow funnels, see if you can correlate user drop off with phone model. Unfortunately, this only works once you have a very popular app - otherwise you generally can't get enough data to do this well (beyond finding problems that affect a lot of your existing user base).
Once you decide you want to troubleshoot a specific phone you don't own yourself yet, you can find someone in the world with that phone/OS combo and work with them remotely. Locally here in Boston there's a company called utest.com that helps coordinate efforts like this, but there are lots of competitors to them now too you can find. You can also try going direct to non-professional testers on something like upwork.com to target specific geographic regions/networks in additions to phones.
In the meantime, you should also be continually adding to your own phone library. Try to acquire the most common new phones in other regions of the world by having someone purchase it locally and ship it to you. The average phone user in the world today gets a new phone *every 18 months*. Your library needs to be completely renewed on that time scale as well unfortunately.
Yes, this whole thing is a pain. There's no easy way out though if you want an app that scales globally - the sooner you fully embrace this challenge, the better off you'll be. Also remember that people in other parts of the world can often be on slow networks - problems can arise when you're using too much data (so be thoughtful about the instrumentation you do add - don't be afraid of it, but realize that - in the extreme - it can degrade performance; be sure to track % of data you are using in your app for internal development vs. app functionality).
And finally... if you really want an app that works across a huge array of Android hardware/OS configurations, there's sadly no substitute for having a high-quality engineering team. If you find your team staring blankly back at you while saying helpful things like "well it works fine on my device," don't rule out putting more effort into HR as another way to address this problem too...
![[C]oFoundersLab](/img/logo/blue_cropped.png){kind=logo}