Thanks for contributing. This project includes performance-sensitive Android and C++ runtime paths, so review quality is more important than change volume.
- Fix root causes, not symptoms.
- Keep pull requests focused on one objective.
- Preserve behavior unless the change scope explicitly includes behavior updates.
- Prefer simple and maintainable implementations.
flowchart LR
A[Create topic branch] --> B[Implement changes]
B --> C[Validate locally]
C --> D[Update docs if needed]
D --> E[Open pull request]
- Create a topic branch from
master. - Implement with minimal unrelated edits.
- Validate locally (build + on-device test).
- Update docs when behavior, architecture, settings, or workflow changed.
- Open a pull request with clear evidence of validation.
Run before opening a pull request:
./gradlew.bat clean assembleDebugIf your change affects detection, tracking, or aim control:
- Install the debug APK on a test device.
- Verify basic detection works (enemies detected and boxes drawn).
- Verify aim assist tracks and releases correctly (if root available).
- Check logcat for errors or warnings.
If your change touches training or export:
- Run the affected scripts in
training/scripts/. - Include output summary and report paths in your PR.
- No placeholder implementations, dead code, or commented-out blocks.
- Keep naming consistent with existing module conventions.
- Keep hot paths efficient: no allocations, no locks, no logging in per-frame loops.
- Avoid unrelated formatting-only churn.
- Do not mix broad refactors with behavior changes in the same pull request.
These paths run every frame. Extra care is required:
| Path | File | Rules |
|---|---|---|
| Inference loop | esp_jni.cpp |
No allocs, no locks, pre-allocated buffers only |
| Target tracker | target_tracker.cpp |
Fixed-size arrays, no heap, no logging |
| Aim controller | aimbot_controller.cpp |
Snapshot settings, no blocking, bounded math |
| Overlay render | imgui_menu.cpp |
No setting writes during draw, defer saves |
- All settings changes go through
UnifiedSettings::validate()before hot-path use. - New settings must have safe defaults and clamp ranges.
- Preset values must be updated when adding or changing defaults.
Include in your PR description:
- Problem statement: What issue or feature this addresses.
- Technical approach: How you solved it and why.
- Validation output: Build log, device test results, logcat output.
- Risk and rollback notes: For behavior changes, explain how to revert.
- Scope boundaries: What this PR intentionally does not change.
A pull request can be rejected if it:
- Bundles unrelated changes.
- Lacks local validation evidence.
- Introduces architecture drift without clear justification.
- Reduces maintainability or runtime stability.
- Adds per-frame cost without measured benefit.
- Keep docs clear, direct, and easy to follow.
- Use tables for structured data, mermaid diagrams for flows.
- No em dashes. Use commas, periods, or parentheses instead.
- Keep Android and training commands aligned with current repository behavior.
- Use "aim assistant" terminology in user-facing documentation.
- Update these files when relevant:
README.md,docs/, andtraining/README.md.
| What to Update | When |
|---|---|
README.md |
New features, build steps, dependencies |
docs/Architecture.md |
Module changes, threading, data flow |
docs/SettingsGuide.md |
New settings, preset changes, default changes |
docs/Performance.md |
Optimization changes, new telemetry |
docs/Training.md |
Pipeline steps, dataset format, export changes |
docs/Troubleshooting.md |
New known issues, diagnostic steps |
By contributing to this repository, you agree that your contribution is released under the repository license in LICENSE.