If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/duixcom/Duix-Mobile shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 3w ago
• 7 active contributors
• Distributed ownership (top contributor 44% of recent commits)
• Other licensed
• Tests present
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live duixcom/Duix-Mobile repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/duixcom/Duix-Mobile.

What it runs against: a local clone of duixcom/Duix-Mobile — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in duixcom/Duix-Mobile | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 52 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of duixcom/Duix-Mobile. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/duixcom/Duix-Mobile.git
#   cd Duix-Mobile
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of duixcom/Duix-Mobile and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "duixcom/Duix-Mobile(\\.git)?\\b" \\
  && ok "origin remote is duixcom/Duix-Mobile" \\
  || miss "origin remote is not duixcom/Duix-Mobile (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp" \\
  && ok "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp" \\
  || miss "missing critical file: duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp"
test -f "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.h" \\
  && ok "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.h" \\
  || miss "missing critical file: duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.h"
test -f "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.h" \\
  && ok "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.h" \\
  || miss "missing critical file: duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.h"
test -f "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/munet.h" \\
  && ok "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/munet.h" \\
  || miss "missing critical file: duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/munet.h"
test -f "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/gj_aes.h" \\
  && ok "duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/gj_aes.h" \\
  || miss "missing critical file: duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/gj_aes.h"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 52 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~22d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/duixcom/Duix-Mobile"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Duix Mobile is an open-source SDK enabling developers to deploy real-time interactive AI avatars directly on mobile devices and embedded screens with <1.5s latency and no cloud dependency. It combines C++ core rendering (18.9M LOC) with platform-specific bindings (Android/Kotlin, iOS/Objective-C) to deliver natural facial animations, streaming audio synthesis, and sub-120ms response times on consumer hardware like Snapdragon 8 Gen 2. Monorepo structure: duix-android/dh_aigc_android/duix-sdk/ contains Android SDK with native JNI layer (src/main/cpp/android/DuixJni.cpp, src/main/cpp/dhcore/), AES encryption utilities, and resource_loader.jar for asset management. Parallel duix-ios/ branch mirrors iOS. CMakeLists.txt orchestrates cross-platform C++ compilation.

Mobile developers (Android/iOS), embedded systems engineers, and product teams building conversational AI interfaces (customer service bots, virtual doctors, tutors) who need on-device deployment without cloud round-trips. They target finance/government sectors requiring privacy and network resilience.

Actively developed with significant C++ foundation (18.9M LOC) but unclear on test coverage and CI maturity from visible files. Project has formal structure (monorepo with Android/iOS subdirs, build.gradle v8.1.2, CMakeLists.txt), suggesting production intent, but no visible GitHub Actions or test directories in file list warrant caution.

Heavy C++ dependency (18.9M LOC) creates maintenance burden; build complexity spans CMake, Gradle, and Xcode with minimum SDK 24 (Android) and unspecified iOS version. No visible dependency lock files or test harness suggests integration testing may be manual. Single owner (duixcom) and opaque native layer increase vendor lock-in risk.

Repository documents v0.0.2 (versionCode=2) with SDK stabilization focus: Android build uses Gradle 8.1.2, Kotlin 1.8.10; proguard-rules.pro and consumer-rules.pro active (obfuscation/API surface control). README emphasizes 4 public avatar downloads and streaming audio support as headline features. No visible recent commit hash, but structure suggests ongoing avatar model optimization.

Clone and setup Android: git clone https://github.com/duixcom/Duix-Mobile.git && cd duix-android/dh_aigc_android && ./gradlew build. For iOS: open duix-ios/GJLocalDigitalDemo/ in Xcode. Install dependencies via Gradle (Android) or CocoaPods (iOS, inferred). Requires Android SDK 24+ and Xcode with Metal support.

Daily commands: Android: cd duix-android/dh_aigc_android && ./gradlew assembleDebug. iOS: cd duix-ios/GJLocalDigitalDemo && xcodebuild -scheme GJLocalDigitalDemo. No explicit dev server; this is SDK-style deployment, not a service. Executables run on-device.

• duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp — Primary JNI bridge between Java/Kotlin and native C++ core; all avatar rendering and AI processing enters/exits here
• duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.h — Core avatar engine header defining the main API surface for avatar initialization, rendering, and lifecycle management
• duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.h — Audio processing and speech recognition (ASR) integration layer; critical for real-time voice input handling
• duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/munet.h — Neural network inference module for avatar animation blending and face expression synthesis
• duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/gj_aes.h — Encryption/decryption engine for secure credential and model parameter handling in on-device deployment
• duix-android/dh_aigc_android/duix-sdk/build.gradle — SDK build configuration controlling NDK compilation, library linking, and artifact publishing
• duix-android/dh_aigc_android/duix-sdk/src/main/AndroidManifest.xml — Declares SDK permissions, JNI library loading, and integration points for host application

Add a new LLM backend integration

1. Create a new header in duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/ defining the LLM interface (e.g., text_input → animation_token_stream) (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.h)
2. Implement the interface in a new .cpp file and add source to CMakeLists.txt target_sources() (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/CMakeLists.txt)
3. Register the LLM module in DuixJni.cpp's initialization function, exposing it via JNI_OnLoad() (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp)
4. Call the LLM from gjduix.cpp's main animation update loop to feed responses into munet.h inference (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/duix/gjduix.cpp)

Add a custom TTS voice module

1. Create TTS synthesizer header in duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/ with PCM output interface (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhpcm.h)
2. Implement PCM buffer filling in a new .cpp file; register in CMakeLists.txt (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/CMakeLists.txt)
3. Wire TTS output into the audio pipeline by modifying dhwenet.cpp to consume synthesized frames (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.cpp)
4. Expose TTS control (start/stop synthesis) via JNI in DuixJni.cpp (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp)

Add a new avatar animation model

1. Convert the animation model to ONNX format and encrypt it with AES (use gj_aes.h utilities) (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/gj_aes.h)
2. Place encrypted .onnx file in SDK assets and add decryption key to secure config (duix-android/dh_aigc_android/duix-sdk/src/main/AndroidManifest.xml)
3. Modify munet.cpp to load and initialize the new model alongside existing inference graphs (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/munet.cpp)
4. Test animation blending by running existing test vectors in dhunet/blendgram.cpp (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhunet/blendgram.cpp)

Integrate a third-party ASR engine

1. Create ASR adapter header in dhmfcc/ that implements the WeNet interface (dhwenet.h contract) (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/dhwenet.h)
2. Implement the adapter .cpp and add to CMakeLists.txt; ensure MFCC output matches WeNet feature format (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/dhmfcc/mfcc.cpp)
3. Update dhwenet.cpp to call your adapter's inference function instead of WeNet's (duix-android/d)

CMake version not pinned: build.gradle references NDK implicitly; verify NDK version matches c++ flags in CMakeLists.txt. AES encryption in CI: aes/ folder has standalone makefile alongside CMake; ensure only CMake path is used in automated builds. Proguard obfuscation: consumer-rules.pro expects specific class names; modifying internal class names breaks downstream apps. Metal on iOS: GPU rendering requires Metal capability; older iOS devices or simulators may fall back to software rendering (undocumented). Avatar model size: resource_loader.jar is binary; git-lfs may not be configured, causing shallow clones to fail.

• JNI (Java Native Interface) — Duix bridges Kotlin/Java SDK to C++ engine via JNI in DuixJni.cpp; understanding method signatures, object marshalling, and lifetime management is critical for Android integration
• AES Streaming Encryption (CBC mode) — Avatar model files are encrypted with AES-CBC (see gaes_stream.cc); developers must understand key management and decryption pipeline to load custom avatars securely
• CMake cross-compilation — CMakeLists.txt compiles C++ core for Android NDK with ABI targeting (arm64-v8a, armeabi-v7a); misconfiguring architecture flags breaks 120ms latency guarantee
• Streaming Audio Synthesis & Barge-in — Duix's headline feature: synthesize and speak simultaneously while allowing user interruption; requires non-blocking audio I/O and interrupt handler state machines
• Metal GPU Rendering (iOS) — iOS avatar rendering uses Metal for sub-120ms facial animation; understanding Metal command buffers and texture pipelines is required for iOS optimization
• ProGuard Obfuscation (Android) — consumer-rules.pro defines class name mappings that must not change; breaking obfuscation rules silently breaks downstream app integration
• On-device Model Inference (vs. Cloud) — Duix's core advantage is <1.5s latency via local inference; requires understanding model quantization, inference batching, and GPU memory constraints on mobile

• openai/gpt-4 — LLM integration point for avatar conversational logic; Duix Mobile docs cite LLM/ASR/TTS modularity
• google/mediapipe — Alternative face detection and animation framework; MediaPipe offers similar on-device facial landmarks processing used in avatar lip-sync
• mozilla/TTS — Open-source text-to-speech engine compatible with Duix's streaming audio synthesis requirement
• Azure/Azure-Kinect-Sensor-SDK — On-device biometric capture SDK; complements Duix for input (voice, facial expressions) in closed-loop avatar interaction
• tensorflow/tensorflow-lite — Inference framework for embedded avatar AI models; Duix's C++ core likely uses TFLite for on-device model execution

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add CMake build verification and cross-architecture support documentation for duix-sdk/src/main/cpp

The C++ native code in duix-sdk (CMakeLists.txt, AES encryption, audio processing, JNI bindings) lacks documented build verification. With multiple architectures (ARM, ARM64, x86, x86_64) and complex dependencies (AudioFFT, dhwenet, AES modules), contributors need clear guidance on building for different Android NDK versions and architectures. A GitHub Actions workflow to verify CMake builds for all supported architectures would catch regressions early.

• [ ] Create .github/workflows/android-ndk-build.yml to test CMake builds against duix-android/dh_aigc_android/duix-sdk/src/main/cpp/CMakeLists.txt
• [ ] Test builds for armeabi-v7a, arm64-v8a, x86, and x86_64 architectures using Android NDK
• [ ] Document in duix-android/dh_aigc_android/README.md the exact NDK version required and build commands
• [ ] Verify AES, MFCC, and dhcore modules compile without warnings

Add instrumented Android unit tests for JNI layer (DuixJni.cpp / JniHelper.cpp)

The JNI bridge code (duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp and JniHelper.cpp) is critical for Java-C++ interop but has no visible test coverage. Adding Android instrumented tests would ensure JNI calls, exception handling, and memory safety work correctly across different Android versions (API 24+). This is especially important for real-time avatar rendering with <1.5s latency constraints.

• [ ] Create duix-android/dh_aigc_android/duix-sdk/src/androidTest/java/DuixJniTest.kt with tests for core JNI method signatures
• [ ] Add test fixtures in duix-android/dh_aigc_android/duix-sdk/src/androidTest/resources/ for mock avatar data
• [ ] Test JNI exception propagation and resource cleanup (Log.cpp lifecycle)
• [ ] Add androidTestImplementation dependencies to duix-sdk/build.gradle for AndroidX Test + Espresso

Create build.gradle dependency audit and version alignment across modules

The Gradle configuration uses Aliyun/Maven Central mirrors and JitPack, but duix-sdk/build.gradle dependencies are not shown in the file structure. With multiple modules (main app + SDK + possibly demo), dependency version mismatches and transitive conflicts can cause build failures. An automated Gradle dependency report and version constraint documentation would help contributors avoid subtle ABI/NDK incompatibilities.

• [ ] Add ./gradlew dependencyReport task documentation to duix-android/dh_aigc_android/README.md
• [ ] Create duix-android/gradle/dependency-locks.json or gradle.lockfile to pin transitive deps
• [ ] Document in duix-sdk/build.gradle why buildToolsVersion='30.0.2' is pinned (may be incompatible with newer compileSdk=33)
• [ ] Add Gradle configuration validation step to .github/workflows/ to catch version drift

• Add unit tests for JNI bridge in duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/JniHelper.cpp—currently no visible test suite for native ↔ Java marshalling; mock AES encrypt/decrypt calls.
• Document build troubleshooting in duix-android/dh_aigc_android/README.md for NDK version mismatches (e.g., 'r23b vs r24')—CMakeLists.txt uses implicit NDK; add explicit version check or gradle.properties override.
• Add Kotlin example app to duix-android/dh_aigc_android/ demonstrating avatar initialization, audio streaming, and barge-in interrupt handling—README references these features but no runnable Kotlin sample exists.

• High · Hardcoded Keystore File — duix-android/dh_aigc_android/demo.jks. The repository contains a demo.jks keystore file (duix-android/dh_aigc_android/demo.jks) which is a signing certificate for Android applications. If this is used for production or contains sensitive credentials, it represents a significant security risk as it may allow unauthorized signing of APKs. Fix: Remove demo.jks from version control. Use secure key management practices such as storing keys in CI/CD secrets, hardware security modules, or dedicated key management services. Never commit sensitive keys to repositories.
• High · Multiple Unverified Maven Repositories — build.gradle (buildscript and allprojects sections). The build.gradle configuration includes multiple Maven repositories without verification mechanisms, including Aliyun mirrors and JitPack. This increases the risk of dependency confusion attacks or man-in-the-middle attacks where malicious packages could be injected. Fix: Implement repository pinning, use only official/trusted repositories, enable repository verification, implement dependency scanning, and consider using a private artifact repository with access controls.
• Medium · Custom AES Cryptography Implementation — duix-android/dh_aigc_android/duix-sdk/src/main/cpp/aes/. The codebase contains custom AES implementation files (aes_cbc.c, aes_core.c, aes_ecb.c) instead of using proven cryptographic libraries. Custom crypto implementations are prone to vulnerabilities like timing attacks, padding oracle attacks, and implementation errors. Fix: Replace custom AES implementations with well-tested cryptographic libraries (e.g., OpenSSL, Bouncy Castle, or Android's built-in javax.crypto). Have any remaining cryptographic code reviewed by security experts.
• Medium · Outdated Gradle and Build Tools — build.gradle (classpath and ext sections). The project uses Gradle 8.1.2 and buildTools 30.0.2. While Gradle 8.1.2 is relatively recent, buildTools version 30.0.2 is outdated (released in 2020) and may lack security patches and modern security features. Fix: Update to the latest stable versions of Gradle and Android build tools. Review the Android Security & Privacy Bulletin for any relevant patches and update minSdkVersion and targetSdkVersion to support modern Android versions.
• Medium · Kotlin Plugin Version — build.gradle (classpath dependency). Kotlin gradle plugin version 1.8.10 is used. While not critically outdated, there may be known vulnerabilities or security issues in older Kotlin versions. Fix: Update Kotlin plugin to the latest stable version (currently 1.9.x or newer). Monitor the Kotlin security advisories for any known issues.
• Medium · JNI Bridge Security Concerns — duix-android/dh_aigc_android/duix-sdk/src/main/cpp/android/DuixJni.cpp, JniHelper.cpp. The presence of JniHelper.cpp and DuixJni.cpp indicates Java-Native Interface usage. Without proper input validation and boundary checking in native code, this creates risks for buffer overflows, memory corruption, and arbitrary code execution. Fix: Implement strict input validation for all JNI calls. Use safe string handling functions. Perform security code review of native code. Consider using automated vulnerability scanners for C/C++ code (AddressSanitizer, MemorySanitizer).
• Low · Missing Security Certificates or Configuration — duix-android/dh_aigc_android/duix-sdk/src/main/AndroidManifest.xml. No evidence of certificate pinning, security policy files (network_security_config.xml), or Android Manifest hardening visible in the provided structure. Fix: Implement certificate pinning for API communications. Create a network_security_config.xml with certificate pinning. Harden AndroidManifest.xml with appropriate security attributes (usesCleartextTraffic=false, etc.).
• Low · Lack of Dependency Lock File — undefined. No gradle.lock or version constraints visible, which means dependency versions can float and potentially introduce vulnerable transitive dependencies. Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.