@Mofedul Alam Joy Thanks, this is very useful and exactly the kind of practical feedback I was looking for. A few follow-up questions before I buy a test device: 1. Have you personally used the SUNMI V2s in production, or is this based on general developer experience with SUNMI devices? 2. Which exact V2s configuration would you recommend?GMS or non-GMS, RAM/ROM, scanner/no scanner, Android version, receipt/label version? 3. For printer access: did you use the official SUNMI SDK, ESC/POS commands, or a wrapper/bridge? 4. When you say print success callbacks, does the SDK confirm that the ticket was actually printed, or only that the print command was accepted by the printer service? 5. Can the app reliably detect paper-out, printer error, overheating, and failed print jobs? 6. For dedupe: would you still keep the main print_jobs state in the backend and use device-level job_id storage only as an extra safety layer?My current thinking is: backend print_job state + device lock + local job_id cache + printed/failed callback. 7. Did you ever test reboot recovery? For example: order accepted → print job locked → device reboots before/while printing → app restarts → no duplicate ticket. 8. Do you have any SDK docs, GitHub sample, or bridge app you would recommend for SUNMI V2s? 9. Would you still choose SUNMI V2s over iMin M2/Swift if the use case is mainly order acceptance + prep time + kitchen ticket printing? Appreciate the help. I’m trying to avoid buying the wrong hardware before testing the real printer/app layer.