Designing Android POS systems that last: tackling retail development

Have you started building retail technology products for Android POS (Point of Sale) systems? If so, you’ve discovered that Android is robust enough to streamline transactions and flexible enough to integrate a variety of applications. Plus, Android is a familiar, time-tested platform for both your development needs and your customers’ retail use.

Keep in mind, though, that Android POS development is not the same as Android mobile development. For one thing, you’re designing and building products for a much longer active life – typically 7 to 10 years. For another, you have to factor in standards for Payment Card Industry (PCI) PIN Transaction Security (PTS), should there be a need to accept card (chip or swipe) payments). Any design decisions you make must also allow for software updates to devices that non-technical users rely on day in and day out.

This post covers 4 fundamental design questions you should address from product inception. It is based on our experience of continually listening to and answering these questions from manufacturers and developers like you. Since processors and system-on-chips (SoCs) from Qualcomm Technologies appear in a variety of retailer products from points of sale and smart cash registers to back-office handhelds, we are excited to share our learnings. 

1. For what time frame should I design my Android PoC product?

Align your time frame with the active life span of PCI/PTS standards. It’s typical for a point of interaction (POI) version of a product to be certified within 3 years of inception. The sunset date for a POI version is approximately 10 years from inception, which coincides with the expected active life of most POS systems.

For example, PCI PTS POI v6 was released around June 2020 and will sunset in April 2031. Therefore, you might want to design the product for a similar time frame to ensure that the product is updated with the latest security patches and remains safe from cyberattacks.

2. What is the minimum memory configuration we should design into our POS product?

At a minimum, the memory configuration of a POS product should efficiently accommodate the operating system, application software and any transaction data. Since “minimum memory configuration” is a subjective term dependent on the number of applications to be supported, consider a simple Android POS system that only accepts payments.

The minimum recommended memory requirements for handheld devices based on Android are outlined in the Android Compatibility Definition Document (CDD). But POS systems are built on an Android Open Source Project (AOSP) product that does not get certified for Google Mobile Services (GMS). Because a POS system does not demand the same level of functionality as a handheld device, the CDD serves only as a guideline.

You can, of course, reduce your memory requirement by disabling AOSP components that your POS product does not need. But you then deviate from the well-tested and stable AOSP release, thereby increasing your software development and maintenance costs.

3. For guidance on memory configuration, should we just rely on the CDD for the launch AOSP version?

No! Here are some other factors to consider:

a) From one year to the next, changes arise in the AOSP configuration that you should take into account. For example, AOSP has been supported historically on 32-bit configurations, then migrated to 64-bit configurations as newer SoCs added support for 64-bit. AOSP also supports the Android (Go edition), which allows low-RAM devices to run specific versions of the app if the product is memory-constrained. The optimal version would be an Android Go 32-bit configuration. Note, however, that the applications must match the OS configuration.

Android CDD provides recommendations for minimum available memory to userspace and kernel (Section 2.2 , Requirements 7.6) based on the size of the display. 

Notes:

·       To take advantage of platform optimizations, the device should be declared as low-RAM, based on RAM size, by returning TRUE for the public API ActivityManager.isLowRamDevice().

·       Any device that launched as a standard (i.e., not low-RAM) device SHOULD NOT convert to a low-RAM device using maintenance releases or letter upgrades.

b) Based on historical data, different components of Android have increased in memory requirements from one version to the next, as shown in the following tables:

 

Android (Go edition) 32-bit version upgrade	Estimated impact (in MB)	Reasons
12-Go to 13-Go	85-90	Android frameworks ~30 MB GMS for Android apps impact ~35 MB Variance (cached app size) ~25 MB
13-Go to 14-Go	85-90
14-Go to 15-Go	90-95

Android version upgrade	Estimated impact (in MB)	Reasons
12 to 13	60-65	Android frameworks ~25MB GMS apps impact ~15MB Variance (cached app size) ~25MB
13 to 14	60-65
14 to 15	90-95	Android frameworks impact ~50 MB GMS apps impact ~15MB Variance (cached app size) ~25MB Additional virtualization service ~5 MB

Android Common Kernel (ACK) 64-bit version upgrade	Estimated impact (in MB)	Reasons
5.4 non-Generic Kernel Image (GKI) to 5.15 (GKI)**	110	Addition of multiple kernel configurations Increase in size of vmlinux

 

The impact estimates shown are for reference. Measurements may vary based on product configuration (RAM size, processor cores, etc.). The figures are not additive, since specific Android versions can be supported with a variety of ACK versions.

This way, the many variables involved suggest that memory configuration should follow the CDD. The variance of memory required for GMS apps and for desired OS/Kernel updates for the product serves as a useful guideline for deciding the minimum memory configuration.

4. Do I need to update the OS and kernel every year?

No, but PCI requires that you update them whenever necessary to address known vulnerabilities. The Android OS and kernel are supported by their respective communities for a limited period, as indicated by the table below:

Version	Released	Projected end of life
6.6	October 29, 2023	December 2026
6.1	December 11, 2022	December 2026
5.15	October 31, 2021	December 2026
5.10	December 13, 2020	December 2026
5.4	November 24, 2019	December 2025
4.19	October 22, 2018	December 2024

It is sometimes possible to backport fixes if community support for a specific OS or kernel version has expired, but that increases R&D costs. Besides, backporting is not always an option since Android and kernel engineers may have redesigned subsystems to fix bugs and accommodate new requirements and features.

Your turn

Can you safely design Android POS systems for the long haul? Yes, you can, by keeping in mind that developing for POS systems is not the same as developing apps for mobile phones. The guidelines above are based not only on active lifespan and memory requirements, but also on our years of experience building retail technology products for Android POS systems.

A well-designed POS system offers retailers not only eco-friendly longevity but also lower total cost of ownership (TCO) of the system. Moreover, given how quickly the payment landscape changes all over the world, smart POS designers anticipate and embrace those changes.

If you’re working on Android POS design and development, Qualcomm Developer Discord is the place to be to meet fellow developer experts, get the latest news and prompt tech support.

Will you be in New York for Retail’s Big Show, January 12 through 14, 2025, at the Javits Center? If so, stop by and see us at booth 6713. Besides demos of our technology in everyday retail products, we’ll have field engineers who can answer your questions and talk you through the products you’re trying to build.