AListLiteAndroid: Running OpenList on Android 5.0 and Later

Why AListLiteAndroid Exists on Android

AListLiteAndroid addresses a specific deployment problem: running an AList service, now described by the project as OpenList, on an Android phone or television without first installing Termux and arranging the service through command-line procedures. The README positions the application as an immediately usable Android server rather than a client for browsing files. Its intended users include people who want to host a file-list interface from an Android device, operate it from a TV, or administer the service from a PC on the same network.

The package includes OpenList itself. Based on the compatibility section, it integrates the Go implementation and provides binaries for `x86_64`, `x86`, `arm64-v8a`, and `armeabi-v7a`. The minimum Android version is 5.0, corresponding to SDK API 21. This device and architecture coverage matters because an application that merely links to the OpenList project would not tell the user whether a packaged Android build can run on the target hardware. AListLiteAndroid makes that compatibility part of the application distribution.

The app centers on service control rather than a large Android management surface. The documented controls include a start and stop switch, an Android status tile on Android 7.0 or later, background operation, boot startup, update checks, password settings, remote-access QR codes, and an advanced configuration editor. This makes it closer to a packaged server appliance than a conventional Android utility. The README does not document a separate web-based installation process because the application is itself the server package.

There is a security-sensitive boundary in this design. A local file service can expose storage and administrative functions once it is reachable from another device. AListLiteAndroid simplifies startup, but the documented configuration surface is broad enough that operators must still make network and credential decisions. The convenience addresses deployment complexity, not every operational security concern.

OpenList Packaging and Android Service Flow

The repository layout contains an Android application under `app/`, Gradle project files, and an `AListLib/` directory. The README explicitly states that the application integrates the Go implementation of OpenList. This points to a packaged Android project rather than a browser-only wrapper. The exact process-launch and binding code is not included in the documentation, so the repository description cannot establish which Android service class is used or how lifecycle changes are implemented.

The documented data flow is straightforward at the user level. Opening the app and activating its upper-right switch starts the embedded OpenList service. After startup succeeds, the app displays the AList front-end page. The README recommends configuring the service from a PC after startup, while a browser on the device can access `http://localhost:5244`. That address identifies the conventional AList service endpoint supplied by this project, but it does not mean every installation remains on that port. The advanced configuration page permits manual changes to the port, HTTPS settings, database configuration, and other AList settings.

Android lifecycle support is exposed through application features rather than a documented API. Users can grant storage, notification, and background-running permissions, then inspect their status from the `权限配置` page. Boot startup requires both permission and a separate system-level autostart switch. That two-part requirement is important: granting Android permission does not, by itself, guarantee startup after reboot.

For Android 7.0 and later, the app can publish a quick-control tile. A TV-oriented workflow is also reflected in the remote-access QR code. The README says the QR code lets a user configure a service running on a TV from a mobile device. It does not specify the network discovery protocol, pairing rules, or whether the QR code changes after configuration, so those details should not be assumed.

Installing AListLiteAndroid and Starting the First Service

The README does not provide Gradle build instructions, command-line installation steps, or an Android SDK configuration procedure. It directs users to prebuilt release packages on GitHub or Gitte, with an additional Tianyi Cloud distribution option. Install the release that matches the device architecture, open it on an Android phone or television, and proceed to the first-run permission screen. The README says the app requests the relevant storage, notification, and background-running permissions. A reviewer can open the upper-right `+` page to inspect whether each permission was granted.

After permissions are settled, return to the main page and use the upper-right switch to start the service. The expected result is that the service starts successfully and the AList front-end appears. On the same Android device, the documented local address is:

http://localhost:5244

The example is presented as text because the README gives a browser URL rather than a shell command. The documentation recommends completing subsequent configuration from a PC once the service is running. That implies network reachability from the PC, but the README does not explain router forwarding, firewall rules, DNS, or binding addresses, so it does not provide a complete remote-access tutorial.

The default administrator credentials are documented as `admin` / `123456`. Change them from the upper-right `+` menu by selecting `密码设置`. Do this before any other client uses the service. The advanced configuration page also exposes manual AList settings, including HTTPS and database configuration. Its own warning is direct: an incorrect configuration can prevent startup. For a first use, changing the password and confirming local access are documented operations. Editing several unfamiliar settings before the first successful login makes diagnosis harder.

Permissions, Autostart, and Remote-Access Constraints

Background availability is central to the project, but Android makes that feature policy-dependent. AListLiteAndroid requests storage, notification, and background-running permissions. For boot startup, the README says users must grant the relevant permissions and then manually enable the app's autostart switch in system settings. Consequently, an app update or a device migration may require permission review even if the service previously started after reboot.

The status tile is limited to Android N, version 7.0, and newer. On those devices, users can add an AListLite tile to the control area and start or stop the service without opening the full interface. This feature does not appear to apply to Android 5.0 or 6.0 devices. The distinction matters when managing mixed fleets of old phones and televisions.

Remote access is presented as a QR-code workflow from the `远程访问` page. The documentation does not say whether this feature creates a temporary session, exposes the full administrative interface, changes firewall rules, or requires a particular companion application. It should therefore be treated as an undocumented security boundary until its actual behavior is verified on the target device. Likewise, allowing a PC to reach the Android server requires network reachability, but the README does not state how the service is exposed across interfaces.

For television use, the application is designed to fit the device category and offers a mobile-assisted configuration path. That is useful for interfaces without an easy browser workflow. It does not establish that every television OS grants the same background, notification, or autostart permissions. Device vendor behavior remains an adoption condition, not something the README promises to normalize.

Configuration Errors, Default Credentials, and Upgrade Scope

The largest operational risk stated by the project is an incorrect advanced configuration. Because users can directly modify AList configuration, a malformed port, HTTPS setting, or database value can stop the service from starting. The README provides no configuration validation procedure, backup command, reset button, or rollback documentation. There is also no documented recovery flow for replacing a bad configuration file. An operator who changes settings should therefore retain a known-good copy before editing, although the application itself does not promise automatic restoration.

The default `admin` / `123456` login is another explicit concern. The application exposes a dedicated password-setting screen, so changing it is straightforward within the documented UI. Nevertheless, the package does not claim to enforce strong credentials, two-factor authentication, or an allowlist for administrative requests. Those features cannot be inferred from a QR code or a local web interface.

Updates are checked automatically each time the app opens, and the `检查更新` page can perform a manual check. Recent release names connect AListLite versions to upstream OpenList versions, such as `v3.0.1-auto7` being based on OpenList v4.2.6. This makes upstream version tracking visible to users, but it does not document migration notes for every bundled change. Before upgrading an instance that stores meaningful metadata, verify the release notes and preserve a usable copy of the relevant database or configuration.

The repository is not archived, and its last push was on 2026-09-02. Releases were published on 2026-09-02, 2026-08-10, and 2026-07-24, which indicates recent release activity. This does not by itself describe support duration or compatibility testing coverage. The `AGPL-3.0` license also matters to redistributors and network-service operators. This review does not interpret the license's legal obligations; organizations modifying or distributing the application should review the included `LICENSE` directly.

AListLiteAndroid Compared with a Termux OpenList Setup

The README gives the practical comparison point: users do not need to install Termux to follow the referenced Android service tutorial. A Termux-based approach would involve preparing a command-line environment and managing the OpenList process through terminal procedures, while AListLiteAndroid packages the server and exposes it through an Android interface with a switch, status tile, and configuration pages. AListLiteAndroid reduces the number of Android setup components for this specific use case.

That convenience comes with a narrower documented control surface. The README does not provide shell commands for inspecting processes, reading logs, backing up data, or restoring configuration. It also does not describe how to choose or update an OpenList binary independently of the app. Users who need explicit operating-system service control and text-based administration may prefer a Termux deployment, if that extra setup is acceptable.

The embedded approach is still not a separate hosted cloud service. OpenList runs on the selected Android phone or television, and storage access depends on Android permissions and device storage. The package is therefore most appropriate when the Android device is intentionally the host. It is the wrong tool when the hosting device is disposable, difficult to update, subject to aggressive vendor power management, or outside the operator's control.

The key distinction is packaging versus capability. AListLiteAndroid does not appear to add a new storage backend or replace OpenList's configuration model. It embeds OpenList and supplies Android-specific lifecycle controls. That judgment follows from the README's compatibility statement and the existence of `AListLib/`; claims about individual storage drivers remain outside this repository's documentation.

Editorial conclusion

AListLiteAndroid is appropriate for an Android phone or television that needs a self-contained OpenList instance and where installing Termux is inconvenient. It is less suitable for users who need documented production networking controls, rollback procedures, or a hardened initial configuration. Before exposing the service beyond the local device, first verify the changed administrator password, review the advanced configuration, restricted network access, and confirmed that the required Android permissions and startup behavior match the device policy.

Frequently asked questions

Official sources

1. LeoHaoVIP/AListLiteAndroid on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases