Android version support

Proven on physical devices

Emulators prove breadth; handsets prove the parts an emulator cannot. The list below is short on purpose, and the count is not the claim. Training fleets are scavenged rather than standardized, so what matters is whether Loadout works on a phone that is not a Pixel. Three vendors and three manufacturer skins answer that; a longer list of the same handset would say less.

Several handsets at once: The three-device counter-network mission deploys across all three handsets on the companion-app path, with the read-back green on each, cross-device correlation verified, and a clean residue check after removal. Reproduced over four consecutive cycles. That mission carries SMS, MMS, calls, and contacts. Gallery photo and video are hardware-proven on a single device, not yet inside a multi-device scenario.

Rooted devices

Loadout does not need root, and rooting is not recommended. Training fleets are unrooted, and the on-device companion app above is the path that ships. This table is here for operators who already have a rooted device and want to know what to expect, and so that nothing on this page implies rooted support Loadout has not earned.

The cells use a different vocabulary from the table above, because most of them are not on a road to a yes. Calling them "in validation" would overstate every one. Note in particular that SMS and MMS are declined on the rooted path at every version, including the two where the platform was measured to accept them: writing SMS needs the default-messaging role, root is not a substitute for holding it, and a capability that only appears on the newest Android buys nothing for a mixed fleet. On a rooted handset Loadout uses the companion app for those types.

Two limits stated plainly. No rooted measurement on this page comes from physical hardware — every one is an emulator, so manufacturer behaviour on the rooted path is unknown. And "Declared only" means our own code asserts the capability and no run supports it: the full rooted lifecycle runs in continuous integration on Android 15 and 16 only, so contacts and call logs have no rooted evidence below that. Those cells are shown rather than quietly rendered as support.

Notes

"Validated" means Loadout injected a persona on that Android version, read every artifact back through the on-device content providers, and diffed it against the ground-truth manifest with zero failures, then removed it and re-read the device to confirm the removal was complete. The removal check validates itself: a query that never saw a row in the first place cannot support a clean result, and a run where that happens fails rather than reporting a clean device. On the reference build (Android 15) the injected data is additionally confirmed to parse in a real open-source forensic tool (ALEAPP). That parse is not the bar every row cleared, and is not claimed for the whole table. "In validation" means the same method applies and the version is in the scheduled conformance matrix, not yet confirmed. "Not yet" means the matrix found that artifact failing on that version. "Planned" means the version has no public emulator image to validate against yet. Android 17 has no public emulator image either, and is marked validated because it was run on a physical device instead.

Contacts, call logs, photos, video, SMS, and MMS are written by the on-device companion app (the path used on lab devices) and verified field by field. The conformance matrix re-runs monthly in CI, and again on every change to the injector, the engine, or the data contract, across the seven versions whose emulator images boot on cloud runners (Android 10, 11, 12, 12L, 14, 15, and 16), so support is maintained, not asserted once. Video runs inside that same full-scope matrix, which compares the injected file's recorded capture time against the authored one and refuses to run at all if the persona carries no video, so a video cell cannot pass by not being tested. On Android 15, ALEAPP (a free proxy for the parsers in MSAB XRY and Magnet GrayKey) independently surfaces every injected type, including video, from the app-injected device. Android 13 was validated on a local emulator (the full provision, field-level read-back, and clean removal all pass) because its image will not boot on our cloud CI runners — an infrastructure limitation, not a device one. Android 17 still has no public emulator image, so it was validated on a physical Pixel 8a instead: a full provision, a field-level read-back of every record with zero failures, and a clean removal whose completeness was confirmed a second time by an independent device-wide check. That row is earned from hardware rather than from CI, and it does not re-run on the monthly cron. Android 9 and older are out of scope: the companion app is built on a messaging-role API that Android 10 introduced.

Documents is the newest artifact type, and every supported Android version, 10 through 17 (API 29-37), is validated: a full lifecycle (clean baseline, provision, counted field-level read-back, removal, and a residue check with a positive control proving the check can see a row that exists) measured through the real production paths the Control Station and CLI actually use, not bare per-record calls. Android 10 through 16 were measured across the emulator/local spread; Android 17 has no public emulator image, so it was earned on a physical, unrooted, `user`-build Pixel 8a instead -- the same device as this table's other Android 17 evidence, and the strongest evidence in this column since every other level here is an emulator. That measurement also closed the gap the two rows at Android 10 and Android 14 previously carried: an earlier run there had proven injection and every field-level value but not removal, which is why those two used to read "in validation" rather than "validated." Documents are also operator-reachable end to end now, proven on a real unrooted handset, so "validated" here means the same thing it means for every other artifact type on this page: usable, not merely measured in isolation.

iOS support is under evaluation and is not represented here. See the roadmap. Validation evidence and the conformance reports are described on the Security and Compliance page, and available on request: dayel@sigilark.com.