Everything outside the game protocol: permissions, third-party SDK wiring, and the Java↔native↔C# bridge. None of it duplicates or gates the SFS2X/HTTP game protocol; this layer is platform shell, cleanly separable from the client a Go reimplementation needs.
Why the permissions you wouldn’t expect
A war-strategy game asking for CAMERA/RECORD_AUDIO/calendar access looks suspicious until traced to real, named features:
Third-party SDK inventory
Cleartext HTTP, by design. usesCleartextTraffic="true" is set at the manifest level; two FunPlus-owned endpoints (analyse-aps.readygo.tech push-analytics beacons, upload-img-aps.readygo.tech/get_apk_ver.php a side-loaded self-update check) are called over plain HTTP. Neither gates gameplay; both are safe to skip for a Go client.
The JNI split for anti-cheat is worth knowing
libanogs.so (Tencent ACE) has a full Java wrapper class (com.gamesafe.ano.AnoSdk) that turns out to be dead code. C# calls into the native library directly via [DllImport("anogs")] P/Invoke, bypassing Java entirely. Its detection/report data appears to travel over a local Unix pipe to Tencent’s own backend, not the FunPlus game server’s wire protocol. 
