APK

How it works

An APK is a zip file with a fixed layout: AndroidManifest.xml declaring the package name, permissions and components, one or more classes.dex files holding the compiled bytecode, compiled resources in resources.arsc, native libraries under lib/, and a signature block in META-INF. Android identifies an app by its package name plus its signing certificate, and that pair can never change after publication. A different key means a different app as far as the OS is concerned.

Signing has gone through four schemes. The original jar signing (v1) gave way to the v2 whole-file scheme in Android 7.0 in 2016, v3 arrived with Android 9 and allows key rotation, and v4 shipped with Android 11 for incremental installs of very large apps. If you publish through Google Play, Play App Signing keeps the final signing key on Google's side and you hold only an upload key. Safer against key loss, but Google signs the binary your users receive, not you.

Since August 2021, new apps submitted to Google Play must be Android App Bundles (.aab) rather than APKs. That changed publishing, not installing. Play takes the bundle and generates split APKs matched to each device's screen density, CPU architecture and language, and those APKs are what reaches the handset. For an internal build you distribute yourself, the APK is still the file you hand over.

Versioning runs on versionCode, a plain integer that has to increase with every release, plus versionName, the human string such as 3.2.1. Android refuses to install a lower versionCode over a higher one, so a rollback means uninstalling first, and the local app data goes with it. Plan that before you ship a bad build to 400 devices.

Why it matters for a fleet

Most fleets run at least one app that will never sit on a public store: a warehouse scanner client, a field service form, a tool written for one business unit. It arrives as an APK, and someone has to decide who gets version 4.1 and when. Pushed through a private channel, the install is silent, the version is known and the update is one action. Emailed around instead, you get the usual mess: three versions in the field, no inventory, and a user who installed a file from a link he can't remember.

Google keeps closing the door on anything installed outside a store. Android 13 stopped sideloaded apps from obtaining Accessibility permissions, Android 14 refuses to install apps targeting API 22 or lower, and Play Protect added real-time scanning of newly sideloaded apps in 2024. In 2025 Google announced that installing apps on certified Android devices will progressively require a verified developer identity, starting with a first group of countries in 2026. Ad hoc sideloading is a dead end. Managed private distribution is not.

How Appaloosa handles it

You upload your internal APK, Appaloosa keeps every version, and you assign a version to a group instead of the whole fleet: pilot on 20 devices, then widen. Public apps sit in the same catalog through Managed Google Play, so users see one list. Installs can be silent on managed devices, managed app configuration travels with the package, and the install report shows which handset is still running the old build. The full scope is on the Mobile Application Management page.