MosisService/docs/AGENTS.md

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