wildfirechat/android-chat: the Android client you fork, not the app you install

What wildfirechat/android-chat actually is

The repository is the Android side of Wildfire IM, a commercial instant messaging and real-time audio/video product from Beijing Wildfire Infinite Network Technology. It contains both the SDK source and a working app, and the README states the code was written with secondary development in mind: you can integrate it into an existing application or fork it and build your own product on top.

That framing matters more than any feature list. This is not a consumer chat app you download and use. It is the client half of a client-server system. The server side lives in a separate repository, im-server, alongside app_server, robot_server and push_server. Topics on the repository are chat, im and voip, and the module layout reflects that: avenginekit for audio and video, pttclient for push-to-talk, uikit for the interface layer, plus push variants for Getui and JPush.

The target reader is an Android engineer at a company that has decided to run its own messaging infrastructure, or to embed messaging inside a product it already ships. Individual developers looking for a messaging app to install are not the audience, and the README's own framing assumes you will be editing Java.

The licence gate is the first thing to understand

The README opens with a statement that the default protocol stack can only connect to Wildfire's official service and cannot connect to a self-deployed server, citing anti-fraud compliance requirements. To get a temporary or unrestricted version, the README says to add the vendor on WeChat at wfchat or wildfirechat and apply.

Once you have the unrestricted build, the README gives the replacement step: swap the file ./mars-core-release/mars-core-release.aar and then Clean and Rebuild. The protocol stack is delivered as a prebuilt AAR rather than source, so this is a binary substitution, not a configuration flag. The repository carries a NOASSERTION licence identifier, which means GitHub could not map the LICENSE file to a known template. Read that file yourself before you plan around it; nothing here is legal advice.

The practical consequence is that the open repository is a development kit with a vendor-controlled runtime component. You can read and modify the Java application layer freely, but the networking core is not yours to change, and the conditions under which you may point it at your own server are negotiated with the vendor rather than granted by the licence file.

Building the app: JDK 17, current Android Studio, and a debug APK caveat

The development notes specify JDK 17 and the latest stable Android Studio with its matching gradle. Older IDEs are explicitly untested, and the README says compile problems on them are yours to solve. The repository root has the usual gradlew wrapper, so the build is standard Android tooling.

The README documents a real trap in debug builds. With minification off, an APK built from the command line with ./gradlew clean aDebug, or from Android Studio via Build App Bundle(s)/APK(s) -> Build APK(s), does not support audio and video calls. The README attributes this to useFullClasspathForDexingTransform and links to a Google issue tracker entry.

There are two documented ways around it. Turning on minification for debug builds, by setting chat/build.gradle#buildTypes#debug#minifyEnabled to true, makes the debug APK behave normally. Alternatively, build a release APK, which the README says works correctly.

./gradlew clean aDebug

That command produces the debug APK the README warns about. If you are testing calls, expect them to fail until you either enable minification for the debug build type or move to a release build.

Before any of this, one more edit is required for anyone doing secondary development. The app uses Bugly for log collection, and the README asks you to replace the bugly id in MyApp.java with your own, otherwise crash logs go to the vendor's account and you cannot see them.

Package name, push configuration and the files that break when you rename

The README is direct about the applicationId: do not ship under the demo's package name, because the vendor changes it periodically. Renaming is not a single-line edit. The README states that changing the package name causes the build to fail unless you also update the package_name field in google-services.json and agconnect-services.json, and that push integration requires regenerating both files. If you want to change the package name of client, mars-core-release or avenginekit.aar, the README says to contact the vendor instead.

This is a fork-and-rebrand workflow with a known set of friction points, and the documentation names them rather than leaving you to discover them at build time. The push modules are split by vendor, push-getui and push-jpush at the repository root, so the push path you configure depends on which provider you use.

Security defaults you must change before shipping

The README states that HTTP network requests are permitted by default to make deployment and testing easier, and lists the steps to tighten this before going live. Configure HTTPS for app-server and point APP_SERVER_ADDRESS at the HTTPS address. If you use the open platform, do the same for it and set WORKSPACE_URL. If you use the organization structure service, set ORG_SERVER_ADDRESS to an HTTPS address. Then set android:usesCleartextTraffic to false in chat/src/main/AndroidManifest.xml.

That last step is the one people skip. Leaving cleartext traffic enabled while the three addresses are already HTTPS means the app still accepts plain HTTP from anywhere, which defeats the purpose of the other changes.

The permission list is worth reading before you ship too. The README documents android.permission.PROCESS_OUTGOING_CALLS, which lets a normal phone call interrupt an audio or video call and is not requested by default; android.permission.SYSTEM_ALERT_WINDOW, which allows the call window to minimize and float above other windows; and the BLUETOOTH and BLUETOOTH_ADMIN permissions for Bluetooth headsets during calls. Each is tied to a specific calling feature, so you can decide per permission whether your product needs it.

Android 4.x lives on a different branch

The repository description advertises support from Android 4.x to the latest, but the README qualifies it. Android 4.x support is on the api-19 branch, not on master. The README also warns that build failures there may be caused by an outdated protocol stack for that version, and says to contact the vendor on WeChat at wfchat to get an update.

So the 4.x claim is real but conditional, and it depends on the vendor updating a binary you do not control. If your deployment target includes very old devices, budget for a conversation with the vendor and for the possibility that the api-19 branch lags behind master. If you only target modern Android, this branch is irrelevant to you.

How it compares to building on Matrix or Signal's client libraries

The closest alternative approach is Matrix: an open protocol with independent server implementations, where a client like Element Android talks to any homeserver. The difference is where control sits. With Matrix you choose the server, and the client is one implementation among several. With wildfirechat/android-chat, the server is Wildfire's im-server, the client is this repository, and the protocol stack ships as a prebuilt AAR that by default refuses non-official servers.

Signal's approach is the other pole: a single client and a single service, with the protocol designed so that federation is not a goal. Wildfire sits between the two. It sells private deployment as a feature, but the open client enforces a vendor gate until you obtain the unrestricted binary.

The trade-off is coherent rather than accidental. Wildfire is selling a supported product with a compliance story, and the gate is how it keeps that story intact. If you want a stack where the client and server are both fully yours with no vendor approval step, this is the wrong repository. If you want a commercially supported IM and VoIP stack where the hard real-time parts are maintained by someone else, the arrangement is the point.

Editorial conclusion

Adopt wildfirechat/android-chat if you are building an Android IM product on top of Wildfire's server suite and can live with the vendor's licensing gate: the default protocol stack connects only to Wildfire's official service, and unlimited or self-hosted builds require contacting the vendor on WeChat. Do not adopt it if you need a permissively licensed, fully self-contained IM stack with no vendor in the loop, or if you need Android 4.x, which lives on a separate api-19 branch rather than master. Before committing, verify three things: that you can obtain the unrestricted mars-core-release.aar, that the gradle build succeeds on JDK 17 with a current Android Studio, and that the debug APK you produce actually places audio and video calls, which the README says fails when minifyEnabled is false.

Frequently asked questions

Official sources

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