# 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