AsterLink: one app to parse shares and manage 17 cloud drives

One Flutter app covering both a phone and a desktop

AsterLink, distributed under the name wenxi, is a Flutter application for Android and Windows that combines cloud drive parsing, account management, file transfer and media playback. The stated platforms are Android 7.0 and above for an arm64 APK, and Windows 10 or 11 for an x64 installer. The desktop build uses a side navigation and a wide layout, while the phone build has four main tabs, and both present the same four screens: share parsing, drive management, transfer management and settings.

The practical problem it addresses is fragmentation. Anyone who stores files across several providers ends up with several apps, several transfer queues and several places where a shared link was seen once and then lost. AsterLink puts the parse step, the file listing, the download queue and the favourites into one interface, and adds a local network feature that lets a phone and a computer hand files to each other.

The build side is not hidden. The project states that it is developed with Flutter 3.41.4, Dart 3.11.1 and Go 1.24.7, and points to a build document under docs. The repository layout shows a normal Flutter tree with lib, test, tool, config, assets, android and windows directories, plus a vendor_plugins directory, a native directory, an analysis_options.yaml file and a pubspec.lock, so the Dart dependency set is pinned.

Getting the build and running the first share parse

The project notes give no command line, no package manager entry and no container recipe for this project. Installation is a download: the Releases page of the repository is where the installers live, and the table lists an arm64 APK for Android 7.0 and above and an x64 installer for Windows 10 or 11. The compile path is documented separately in docs/BUILDING.md, and the environment it names is Flutter 3.41.4, Dart 3.11.1 and Go 1.24.7, with the project built on Flutter, Gopeed and media_kit.

The first run follows a four step path in the documentation. To reach your own files, open the drive tab, pick a platform and sign in, then adjust the ordering, hide platforms you do not use or add a second account for the same provider. To work with someone else's link, go to the parse tab, paste the link or the entire share text, check the extraction code and start the parse. If the share came as a Chinese text code, the separate code entry point asks you to choose the matching drive first, since the code alone does not identify the service.

From the file list you can download or preview, and the star at the top of the list saves the whole share to favourites. Transfers are then managed in their own tab, where download and upload queues are switched between, progress is visible, and pause, cancel and retry are available, with the phone overlay window available as an option. The three release tags published in October 2026, v1.0.7+107, v1.1.0+110 and v1.5.0+150, carry the build numbers, which is useful when reporting an issue since the issue template asks for the version.

Seventeen drive sources, and a count that does not quite add up

The project notes state that 17 cloud drives plus a GitHub file source are connected, and that 15 of the drives support share link parsing. Quark, Xunlei and UC each get a separate entry point for their own share codes alongside the ordinary link field, and the drive list supports custom sorting and hiding, with accounts that can be renamed and whose configuration is kept.

Two of the sources are limited on purpose. The Lanzou Youxiang edition and Tencent Weiyun offer personal file management only and do not parse share links for now. The GitHub source is not a drive at all, and covers repository files and release attachments instead. The project notes also state that file operations and download capability depend on the platform and the permissions of the account, which is the honest version of what a multi-provider app can promise.

The documentation has a small inconsistency worth knowing about. The repository description says the project supports parsing for 16 mainstream cloud drives, while the project notes say 17 drives plus the GitHub source with 15 supporting share parsing. Anyone writing their own expectations against the project should count from the table in the project notes, since that is the list with the per-provider limits spelled out. The tables also show the release names, with v1.5.0+150 on 2026-10-06, v1.1.0+110 on 2026-10-04 and v1.0.7+107 on 2026-10-01.

One transfer queue for drives, HTTP links, magnets and torrents

The download side is where an aggregator can either add value or add a bottleneck, and AsterLink clearly tries to add value. The unified download manager handles drive files, HTTP and HTTPS links, magnet links and BT seeds, with pause, resume, retry on failure, batch operations, and settings for connection count, task count and speed limits. Uploads get their own separate queue, so leaving a file page does not stop the upload, and on Android the notification bar shows transfer state.

On the phone there is a floating window for transfers. It shows download and upload progress at the same time, can be dragged, resized and collapsed into a floating ball, and after three idle seconds it docks to the edge of the screen and hides itself half way. That is a small feature with a real cost: an overlay window on a phone is exactly the kind of thing a manufacturer battery policy tends to attack, so it is worth checking how your device handles it.

Backup and restore are handled locally rather than through a server. Accounts, settings and favourites can be exported with a password, and restored on a new device or after a reinstall, optionally carrying the background images along. The issue template asks for the version, system, steps and a redacted error message, and explicitly asks people not to upload account passwords, cookies or account backups, which is a reasonable request given what the app stores.

Playback that keeps going while the file downloads

Preview and playback sit on top of the same transfer machinery. Images, text and audio or video can be previewed, and the player offers resume from a saved position, playlists, playback speed, audio track and subtitle selection, screenshots, a sleep timer, aspect ratio and subtitle appearance settings. On Android a third party player can be chosen, and supported tasks can play while they download, which is the behaviour that makes a large remote video usable on a slow link.

The project is built on Flutter with Gopeed and media_kit, and the third party notice file in assets/licenses records that those components keep their own licences. The media stack is the reason the feature set looks like a player rather than a file browser, and it is also the reason the build needs a Go toolchain in the documented environment, since a native sidecar has to be produced for each platform.

A caveat applies to everything in this section. Whether a file can be previewed at all depends on the provider, the account tier and the link type, and the project notes say as much. A provider that only hands out an indirect download URL will not stream, and the fallback is the transfer queue rather than the player.

Sharing over the local network without a server

Device interconnection is the feature that has no equivalent in the individual provider apps. Two devices on the same local network can exchange text, links, files and folders. The phone side has to be switched on manually, while the Windows build enables it when the page is opened and shows a connection QR code that can be enlarged. Once connected, you can pick a device from the list and send, reply from an inbox, and share files through time limited links or QR codes.

The implementation avoids a cloud relay, which matters for two reasons. A transfer of a large file stays on the local network, and the project does not have to operate a file hosting service to be useful. The cost is that the feature only works inside one network segment, so a phone on cellular data and a laptop on office wifi will not see each other.

The remote announcement system is the counterweight to that. The parse page can show several remote illustrated announcements, with Markdown formatting, pinning and read state, and the configuration is described in a separate document under docs. A repository root also carries a standalone remote configuration editor page, so the announcement content can be maintained without touching the app. Treat that channel as a distribution dependency: it is remote content rendered inside the app, which is a different trust model from everything else here, which is local.

Theming, storage switching and the per provider limits

The settings surface is deeper than a colour picker. There are five colour schemes and three glass effects, with light, dark and follow system modes, and customisable day and night backgrounds with brightness, blur and card opacity settings, where the phone and the desktop remember their own crop positions. Accounts can be renamed, drives can be reordered or hidden, and favourites can hold share links, files and folders with their extraction codes kept so a share can be parsed again quickly.

Drive specific behaviour shows up in a few places. Alibaba Cloud Drive can switch between a resource library, a backup drive and an album, and supported China Mobile, Tianyi and Unicom accounts can browse a family cloud. The parse page recognises full share text, extracts codes and pulls out several links at once, and keeps a parse history. The independent search page supports type filters, search history and searching inside subdirectories, and the file list supports multi select, upload, new folders and the rename, move, delete and share actions the provider allows.

A shared file over the local network can be offered as a time limited link, and the transfer settings let you cap connection counts, task counts and speed. The project notes also point out that different drive interfaces, account entitlements and network conditions affect speed and feature availability, and that connection counts are adjusted per platform limits. That is the kind of sentence that only appears in a project that has watched its integrations break.

Where AsterLink is the wrong choice

The first limitation is legal and structural. The project is licensed under AGPL-3.0, it states that third party components keep their own licences, that drive names and marks belong to their respective services, and that it is not an official client of any drive. AGPL-3.0 is a serious obligation for anyone who modifies the program and offers it over a network, and it is a poor fit for a company that plans to wrap the app in its own product. The project publishes a licensing scope document under docs for a reason, and a deployment should read it before anything else.

The second limitation is that every integration depends on behaviour the provider does not promise. Parsing works by following the link and the account session, and the resulting flows break when a provider changes a redirect, a token format or a rate limit. The project notes are candid that capabilities follow the platform and the account, and the support request asking for redacted error text is a hint that provider changes are a recurring source of reports.

The third is the scope of the aggregate. Files still live in the providers, so the app is a control surface and not a backup, and the LAN feature only covers one local network. And the project itself offers the alternative implicitly: if you only need one provider, that provider's own client plus a standalone download manager such as the Gopeed component the app is built on will be simpler and better supported. AsterLink earns its place when you actually have many accounts, since that is the case where a single aggregated queue and a single favourites list remove real friction.

Editorial conclusion

Adopt AsterLink if you juggle several Chinese cloud drives and want one place for share parsing, account switching, transfers and playback on both a phone and a desktop, and if you are willing to run an AGPL-3.0 application that stores every account in one local export. Do not adopt it if you need a supported client for any provider, if your accounts live under enterprise policies that forbid third party access, or if you need offline access to files that only exist inside a drive. Before you install, check the drive count in the project notes against the 16 named in the repository description, read the AGPL-3.0 obligations in docs/LICENSING.md, and confirm from the Releases page that an arm64 APK and a Windows x64 installer exist for your devices.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. z7786/wenxi on GitHub