FractalAndroid turns a phone into a gated federated learning node

A phone that is one node of a larger Fractal network

FractalAndroid is not a standalone app that happens to run some AI. The README describes it as the distributed compute client and edge execution runtime for the Fractal decentralized intelligence framework, working in coordination with a central server called FractalCore. Its job is to turn consumer phones into compute nodes inside that network.

The workloads it runs are described as localized machine learning tasks: on-device federated training with TFLite, and partitioned batch dataset training. The stated purpose is to do this without exposing user data and without degrading the performance of the device that hosts the work. That framing tells you the audience. This is not a consumer reading app or a photo utility. It is infrastructure for a distributed training setup where a phone is expected to sit on a charger, on unmetered Wi-Fi, and quietly contribute.

The application id on the Play Store listing is org.fractal.app, and the repository is written in Kotlin with an MVVM architecture, targeting Android API 24 and above, which is Android 7.0. The primary language of the repository is Kotlin, and the topic list names edge computing, federated learning, privacy by design, resource management and on-device AI, so the design intent is consistent throughout: the phone is treated as a small, shared, battery-limited server that has to behave politely.

Telemetry gating decides whether a task runs at all

The mechanism that distinguishes this client from a naive background job is a gate driven by physical hardware readings. The engine continuously monitors SoC temperature, battery level, charging status and RAM pressure, then dynamically gates computation based on those values. The Node Settings screen is described as holding autonomous telemetry thresholds and charging policies, so the gate is user configurable rather than a fixed constant buried in code.

Read the wording carefully. The claim is not that the app runs fast. The claim is that it will not cost you. The README phrases the target as zero impact on user experience and battery longevity, and the reward section reinforces it by tying edge compute contribution to a specific precondition: the device must be connected to power and on unmetered Wi-Fi. In that state the node executes quantized gradient descent or model slice inference. Both are reduced forms of the work, which is consistent with the ambition of keeping a consumer handset usable.

The measurement surface is broad enough to be useful. Usage Insights gives time series graphs for CPU, RAM, battery and thermals. Device Insights adds hardware profiling with a one-tap memory optimization. Model Training shows loss convergence curves, parameter transfer rates and epoch progress. The home screen has two states, a standby view awaiting task assignment and an active view during local training.

What the documentation does not say is how the gate reacts when a threshold is crossed mid task, whether a partially finished epoch is checkpointed or discarded, or what the measured overhead of the telemetry polling itself is. Those details determine whether the promise holds on a cheap handset, and they are not in the README.

The WiFi Bank pays in data credits, not in money

The incentive layer is called the WiFi Bank, and the README describes a reward exchange rather than a donation. When a node uploads a validated parameter checkpoint, identified in the text as a .ckpt file, to FractalCore, the system automatically credits liquid megabytes to that device's account through the Firestore ledger. Users then redeem accumulated credits for high-speed Wi-Fi access or shared bandwidth pools.

The unit of account is bandwidth, and it is worth noticing what that implies. A participant is not paid in currency, and the operator is not paying for a data centre either. The credit is a proxy for metered mobile data that the participant was not going to spend, or a share of pooled capacity. The mechanism is only as trustworthy as the validation step, and the README refers to a validated checkpoint without describing how a checkpoint is validated, who validates it, or what a failed validation does to the credit already granted.

There is also a dependency stack here worth naming plainly. Authorization uses Firebase auth, device binding uses the ANDROID_ID, CPU and RAM, and the credit ledger lives in Firestore. The node does not talk only to FractalCore for work; it leans on Google's hosted services for identity and accounting. For a project whose selling point is privacy preserving and decentralized, that is a structural tension, and the README does not discuss it.

Onboarding is a Play Store install plus a device binding

The install path is the ordinary consumer one, which is unusual for a project of this kind. There is no sideloadable artifact documented in the README, and the project homepage is a Google Play listing under the application id org.fractal.app. The repository itself contains a Gradle project with gradlew, gradlew.bat, build.gradle.kts, settings.gradle.kts, an app module, scripts, docs and a .github folder, but the README section on development and build is referenced in the table of contents and not included in what is available here, so no specific build or install command can be quoted.

What a first use looks like is documented through the screens. Onboarding starts with a Get Started page that introduces the decentralized compute harvesting paradigm, then moves to Device Authorization, where Firebase auth is combined with hardware ID binding on ANDROID_ID, CPU and RAM, and finally to a Registered Info screen showing the confirmed registration profile and the assigned compute node telemetry. After that, the node waits in standby for a task assignment, moves to active compute when work arrives, and reports progress through the Model Training view. Reading settings first is the sensible order, because the telemetry thresholds and charging policies there decide what the phone is allowed to do.

Since the documentation offers no runnable command for this project, the only quoted identifier worth keeping is the application id, which is the same string the Play listing uses and the same one the device registration screen records: org.fractal.app. That match is a small but useful confirmation that the published build and the source tree belong to the same artifact.

A proprietary non-commercial licence with no release history

The licence situation is the sharpest edge of this project. The badge in the README names a Proprietary Non-Commercial v3.0 licence, and the licence field on the project listing is marked as Other, a custom licence that GitHub cannot classify, pointing at the LICENSE file. This is not an OSI style open source project, despite the topic list including edge computing and federated learning frameworks, and a company that wants to ship this in a product cannot assume the rights.

The other notable gap is distribution history. The repository has no GitHub releases, so there is no published version list, no changelog-driven upgrade path in the release sense, and no way to pin a known good build from the release page. A CHANGELOG.md does exist in the tree, along with CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md, so the project has the artefacts of a maintained repository even though it does not publish tagged builds. The last push was on 2026-08-22 and the repository is not archived.

For a system whose whole purpose is to be run continuously on a device that belongs to someone else, that combination is awkward. You can install from the Play Store, but you cannot easily inspect which build you have, and you cannot run it without accepting a licence that rules out commercial use.

When running TFLite on your own device is the better answer

The straightforward alternative to this entire approach is to use TFLite inside an app you control, on one device, with no network, no node registration, no checkpoint upload and no credit ledger. For a product that wants on-device inference, that is less moving parts by a wide margin, and it keeps the training data on the handset by construction rather than by policy.

The difference in approach is what FractalAndroid adds. TFLite on a single phone is a local inference tool. FractalAndroid turns that same local execution into a federated arrangement: the phone is one participant among many, it receives partitioned or batch work from a central server, it returns validated parameter checkpoints, and it is compensated in bandwidth. If your problem is that a single device cannot train a model in reasonable time and your users have idle capacity on unmetered Wi-Fi, this is the only approach in the discussion.

If your problem is simply running a model on a device, none of the coordination earns its cost. The extra moving parts are the app, FractalCore, Firebase auth, the Firestore ledger, the telemetry gate, and the checkpoint validation, and the first thing that breaks when a participant behaves badly is the credit system, since the documentation gives no detail on how a bad checkpoint is rejected after the fact.

Editorial conclusion

FractalAndroid suits a researcher or a lab that already runs FractalCore and wants spare Android capacity to participate in federated training without draining the owner's battery. It is the wrong choice for commercial deployment, for an offline app, or for anyone who needs a reproducible build from source. Before adopting it, check the LICENSE file, since the badge names a proprietary non-commercial licence, and confirm that a Google Play install at org.fractal.app is acceptable given that the repository publishes no GitHub releases and its last push was on 2026-08-22.

Frequently asked questions

Official sources

1. Fractal-Compute-Orchestrations/FractalAndroid on GitHub
2. Issues
3. Project website
4. README