Please address the comments from this code review:

## Overall Comments
- In `AndroidNativeControlUnitMgr`, the `MethodParam` string fields (e.g., `package_name`, `client_type`, `text`) are set to `std::string::c_str()` from function parameters; if the external library uses these pointers asynchronously, this will dangle—consider documenting or enforcing synchronous use, or storing the strings in member-owned storage so their lifetime is guaranteed during and after the call as needed.
- The `scroll(int dx, int dy)` method in `AndroidNativeControlUnitMgr` lacks an `override` specifier unlike the other ControlUnit overrides; if it is meant to implement a virtual in `ControlUnitAPI`, consider adding `override` for consistency and to catch signature mismatches at compile time.

## Individual Comments

### Comment 1
<location path="source/MaaAndroidNativeControlUnit/Manager/AndroidNativeControlUnitMgr.h" line_range="53" />
<code_context>
+    bool key_down(int key) override;
+    bool key_up(int key) override;
+
+    bool scroll(int dx, int dy);
+
+    bool inactive() override;
</code_context>
<issue_to_address>
**issue (bug_risk):** The scroll method is missing an override specifier and may not match the base class signature.

Please add `override` to `scroll` and verify its full signature (including constness and parameter types) exactly matches the declaration in `ControlUnitAPI`. Otherwise, calls via a `ControlUnitAPI*` may not dispatch to this implementation as intended.
</issue_to_address>

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="source/MaaAndroidNativeControlUnit/General/AndroidExternalLib.h" line_range="147-156" />
<code_context>
+
+MAA_NS_BEGIN
+
+class AndroidNativeExternalLibraryHolder : public LibraryHolder<AndroidNativeExternalLibraryHolder>
+{
+public:
+    static std::optional<AndroidNativeNS::AndroidExternalFunctions>
+        create_functions(const std::filesystem::path& library_path);
+
+private:
+    static constexpr std::string get_locked_pixels_func_name_ = "GetLockedPixels";
+    static constexpr std::string unlock_pixels_func_name_ = "UnlockPixels";
+    static constexpr std::string attach_thread_func_name_ = "AttachThread";
+    static constexpr std::string detach_thread_func_name_ = "DetachThread";
+    static constexpr std::string dispatch_input_message_func_name_ = "DispatchInputMessage";
+};
+
</code_context>
<issue_to_address>
**issue (bug_risk):** The `static constexpr std::string` members are ill-formed; use `const char*` or `inline const std::string` instead.

`std::string` is not a literal type, so these declarations won’t compile as `static constexpr`. Use either:

```cpp
static constexpr const char* get_locked_pixels_func_name_ = "GetLockedPixels";
// ... etc
```

or, if you specifically need `std::string` and are on C++17+:

```cpp
static inline const std::string get_locked_pixels_func_name_ = "GetLockedPixels";
// ... etc
```
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- In `AndroidNativeExternalLibraryHolder`, the static function name members are declared as `static constexpr std::string`, which is ill-formed on many standard/library combinations; consider making them `inline static constexpr const char[]` (or `constexpr std::string_view`) and passing those to `get_function` instead.
- In `AndroidNativeControlUnitMgr::screencap`, the captured frame is always treated as `CV_8UC3` without consulting the `ImageFormat` or bytes-per-pixel implied by `stride`; if the external library returns RGBA or other formats this will misinterpret the data, so it would be safer either to check `ImageFormat` and convert appropriately or to document and assert the expected format.

## Individual Comments

### Comment 1
<location path=".github/workflows/build.yml" line_range="406-415" />
<code_context>
+            - name: Build MAA
</code_context>
<issue_to_address>
**suggestion (bug_risk):** Preset name and install build_dir logic are duplicated and can drift over time.

The `matrix.arch` → preset name → build directory mapping is defined twice: once in `Build MAA` (`preset`) and again in `Install` (`build_dir`). If either changes independently, `cmake --install` may target the wrong directory. Please centralize this mapping (e.g., derive a single build-dir env var from `matrix.arch` and use it for both steps) to keep them in sync.

Suggested implementation:

```
            - name: Build MAA
              shell: bash
              run: |
                  if [[ "${{ matrix.arch }}" == "x86_64" ]]; then
                      preset='NinjaMulti Android x64'
                      build_dir='build/android/x64'
                  else
                      preset='NinjaMulti Android arm64'
                      build_dir='build/android/arm64'
                  fi

                  # Export for subsequent steps (e.g. Install)
                  echo "MAA_BUILD_PRESET=$preset" >> "$GITHUB_ENV"
                  echo "MAA_BUILD_DIR=$build_dir" >> "$GITHUB_ENV"

                  cmake --preset "$preset" --build "$build_dir"

```

To fully implement the suggestion and avoid drift between `Build MAA` and `Install`, you should also:

1. Locate the `Install` step that currently derives `build_dir` based on `matrix.arch` (or the preset) and remove that local mapping logic.
2. Replace any usage of the locally computed `build_dir` in the `Install` step with the centralized environment variable:
   - Use `${{ env.MAA_BUILD_DIR }}` for the CMake install directory, for example:
     `cmake --install "${{ env.MAA_BUILD_DIR }}"` (and similarly for any other references to the build directory).
3. If the actual build directory paths differ from `build/android/x64` and `build/android/arm64`, adjust the `build_dir` assignments in the updated `Build MAA` step to match your existing layout so that both steps remain consistent.
</issue_to_address>

### Comment 2
<location path="CMakeLists.txt" line_range="12" />
<code_context>
 option(WITH_ADB_CONTROLLER "build with adb controller" ON)
 option(WITH_WIN32_CONTROLLER "build with win32 controller" ON)
 option(WITH_MACOS_CONTROLLER "build with macOS controller" ON)
+option(WITH_ANDROID_NATIVE_CONTROLLER "build with android native controller" ON)
 option(WITH_CUSTOM_CONTROLLER "build with custom controller" ON)
 option(WITH_PLAYCOVER_CONTROLLER "build with PlayCover controller for macOS" ON)
</code_context>
<issue_to_address>
**suggestion (typo):** Consider capitalizing "Android" in the option description for consistency and correctness.

The help string uses lowercase "android" while other messages use capitalized "Android" as a proper noun. Please update this description to "build with Android native controller" for consistency.

```suggestion
option(WITH_ANDROID_NATIVE_CONTROLLER "build with Android native controller" ON)
```
</issue_to_address>

Please address the comments from this code review:

## Overall Comments
- The Android-specific thread attach logic is currently split between `ControllerAgent` (via `ScopedAndroidNativeThreadAttach` and a `dynamic_pointer_cast`) and the control unit itself; consider centralizing this RAII attach/detach handling in the Android-native control unit layer (or a shared helper) so `ControllerAgent` can remain platform-agnostic and avoid the Android-specific `#ifdef`/cast.

## Individual Comments

### Comment 1
<location path="docs/en_us/2.2-IntegratedInterfaceOverview.md" line_range="267" />
<code_context>
+
+Create an Android native controller backed by `MaaAndroidNativeControlUnit` for native screenshot and input on Android.
+
+> `screen_resolution` must match both the control unit's raw screenshot resolution and touch coordinate space, otherwise screencap fails immediately.
+
 ### MaaCustomControllerCreate
</code_context>
<issue_to_address>
**nitpick (typo):** Consider fixing the comma splice in this sentence for clearer grammar.

The phrase `, otherwise` joins two independent clauses and creates a comma splice. Consider instead: `...touch coordinate space; otherwise, screencap fails immediately.` or `...touch coordinate space. Otherwise, screencap fails immediately.`

```suggestion
> `screen_resolution` must match both the control unit's raw screenshot resolution and touch coordinate space; otherwise, screencap fails immediately.
```
</issue_to_address>