shadowsocks-android documents a build, not an install, and leaves the config questions unanswered

The prerequisite list is a cross-compile toolchain, not an install step

Everything the documentation tells you to do is aimed at a person compiling the client rather than a person installing it. The prerequisites are JDK 11+, the Android SDK, the Android NDK, and a Rust installation carrying four Android targets, added with

rustup target add armv7-linux-androideabi aarch64-linux-android i686-linux-android x86_64-linux-android

The four architectures are named one by one, which tells you the Rust core is cross-compiled for arm, arm64, x86 and x86_64 rather than built for the host machine. Consequence: the documented path from this repository to a running app is an Android toolchain plus a Rust cross toolchain, so a reader who only wanted the client has to decide whether that is worth a build environment. No lighter route than the source build is documented, and the build step is offered as Android Studio or the gradle script rather than one named command.

Two Play packages carry the install path, and one of them is still beta

Distribution is handled by two Google Play listings with different scopes. The package id com.github.shadowsocks covers Android and Chrome OS, and com.github.shadowsocks.tv covers Android TV, and both listings link a beta channel served through Play App Testing. The android-arsenal badge at the top marks the app at API level 23 as its minimum. What the README does not include is any direct APK download link, any F-Droid listing, or an install path through GitHub releases, even though a badge links the releases page for people who want the source builds. Consequence: someone searching the web for a Shadowsocks APK finds no instruction in this repository for obtaining one, and the only documented channel is a store account, a boundary the reader has to clear on their own before the app exists on the device.

The build text points at Travis while the badge advertises CircleCI

There are two continuous integration systems in the tree and the instructions refer to the older one. The README tells a contributor to check whether the latest commit builds in a UNIX environment by looking at Travis status, and .travis.yml sits at the top level of the repository. The badge in the header, though, is a CircleCI badge, and a .circleci/ directory is listed next to .github/ in the top-level entries. Consequence: the single instruction the build section gives for confirming that master is healthy refers to a different service than the one shown above it, so a contributor following the text lands on a different signal from the one the header advertises. Two CI configurations also mean two places where a build can drift, and nothing in the build text says which one is authoritative.

A plain clone leaves you with a tree that will not link

The repository is a superproject, and both halves of that fact are given in the same breath:

git clone --recurse-submodules <repo>
git submodule update --init --recursive

The requirement comes from the .gitmodules file in the top-level listing, which is where the native pieces are declared to live elsewhere. The open source licenses section names what those pieces are: libevent, tun2socks, redsocks and shadowsocks-rust, with libsodium and OpenSSL underneath them. Consequence: a clone without the recursive flag gives you source files whose C and Rust dependencies are simply absent, and the failure surfaces late, at link time, with an error that does not point back at the clone command. The build text does not list which paths the submodules occupy, so you cannot tell in advance what should be present in a correct working tree.

The last numbered stable is v5.3.4 from October 2024

The release history is short and uneven, and the newest named build is a nightly. The tags run v5.3.3 on 2023-02-07, v5.3.4 on 2024-10-07, and v5.3.5-nightly on 2026-02-10, while the most recent push to master is dated 2026-08-09. Consequence: a reader who wants a numbered, non-preview build has v5.3.4 from October 2024 as the most recent option, roughly a year and a half behind the current tree, and the only 2026 artifact carries a nightly suffix, which is a weaker promise than a stable tag. Six months also separate that nightly from the last push, so the published nightly is not the same code as master either. A release.sh script sits in the tree, so tagging is automated, but nothing here describes the cut procedure or who performs it.

Six vendored licenses stack under the project's own GPL-3.0

The licensing here is a stack rather than a single grant. The project's own terms are the GNU General Public License, version 3 or later, with 2017 copyright lines naming Max Lv and Mygod Studio. Alongside that, six components carried inside the build are listed under other terms: redsocks under the Apache License 2.0, libevent and tun2socks under BSD, shadowsocks-rust under MIT, libsodium under ISC, and OpenSSL under its own license file. Consequence: a redistributor of a modified build carries GPL-3.0 obligations next to an Apache 2.0 notice and four permissive licenses, and the Apache component sits in a different license family from the one the project itself uses, which matters if you intend to combine code from these parts. The license field on the repository reads NOASSERTION, so automated tooling sees no license at all and has to open LICENSE to find the GPL text.

Nothing here explains what the app does on the network

This is the limit worth stating plainly: the repository answers none of the questions its readers arrive with. The documentation is a build sheet covering prerequisites, the clone step, and the Play Store packages. It does not describe the protocol, how a server is configured, how encryption methods are chosen, what routing behavior to expect, or how a failure presents itself. The mobile/, tv/, core/ and plugin/ modules in the tree suggest where such material might live, and privacy_policy.md and CONTRIBUTING.md cover two adjacent concerns, but no configuration guide, protocol description, or troubleshooting section is present. Consequence: for operational questions about a specific server, cipher, or routing rule, this repository is the wrong document, and a reader who treats the build sheet as the manual ends up with a working compile and no understanding of the traffic the app produces.

Editorial conclusion

Use this repository if you intend to build the client yourself, audit what ships inside it, or follow its release history, since the build steps and the license stack are specific and checkable. Do not rely on it for protocol behaviour, server configuration, or detection questions, because none of that is written down here. Before you build, confirm which tag you want, since the last numbered stable is v5.3.4 from October 2024 and the only 2026 artifact is a nightly, and confirm your toolchain matches the JDK 11, NDK and four Rust Android targets the build expects.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes