Writing Kotlin for Sunmi POS terminals is Android development with old APIs, a thermal printer and three payment SDKs.
The Sunmi V2 Pro runs Android 7.1, from 2017. API 25 rules out newer platform APIs, and the vendor services only expose old AIDL interfaces.
The thermal printer is the star of the show. Its system service blocks the main thread for 200-400ms per receipt: jank on every print, and ANR when prints queue up. We offloaded everything to a background dispatcher through a coroutine-based print queue. That took two weeks to get right because the Sunmi SDK documentation is thin.
Payment integration is where it gets spicy. Stone, Rede and Cielo each have their own SDK, with their own lifecycle, callbacks and creative interpretation of what "success" means. We built an abstraction layer that normalizes all of them into a single PaymentResult sealed class. A new provider only needed a new adapter. Clean Architecture saves lives here.
The small screen left little room for fancy layouts, so we had to make every pixel count. We learned to design for the terminal first and then adapt for tablets. Restaurant staff used this thing during a Saturday dinner rush with greasy hands. They needed big buttons and clear feedback so there was no ambiguity about what happened.
Testing on real hardware is non-negotiable. The emulator lies to you. It has neither the thermal printer nor the NFC reader, and it misses the timing quirks of the Sunmi Android fork. We kept four physical terminals on our desks and every PR got tested on metal before merge.
It is not glamorous work. Nobody writes Medium articles about Kotlin on a restaurant POS. But this code processed real money for real restaurants every single day, and when it broke, someone did not get paid.