From Direct SDK Integration to AIDL: Evolving Android POS Integration Strategies

Background

Android’s open‑source nature enables it to run on many hardware devices, including smart POS terminals. Integrating multiple POS SDKs in a merchant‑service app required a progressive architectural evolution to balance integration speed, code reuse, APK size, and maintenance effort.

Stage 1: Direct SDK Integration

In the early fast‑track phase the POS SDK was added directly to the business code.

Advantages: low integration cost and rapid rollout for a single device.

Problems: tight coupling between business logic and SDK, no abstraction, and duplicated effort across teams. Adding a new device would flood the codebase with if‑else branches, creating a maintenance nightmare.

Stage 2: Componentized Hardware Library

Device capabilities were abstracted and each POS implementation was encapsulated in a shared hardware library.

Benefits: improved extensibility and reuse.

New issues: the common library grew quickly, inflating the APK size; each device only needed its own SDK, making other SDKs dead weight; SDK differences caused dependency and resource conflicts, harming performance and stability.

Stage 3: Differential Packaging with ProductFlavors

Android’s ProductFlavors were used to split the hardware library and isolate SDKs per flavor, reducing coupling and APK size.

New maintenance burdens: multiple hot‑fix base packages required separate patches; configuration IDs/keys tied to package names had to be re‑requested for each flavor; backend services (e.g., push) needed synchronized updates.

Although this solved the size and conflict problems, the added complexity made the approach unsuitable for long‑term maintenance.

Final Solution: Split Service APK with AIDL

The architecture was divided into two independent APKs:

Business APK : contains only business logic.

Service APK : bundles all POS SDKs and the integration logic.

Communication is performed via a custom AIDL interface placed in a shared support module. The Service APK wraps each POS capability behind a unified AIDL contract; the Business APK invokes the contract without knowing the underlying hardware.

Call‑Pattern Details

Transaction‑related calls: the Service APK initiates the transaction and the Business APK polls the backend for payment status updates.

Non‑transactional calls (e.g., printing): results are returned immediately via callbacks.

Reflection and Comparison

There is no universally optimal architecture; the best design solves the specific business problem at hand.

Comparing the five approaches (direct integration, hardware library, differential packaging, AIDL, and plugin concepts) across four dimensions—coupling, extensibility, integration cost, and maintenance difficulty—shows that the AIDL‑based split‑APK consistently scores the lowest on coupling and maintenance while offering high extensibility and low integration cost.

Exploration of Dynamic Loading and Plugin Approaches

Dynamic loading or plugin frameworks could theoretically deliver the Service APK without installation, but Android 9.0+ restricts private API usage. Most popular plugin frameworks are outdated (Gradle 3.x, no AndroidX support) and poorly maintained, making them unsuitable for production.

Even frameworks claiming Android 9.0+ compatibility still suffer from:

Stagnant Gradle versions.

Lack of AndroidX support.

Sparse documentation and unresponsive issue trackers.

Consequently, the team does not recommend plugin‑based solutions for POS integration.

Future Directions

The AIDL‑based model will be generalized to other hardware categories beyond POS devices, aiming to further lower integration costs and provide a unified capability layer for merchants.