How ApkPy is tested

Trust should come from inspectable output and repeatable evidence. Every claim below names the check behind it, and the checks run again on every release.

258transpiler regression checks

21Data Core and Reactive Data checks

Real Gradlegenerated debug APK compiled

Strict docswarnings fail the build

What was validated

Area	Evidence	What it proves
Python compiler	258 regression checks	supported source patterns continue to produce expected output
Full test suite	2,416 unit tests	the suites pass with no failures and cover the Previewer, compiler and generated Java
Reactive Data	21 focused Data Core and Reactive Data checks	relations, includes, lifecycle, invalidation, rollback and conditional code generation are exercised
Data Core	CRUD, transaction and migration tests	typed values, rollback, schema paths and destructive recovery are exercised
Generated Java/XML	structural and XML parsing checks	generated sources are internally consistent
Android toolchain	Gradle debug APK build	the checked release reaches Android bytecode/resources
Runtime floor	same-app Android benchmark	APK size, cold start and PSS are reported with programs and raw samples
Documentation	mkdocs build --strict	navigation, internal links and configuration resolve

Last documented validation: ApkPy 1.14.1, released on 25 October 2026.

These checks do not certify every phone, Android manufacturer, backend or app design. They make regressions visible and give a reviewer concrete artifacts to inspect.

The Android benchmark is deliberately narrow: one 100-note debug app on one emulator. It publishes the competing app programs, line-count rule, raw starts, memory samples and hashes instead of presenting a marketing number without context.

NFC verification — 1.9.0

The NFC development run passed 26 focused tests, including 95 comparisons between Python and the actual generated Java decoder; the complete feature suite passed 1066 tests, alongside 258 transpiler and 35 general tests. The documented app compiled with Gradle and its APK contained no Python runtime.

Direct phone checks covered NFC settings, off/on recovery, reader stop/start and rejecting a write when reading had not started. The Previewer panel was checked in light/dark themes. No physical tag was available in that run. The maintainer confirmed a successful NFC test on 13 September 2026, without a tag model or per-operation results; that report is separate from instrumented verification. See the scope and remaining device checks.

Contacts verification — 1.9.0

The integration passed 19 focused checks and the full 1085-test feature suite, plus 258 transpiler and 35 general tests. People Desk compiled with Gradle; its APK was scanned for Python runtime/source. Direct phone checks covered opening and cancelling the phone picker, not saving/editing contacts, listing the real address book or rotation. A final visual check of the latest simulator layout is still pending. See remaining checks.

The guides distinguish scoped selection, permission-based reads and editor return from actual save confirmation. Test counts and simulator results are not proof of every provider or manufacturer's behavior.

Supported environment

Tool	Supported
Python	3.8 through 3.13
JDK	17 through 21
Android output	Java, XML and Gradle project
Desktop preview	Windows, macOS or Linux with Tk
APK runtime	native Android; no Python interpreter embedded
Android	apps target Android 16 (API 36), which Google Play asks for, and run from 7.0 (API 24); 1.13.0 was used on a phone with Android 16

Run apkpy doctor before a build. Validate notifications, background work, media, permissions and location on a real Android device before release.

Conditional output

ApkPy detects features before generation. A small app does not receive every runtime:

• WebSocket helpers appear only when websocket is used;
• NFC helper, normal permission and optional hardware feature appear only with NFC calls (1.9.0);
• contacts helper appears only when used; only list/get add READ_CONTACTS, and no contacts operation adds WRITE_CONTACTS (1.9.0);
• Firebase dependencies appear only with push code and configuration;
• SwipeRefreshLayout appears only for refreshable virtual collections;
• Media3 and the foreground media service appear only for media features;
• map, route and location helpers appear only when requested;
• rich-document helpers appear only for Markdown, rich text or trees.
• Data Core repositories, executor and migration runtime appear only when db.model() is declared.
• relation metadata and batched hydration appear only with db.relation();
• the invalidation tracker and observable-query runtime appear only when observe() is used.

This keeps generated projects reviewable and reduces unused dependencies.

Stability contract

The documented names exported from apkpy_lib are the supported surface. Generated helper classes are implementation details and may change between versions. The Python declaration remains the source of truth; hand-edits in a generated Android project can be replaced by the next build.

Patch releases should preserve existing declarations. New capabilities are documented in a version page and must pass the existing regression suite.

Ownership and continuity

ApkPy is open source under the Apache License 2.0 since 1.13.0. The engine, its tests and its examples are in the public repository, so the project can be inspected today, and maintained or continued by anyone, whatever happens to it.

Read Licence and project continuity for what the licence asks, and the exception that covers the apps you build.

Scope

ApkPy builds the app; the product around it stays yours. The boundaries follow from that division:

• the phone runs the Python ApkPy documents, and its own https, db and files cover the jobs a pip package such as requests or numpy would do elsewhere;
• code outside the documented vocabulary stops the build with the error that names the fix; it is never turned into Java half-way;
• the backend is the application's to build: accounts, payments, DRM, proprietary map SDKs, cloud deployment;
• protocols a client cannot own alone, such as end-to-end encryption or collaborative CRDT editing, are not part of it;
• OEM behaviour differs by manufacturer; the Previewer versus Android page maps what is simulated, and a device test before release closes the gap.

For a product-level view, read Can ApkPy build this?.