Native Android Development in Kotlin and Java

Kotlin. It's Google's recommended language, the documentation and libraries assume it, and it removes a category of null-related crashes by design. Java remains entirely reasonable for maintaining an existing codebase, and the two interoperate well enough that you can move gradually.

Because several manufacturers add battery managers that are more aggressive than stock Android, and they'll stop your scheduled work without a visible error. The fix is using WorkManager correctly, choosing a foreground service where the work genuinely justifies it, and testing on the specific brands your users carry — this is not reproducible on an emulator.

Driven by your users, not by a rule of thumb. We look at your analytics if you have them, or the market you're selling into if you don't. Supporting one version further back can be nearly free or genuinely expensive depending on which APIs you need, so it's worth deciding explicitly.

Yes. Those handsets usually ship vendor SDKs for the scanner and peripherals, which means native integration and testing on the actual hardware. It's worth confirming device models early, because the SDK quality varies considerably.

Meeting the target API level Google requires that year, a data safety declaration that matches what your app really collects, and justification for sensitive permissions. These have hard deadlines, so an app that isn't maintained can be removed from the store without any code changing.