This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/node/SmsManager.kt
Line: 484-502

Comment:
**No SQL-level LIMIT/OFFSET — all matching rows loaded into cursor**

The `contentResolver.query()` call fetches _all_ SMS messages matching the filter with no row-count cap, and the Kotlin loop then manually applies `limit`/`offset` after the fact. On a device with thousands of SMS messages this causes the cursor to load every matching row into memory before the first message is returned.

Other handlers in this codebase already append `LIMIT` to the `sortOrder` string (e.g. `ContactsHandler` uses `"… COLLATE NOCASE ASC LIMIT ${request.limit}"` and `CalendarHandler` uses `"… ASC LIMIT ${request.limit}"`). The same technique works for the Telephony SMS provider:

```kotlin
val sortOrder = "${Telephony.Sms.DATE} DESC LIMIT ${params.limit} OFFSET ${params.offset}"

val cursor = context.contentResolver.query(
    Telephony.Sms.CONTENT_URI,
    arrayOf( /* … columns … */ ),
    selection,
    selectionArgsArray,
    sortOrder
)

cursor?.use {
    // index columns as before
    var count = 0
    while (it.moveToNext() && count < params.limit) {
        // map row → SmsMessage
        count++
    }
}
```

With this change the `moveToPosition(offset - 1)` dance can also be removed, keeping the cursor traversal simpler.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/node/InvokeCommandRegistry.kt
Line: 192-195

Comment:
**`sms.search` gated on `SmsAvailable` which requires SEND_SMS**

`InvokeCommandAvailability.SmsAvailable` resolves to `flags.smsAvailable`, which is set from `sms.canSendSms()` in `NodeRuntime`. `canSendSms()` checks `hasSmsPermission()` (i.e. `SEND_SMS`) **and** `hasTelephonyFeature()`.

`sms.search` only needs `READ_SMS`, not `SEND_SMS`. If a user declines `SEND_SMS` but grants `READ_SMS` (which is possible through system settings), `sms.search` will not be advertised or dispatched by the node even though it could succeed at runtime.

Consider either:
- Introducing a dedicated `ReadSmsAvailable` availability variant that calls `sms.hasReadSmsPermission() && sms.hasTelephonyFeature()`, or
- Leaving `availability` unset (defaulting to `Always`) and relying solely on the runtime permission check in `SmsHandler.handleSmsSearch`.

The UI currently requests both permissions together, but the availability logic should reflect the actual requirement of the command to stay correct independent of the UI flow.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/android/app/src/main/java/ai/openclaw/app/node/SmsManager.kt
Line: 131-134

Comment:
**`Telephony.Sms.PERSON` is deprecated and rarely populated**

`Telephony.Sms.PERSON` was deprecated in API 29. On modern Android it typically returns `null` or an opaque internal contact ID (not a human-readable name). Exposing it in the API response may confuse callers who expect a display name there.

Options:
- Remove the `person` field entirely (callers can resolve the name from `address` via the Contacts provider if needed).
- Rename it to `personId` with documentation noting its deprecated/internal nature.
- Resolve the contact display name at query time using `ContactsContract` (though that adds latency and an extra permission dependency).

At minimum, the docstring for `search()` should clarify that `person` is an internal ID, not a display name.

How can I resolve this? If you propose a fix, please make it concise.