The default android-chat build only reaches Wildfire's own server, and cleartext HTTP is on

The shipped protocol stack only connects to the vendor's own service

The first section of the Chinese-language README is a declaration, not an introduction. It states that for anti-fraud compliance reasons the protocol stack in this project by default supports connecting only to Wildfire's official service and cannot connect to a self-deployed service. A temporary version or an unrestricted version is obtained by adding the maintainers on WeChat, under the names wfchat or wildfirechat, and the request is described as free. The file then adds that using the project for fraud is strictly prohibited, and that after obtaining an unrestricted build you replace the ./mars-core-release/mars-core-release.aar file and then clean and rebuild. The protocol stack is therefore the one component you cannot get from the public tree, and the tree confirms it: mars-core-release/ sits beside the source modules as a prebuilt archive.

Three archive modules have package names you are told not to change

The package name rules are the part of this file that will cost you the most time. Developers are told not to reuse the demo's package name or applicationId at all, because the maintainers change it periodically. Changing it breaks the build until the package_name field in both google-services.json and agconnect-services.json is updated to match, and for push integration both of those files have to be regenerated. The README goes further and names the modules whose package names cannot be edited by you: client, mars-core-release and avenginekit.aar, where the instruction is to contact the maintainers. That leaves three prebuilt pieces in an otherwise source-distributed SDK, all with fixed identifiers.

At minSdk 21 the debug build quietly loses audio and video calling

A dedicated section covers a failure that produces no error. With obfuscation switched off, a debug APK produced on the command line or through the Build APK(s) menu does not support audio and video calls, and the file links a Google issue tracker entry about useFullClassForDexingTransform as the underlying reason. The fix is to turn obfuscation on for debug builds as well, by setting the minifyEnabled value of the debug build type in chat/build.gradle to true, after which the debug APK behaves normally. Release APKs are unaffected. The two task names are abbreviated rather than descriptive:

./gradlew clean aDebug
./gradlew clean aR

The build section adds JDK 17, the latest stable Android Studio with its matching gradle, and the note that older IDE versions are untested and that compile problems there are for the developer to solve.

Cleartext HTTP is the default and three separate addresses have to be moved

The security section opens by saying that HTTP requests are permitted by default so that deployment and testing stay convenient. Five steps follow for going live. Configure HTTPS for app-server and point APP_SERVER_ADDRESS at an HTTPS address. If an open platform is supported, configure HTTPS for the developer platform and point WORKSPACE_URL at it. If organizational structures are supported, configure HTTPS for that service and point ORG_SERVER_ADDRESS at it. Then set android:usesCleartextTraffic to false in the manifest at chat/src/main/AndroidManifest.xml. Three different keys, three different backends, and an assumption that you run the app server, the workspace and the org service, so a deployment that only runs the first one still needs the other two reviewed.

The Bugly identifier in MyApp.java ships pointing at someone else

Crash reporting goes through Bugly, and the secondary development section carries a warning about the shipped value: replace the bugly id in MyApp.java with your own, or error logs will be delivered to Wildfire's account, you will not receive your own crash data, and their log stream will be polluted with yours. It is the kind of default that looks harmless in a demo and is easy to miss in a fork, and it sits alongside the package name warning in the same file. Two other build-time requirements appear nearby: the lifecycle dependency must be at version 2.2.0 or above for the obfuscation rules to work, and chat/proguard-rules.pro holds the reference configuration.

The license carries NoDerivs while the file walks you through modifying it

Three sources describe the terms and none of them agree on shape. Repository license metadata reads NOASSERTION, a LICENSE file sits in the root, and the License section of the README states that the project is under the Creative Commons Attribution-NoDerivs 3.0 Unported license. That is the no-derivatives variant of an attribution license, and the same README spends most of its length telling you to change the applicationId, regenerate service files, flip minifyEnabled for debug builds and edit the manifest. Settle that tension before investing in a fork. Credits are also spelled out: the image picker and emoji work derives from LQRWeChat, with butterKnife and OkHttp among the other dependencies, all icons come from icons8, and the animated images were collected from the web.

Android 4.x lives on its own branch with a protocol stack that lags

The repository description advertises support back to Android 4.x, and the README explains how that is arranged: use the api-19 branch rather than master. If compilation fails there, the stated reason is that the protocol stack version for the 4.x line has not been updated in time, and the fix is to contact wfchat on WeChat for an update. The current branch targets minSdkVersion 21, so the two lines are maintained separately and the older one depends on vendor-supplied binaries. Release tags tell a similar story: among the three most recent releases, the newest is v1.3.7 dated 2025-11-13, with v1.3.3 in April 2025 and v1.3.2, tagged as the internationalization release, in March 2025, while the last recorded push to the default branch is 2026-09-23.

Background delivery is delegated to vendor push, and three of them are in the tree

The push section explains that once your app is in the background, each phone maker applies its own policy and the process may be frozen or killed quickly or eventually, so receiving messages in that state needs the manufacturer's push notification service. The push server must therefore be deployed separately, with its code available from both GitHub and the Gitee mirror. The tree shows how many paths that opens: push/ alongside push-aar-dep/, push-getui/ and push-jpush/, which correspond to the archive, Getui and JPush integrations, and the earlier package name rule explains why google-services.json and agconnect-services.json both appear in the build. Two more files at the root, PAD_ADAPTATION_PLAN.md and PAD_ADAPTATION_REVIEW.md, are named without explanation anywhere in the Chinese file.

Editorial conclusion

Treat android-chat as a starting point that needs vendor contact before it can run against your own infrastructure, not as a self-hostable SDK you can clone and point elsewhere. Anyone evaluating it should first settle the protocol stack question, then replace the shipped Bugly identifier, move the three server addresses to HTTPS and disable cleartext traffic, and check the NoDerivs license terms against the amount of forking the integration steps assume. The Android 4.x path lives on a separate branch with a protocol stack that lags master.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wildfirechat/android-chat on GitHub