BasicSync runs Syncthing on Android and stays out of the configuration business

BasicSync decides when Syncthing runs and leaves folders to the web UI

The scope of BasicSync is unusually narrow, and that is the design decision everything else follows from. The README states that the app is intentionally kept very basic so the project is easy to maintain and keep updated, and that BasicSync only controls when Syncthing runs while the actual configuration is done through Syncthing's own web UI. For a reader, this means two different interfaces to learn. Folder pairs, device IDs and sharing rules live in a browser session served by the Syncthing process, using the same web interface a desktop or server install would present. The Android side handles permissions, run conditions and the notification that starts and stops the daemon. The alternative design, where a wrapper reimplements folder configuration in native Android screens, means every upstream change to the Syncthing configuration format has to be mirrored in the app. BasicSync sidesteps that whole category of maintenance by refusing to own the configuration.

Syncthing runs as a library inside the main process, not as a child service

The most consequential implementation detail is listed as a single bullet in the feature list: BasicSync runs Syncthing as a library in the main process, which the README says makes the app immune to the child process restrictions introduced in Android 12 and newer. Most Android background work is fragile because the platform can kill a secondary process when memory pressure rises, and a sync daemon that dies mid-transfer is a recurring source of half-synced folders. Embedding the daemon in the primary process removes that class of failure, at the cost of the app's own process lifetime. The repository layout supports this reading: a stbridge directory sits at the top level next to app, external and scripts, and the tree also contains a .gitmodules file and an external directory. The visible documentation does not describe the internal bridge protocol, so the exact mechanism connecting the Android shell to the Syncthing core is not readable from what is published.

Run conditions turn the daemon into something that follows a policy

Run conditions are where BasicSync earns its keep, and the feature list names them plainly: pausing syncing based on network and battery conditions or on a periodic schedule. The permission table explains what each Android capability is used for, and it is a good map of the design. ACCESS_NETWORK_STATE is there to detect when the device is connected and whether the connection is unmetered, so a metered cellular link can be treated differently from home Wi-Fi. SCHEDULE_EXACT_ALARM backs the time schedule feature, and the documentation notes that Android may otherwise delay both the start and the end of a scheduled window. REQUEST_IGNORE_BATTERY_OPTIMIZATIONS exists so the app can ask to be exempted from doze restrictions, and the app deliberately does not prompt for the exact alarm permission while battery optimizations remain enabled. By default the app runs in automatic mode, starting and stopping Syncthing according to those conditions, and a Manual mode in the notification overrides that when you want to control the daemon by hand.

The web interface stays on loopback, and BasicSync forces HTTPS and basic auth on

Exposing a Syncthing interface on an Android device has obvious security implications, and the documentation addresses them in concrete terms. Syncthing listens on the loopback interface and is available via 127.0.0.1:8384 by default. BasicSync tries to use the same port on every start, but automatically picks a new random port when there is a conflict, and the current port can be found in Web UI, Actions, Settings, GUI. Two settings are forcibly enabled every time Syncthing starts: HTTPS and basic authentication. The default password for that authentication is the API token, and changing it is supported, though the documentation warns it may require one extra login when the web interface is opened from inside the app. On the telemetry side, the app states that it does not and will never have ads or telemetry of its own, and that Syncthing's crash reporting is disabled because BasicSync integrates it in a way that is not supported upstream.

The storage access framework is available but slower than direct file access

Android's storage model produces the clearest trade-off in the project. BasicSync supports the storage access framework as an alternative to direct file access, which limits Syncthing to specific folders instead of all internal and external storage, and the documentation still recommends direct file access. The reasoning given is specific rather than generic. Accessing files by path through the framework is extremely inefficient, because a nested file such as a/b/c forces Android to list every file in a and b and query their metadata before c becomes reachable. BasicSync caches directory listings and file metadata to soften that, and the documentation says it remains significantly slower than internal storage. The framework also cannot report watcher events more specific than a change somewhere in a folder, so Syncthing has to rescan the containing folder rather than just the changed file, and it cannot guarantee a created file gets the expected name when several processes race, where file.txt can become file (1).txt. GrapheneOS users are pointed at the OS-level storage scopes feature instead.

Getting it running is a download and a permission walk, not a build

There is no install command to copy here, and the documentation does not present one. It says to download the latest version from the releases page, and to see the verifying digital signatures section if you want to check the digital signature of the artifact you downloaded. After that the documented steps are short: grant the required permissions and set the desired run conditions. Configuration then happens in the Syncthing web UI, as it would on a computer, and the run controls are a quick settings tile that toggles between automatic and manual modes, together with the Android notification, which is the documented way to start and stop syncing from the phone. The app also offers optional remote control, letting other apps start and stop Syncthing, and it can import and export the Syncthing configuration. Small additions to the web interface provide a folder picker and a QR code scanner, and the app detects and reports sync conflicts.

Releases arrive every few days, and the code is GPL-3.0

The project's release rhythm is visible in the tag history. Version 3.23 was published on 2026-10-17, 3.24 on 2026-10-18 and 3.25 on 2026-10-20, and the last push was on 2026-10-20 as well. The repository is not archived, and the work is recent enough that the project can be described as being under current development rather than a stalled snapshot. That pace has a cost for anyone who vendors the app into a managed device fleet, since a new build can land every other day and each one needs to be reviewed before distribution. The licence is GPL-3.0, which matters for distribution: shipping a modified build of a GPL application obliges you to publish the corresponding source, so an organisation that plans to rebrand the interface or change the package name has to account for that obligation. The repository also carries a LICENSE file, a CHANGELOG.md, a RELEASE.md and a.github directory, with the top level built by Gradle through build.gradle.kts and settings.gradle.kts.

Where BasicSync is the wrong tool

Three situations make this the wrong choice. The first is a team that wants a native Android client with its own folder picker, its own sharing screen and no browser involved, because BasicSync deliberately keeps only a folder picker and a QR code scanner as small additions to the web interface, and everything else stays in Syncthing's own pages. The second is a device below Android 8, since the feature list states support for Android 8 and newer and nothing about earlier releases. The third is a workflow that assumes the daemon keeps running in the background without interruption, because the permission list shows how much of Android's power management the app has to negotiate: a foreground service with a special use declaration on Android 14 and newer, battery optimisation exemption, exact alarms for the schedule, and boot completed handling for autostart, which can be turned off in settings. Two further limits are worth naming. The cross-user localhost communication described for separate Android profiles needs the INTERACT_ACROSS_USERS permission granted through adb, so it is not a normal user-facing path, and the documentation does not describe a rollback procedure for a failed upgrade.

Editorial conclusion

Adopt BasicSync if you want Syncthing to live on an Android phone, start and stop on network, battery or schedule conditions, and stay configured through Syncthing's own web interface. Skip it if you want a native Android client with its own folder picker, or if you need it on a device below Android 8. Before installing, confirm the build you download is the one you trust, since the documentation routes prebuilt and signed artifacts through the releases page, and check that the storage model you pick, direct file access or the storage access framework, fits how Syncthing is expected to reach your files.

Frequently asked questions

Official sources

1. chenxiaolong/BasicSync on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases