70 lines
3.1 KiB
Markdown
70 lines
3.1 KiB
Markdown
# MosisService Agent Guidelines
|
|
|
|
## Build, Lint, and Test Commands
|
|
|
|
### Build Commands
|
|
- `./gradlew build` - Build the entire project
|
|
- `./gradlew assembleDebug` - Build debug version
|
|
- `./gradlew assembleRelease` - Build release version
|
|
- `./gradlew clean` - Clean build outputs
|
|
- `./gradlew :app:build` - Build specific module (if needed)
|
|
|
|
### Lint Commands
|
|
- `./gradlew lint` - Run lint checks
|
|
- `./gradlew lintDebug` - Run lint for debug build
|
|
- `./gradlew lintRelease` - Run lint for release build
|
|
|
|
### Test Commands
|
|
- `./gradlew test` - Run unit tests
|
|
- `./gradlew connectedAndroidTest` - Run connected device tests
|
|
- `./gradlew testDebugUnitTest` - Run debug unit tests
|
|
- `./gradlew testReleaseUnitTest` - Run release unit tests
|
|
- `./gradlew :app:test` - Run tests for specific module
|
|
- `./gradlew :app:testDebugUnitTest` - Test specific module debug unit tests
|
|
|
|
**Important Note:** The project contains C++ native code that uses CMake with both `mosis-service` and `mosis-test` libraries defined in `CMakeLists.txt`. Tests are built as shared libraries with the suffix `.so`.
|
|
|
|
## Code Style Guidelines
|
|
|
|
### Naming Conventions
|
|
- `PascalCase` for class and function names (e.g., `MosisService`, `RenderTexture`)
|
|
- `camelCase` for variables and parameters (e.g., `renderTarget`, `inputData`)
|
|
- `UPPER_CASE` for constants (e.g., `MAX_BUFFER_SIZE`, `DEFAULT_TIMEOUT`)
|
|
- Class names should be descriptive and follow Android naming conventions (e.g., `MosisService`)
|
|
- Files should use meaningful names that match their content
|
|
|
|
### Imports & Formatting
|
|
- Import statements are grouped logically: Android imports, third-party imports, first-party imports
|
|
- Imports are sorted alphabetically within each group
|
|
- Use of fully qualified names is allowed for clarity when needed
|
|
|
|
### Types & Variables
|
|
- Use primitive types when possible
|
|
- Use `final` keyword for constants
|
|
- Prefer `val` over `var` in Kotlin
|
|
- Use `final` for native C++ variables that don't change
|
|
- Use appropriate data types (int, long, float, double) based on precision requirements
|
|
|
|
### Error Handling
|
|
- C++ code uses standard C++ exception handling
|
|
- Android code leverages standard Android error handling patterns
|
|
- Use try-catch blocks appropriately in Kotlin code
|
|
- Log errors via Android's logging framework in Kotlin
|
|
- C++ logging via `logger.cpp` component
|
|
|
|
### Coding Standards
|
|
- Follow Android development best practices
|
|
- C++ code should follow modern C++23 conventions (including use of std::span, std::format, etc.)
|
|
- Use RAII (Resource Acquisition Is Initialization) principles in C++
|
|
- Ensure memory management is handled properly in native code
|
|
- Avoid magic numbers in C++ code - use constants instead
|
|
- Use smart pointers like `std::unique_ptr` and `std::shared_ptr` where appropriate
|
|
- Proper resource cleanup in destructors
|
|
- Avoid memory leaks in C++ components
|
|
|
|
### Structure
|
|
- Kotlin code following Android project structures
|
|
- C++ code organized in separate files within `src/main/cpp/`
|
|
- Clear separation between platform-specific code and shared logic
|
|
- Use Android build system capabilities for multi-architecture support
|
|
- Follow Gradle conventions for dependency management |