How do you handle testing on the huge variety of Android devices and versions?

Show that you approach fragmentation systematically rather than hoping.

• Decide coverage from your own data, not from general statistics. Play Console shows the actual distribution of devices, Android versions, and screen sizes among your users. That tells you what to support and, importantly, what to drop.
• Test the extremes deliberately. The oldest supported API level, the newest, a low-RAM device, a very small screen, and a tablet or foldable. Bugs cluster at the boundaries.
• Test on real devices for the things emulators cannot reproduce — camera, sensors, performance on weak hardware, and manufacturer battery management. Firebase Test Lab gives access to a device matrix in CI.
• Automate what you can. Unit tests for logic, Espresso or Compose tests for UI, and instrumented tests run across a small device matrix on every merge.
• Use staged rollouts. Releasing to 5% first, watching crash-free rate and ANR rate, then expanding, catches device-specific problems before they reach everyone.

Note: OEM-specific behaviour — particularly aggressive background process killing on some manufacturers — is a genuine Android problem that catches out candidates who have only tested on Pixels. Mentioning it signals real production experience.