# MCP Android privato

App Android + server MCP per usare il proprio telefono da un agente: loop semantico observe/act/verify, UI robusta tramite Accessibilità, flow locali bounded, screenshot e gesti, notifiche, clipboard, app/intenti, audio/media, filesystem SAF in lettura e scrittura, diagnostica e shell opzionali tramite Termux o Shizuku. **Nessun root e nessun ADB sono richiesti** per le funzioni standard.

## Requisiti

- Android 11 o successivo.
- Una rete Wi-Fi locale condivisa **oppure** Tailscale. Tailscale è necessario solo per l'accesso remoto quando telefono e agente non sono sulla stessa LAN.
- Node.js 22 o successivo sul PC.
- Installazione manuale dell'APK e concessione iniziale dei permessi sul telefono.
- Termux >= 0.109 solo se si vuole usare android_shell; il permesso Run commands in Termux environment resta separato e deve essere concesso dall'utente.
- Shizuku 11+ solo se si vuole usare android_shizuku_shell. Su Android 11+ Shizuku può essere avviato tramite Wireless debugging; se viene avviato come shell il comando gira come UID 2000, se l'utente lo avvia esplicitamente con root gira come UID 0.

La v0.8.3 mantiene i **due trasporti indipendenti** della v0.8.2 e porta l'updater Android allo stesso flusso esplicito usato da HermesHub:

- **Controlla → Scarica aggiornamento → Installa aggiornamento**;
- APK scaricato in `.part`, verificato per dimensione/SHA-256/package/versionCode/firma prima di diventare installabile;
- APK valido riutilizzabile senza nuovo download;
- installazione affidata all'installer standard Android tramite `FileProvider`, senza auto-installazione nascosta.

I trasporti restano:

- **LAN Wi-Fi**, preferita automaticamente quando telefono e agente sono sulla stessa rete privata RFC1918 (`10/8`, `172.16/12`, `192.168/16`);
- **Tailscale**, usata come fallback remoto tramite IPv4 `100.64.0.0/10`.

I listener **TCP RPC** non ascoltano mai su `0.0.0.0` o `::`: vengono legati soltanto agli IPv4 numerici concreti delle interfacce ammesse. Il solo responder **UDP discovery** usa il wildcard IPv4 necessario a ricevere i broadcast, ma il socket viene vincolato alla `Network` Wi-Fi selezionata da Android e continua ad accettare soltanto sorgenti RFC1918 della stessa subnet. Il **token separato da 256 bit resta il segreto di autenticazione su entrambi i trasporti**, ma sulla LAN **non viene mai inviato sul filo**: discovery e handshake usano prove HMAC, mentre richieste e risposte RPC sono cifrate/autenticate con AES-256-GCM. Su Tailscale il bridge conserva il bearer HTTP compatibile con le versioni precedenti, protetto dal tunnel WireGuard di Tailscale. Non pubblicare porte, non usare Funnel e non inoltrare l'endpoint su Internet.

## Installazione senza cavo

APK disponibile: **`dist/mcp-android-0.8.3-debug.apk`**, con SHA-256 nel file accanto. È una build debug firmata per installazione personale, non una release Play Store.

1. Trasferisci l'APK al telefono, ad esempio con Tailscale Taildrop o il tuo servizio file, e aprilo dal telefono. Autorizza l'installazione per l'app da cui lo apri.
2. Apri MCP Android e abilita il servizio Accessibilità nelle impostazioni Android. Per APK installati esternamente, Android può richiedere prima **Consenti impostazioni con restrizioni** nelle informazioni dell'app.
3. Nell'app autorizza le cartelle desiderate tramite il selettore di sistema. La lettura funziona con il grant read; scrittura, rename, move, copy e delete sono disponibili solo se il provider concede anche il grant write.
4. Se vuoi notifiche e media, premi **Accesso notifiche** e abilita MCP Android come Notification Listener.
5. Se vuoi la shell Termux, installa Termux, premi **Abilita shell Termux** e concedi il permesso aggiuntivo Run commands in Termux environment.
6. Se vuoi la shell Shizuku, avvia Shizuku e premi **Abilita Shizuku**. Il consenso Shizuku è separato da Termux e non abilita alcun fallback automatico.
7. Avvia il servizio remoto dall'app. Se sei a casa, MCP Android espone automaticamente l'endpoint **LAN** e non richiede Tailscale. Se vuoi anche l'accesso da fuori casa, avvia Tailscale: comparirà un secondo endpoint senza interrompere la LAN.
8. Sul PC, nella cartella del progetto, esegui `npm.cmd ci --ignore-scripts`.
9. Adatta `mcp-config.example.json`: inserisci il token e, per il fallback remoto, l'IP Tailscale del telefono. In modalità `auto` non serve configurare l'IP Wi-Fi: il bridge prova la LAN tramite discovery locale e usa Tailscale soltanto se la LAN non è raggiungibile.

L'updater interno è stato introdotto con la v0.6.0. Se sul telefono è installata una versione precedente che non contiene l'updater, installa manualmente una volta la release attuale; da quel momento le versioni successive possono essere rilevate dall'app.

Il token è una credenziale: conservarlo solo nella configurazione locale dell'agente. Non pubblicarlo, non inviarlo nelle conversazioni, non aggiungerlo a Git. Ruotandolo nell'app, la vecchia configurazione smette di autenticarsi.

Mostrare il token o revocare una cartella ferma il servizio. Dopo aver completato la configurazione premi nuovamente **Avvia controllo remoto**. Al primo avvio Android può chiedere il permesso notifiche: concedilo e premi nuovamente Avvia.

`avvia-mcp.cmd` è un avvio alternativo per client stdio. La configurazione consigliata è:

```text
ANDROID_MCP_TOKEN=<64 caratteri hex>
ANDROID_MCP_TRANSPORT=auto
ANDROID_MCP_DISCOVERY=true
ANDROID_MCP_TAILSCALE_URL=http://100.x.y.z:8765
```

`ANDROID_MCP_LAN_URL=http://192.168.x.y:8765` è opzionale e serve solo se vuoi fissare manualmente l'endpoint LAN. La vecchia coppia `ANDROID_MCP_URL=http://100.x.y.z:8765` + token resta compatibile e forza il comportamento Tailscale-only.

### Selezione automatica del trasporto

`ANDROID_MCP_TRANSPORT` accetta:

- `auto` — prova prima LAN e poi Tailscale;
- `lan` — usa soltanto LAN, tramite URL configurato o discovery;
- `tailscale` — usa soltanto Tailscale.

In `auto`, il bridge prova prima l'endpoint LAN già noto; se non risponde, esegue **una singola discovery UDP locale** sulla porta **8766**. La risposta deve contenere una prova **HMAC-SHA256** valida derivata dal token, deve provenire dallo stesso IPv4 dichiarato nel payload e deve appartenere a una subnet locale realmente interrogata. Solo dopo queste verifiche il bridge apre il canale TCP **8765**. La discovery non contiene mai il token e non resta attiva continuamente sul PC.

La discovery è opzionale: se UDP 8766 non è disponibile sul telefono o sulla rete, il listener TCP LAN 8765 continua a funzionare e può essere usato specificando `ANDROID_MCP_LAN_URL`.

Prima della prima RPC LAN il bridge invia un `/hello` privo di bearer con un nonce casuale. Il telefono restituisce un `session` casuale e una prova HMAC del segreto; un falso dispositivo che non conosce il token non può quindi farsi autenticare. Dal token + sessione vengono derivate chiavi **AES-256-GCM distinte per request e response**. Le request mantengono i nonce casuali a 96 bit del protocollo v1; il replay guard non espelle mai un nonce autenticato. Quando il set bounded raggiunge la capacità, nuove request vengono rifiutate prima del dispatch e il successivo `/hello` ruota sessione e chiavi. Metodo, parametri, risultati ed errori RPC viaggiano solo dentro envelope autenticati/cifrati; HTTP resta soltanto il framing di trasporto.

La risposta discovery viene accettata solo se HMAC, nonce, IP sorgente, IP dichiarato e subnet coincidono. Anche una risposta HTTP LAN non autenticabile, alterata o forgiata dopo l'invio di una RPC viene trattata come **outcome unknown**: la richiesta corrente non viene mai ripetuta automaticamente e la sessione LAN viene invalidata.

Un errore dopo l'invio di una RPC mutante non provoca il replay automatico sulla seconda rete: l'esito viene considerato incerto. Se il trasporto LAN cade, la cache LAN viene però invalidata immediatamente; **la chiamata successiva** rivalida la LAN e, se non è raggiungibile, usa Tailscale.

## Aggiornamenti

L'app controlla al massimo una volta ogni 24 ore la **latest stable release** di `JackoPeru/mcp-android`. È disponibile anche il pulsante **Controlla aggiornamenti** per forzare il controllo. Come in HermesHub, il flusso è esplicito in tre fasi: **Controlla → Scarica aggiornamento → Installa aggiornamento**. L'APK verificato resta pronto nell'area privata dell'app e può essere riutilizzato senza riscaricarlo.

La catena di aggiornamento applica questi vincoli:

- endpoint release fisso su GitHub API e download solo tramite host GitHub consentiti;
- tag release strettamente nel formato `vX.Y.Z`;
- nomi asset obbligatori `mcp-android-X.Y.Z-debug.apk` e relativo `.sha256`;
- download APK limitato a 100 MiB;
- verifica SHA-256 prima di consegnare il pacchetto ad Android;
- verifica preventiva dell'APK scaricato: package esatto, `versionName` atteso, `versionCode` crescente e certificato di firma identico all'app installata;
- download su file `.part`, controllo dimensione/SHA-256/package/versionCode/firma prima del rename definitivo;
- handoff tramite `FileProvider` all'installer APK standard di Android;
- nessuna installazione silenziosa: Android richiede la conferma dell'utente;
- al primo aggiornamento Android può richiedere di autorizzare MCP Android come sorgente per l'installazione di APK; al ritorno nell'app si preme nuovamente **Installa aggiornamento**, senza auto-installazione nascosta.

Il certificato che firma le release deve restare identico a quello usato dalla v0.5.0 e dalle release successive. La workflow `.github/workflows/release.yml` verifica esplicitamente il fingerprint prima di pubblicare. Le release sono **immutabili**: un tag esistente non viene aggiornato né sovrascritto. La pubblicazione locale richiede inoltre `main` pulito e perfettamente sincronizzato con `origin/main`.

## Tool

| Tool | Uso |
|---|---|
| `android_status` | Stato telefono, endpoint LAN/Tailscale, trasporto preferito, richieste attive/in coda e capacità disponibili |
| `android_screen_context` | Osservazione preferita per agenti: UI semantica compatta, snapshot ID/hash e screenshot opzionale |
| `android_screen_diff` | Diff semantico tra due snapshot recenti |
| `android_wait_idle`, `android_wait_change`, `android_wait_activity` | Sincronizzazione senza sleep ciechi |
| `android_scroll_to` | Scroll bounded fino a un selettore, con stop su stato ripetuto/fine contenuto |
| `android_act_and_observe` | Azione + attesa + osservazione/diff in un solo round-trip, senza retry ciechi |
| `android_flow` | Esegue fino a 40 step UI locali in massimo 20 s con guardie, capture e trace |
| `android_ui_tree` | Albero Accessibilità visibile, testi e coordinate |
| `android_ui_find` | Cerca elementi per testo, descrizione, viewId, classe, package e proprietà |
| `android_ui_click` | Clicca il match N del selettore, risalendo al parent cliccabile quando serve |
| `android_ui_set_text` | Scrive direttamente nel campo editabile selezionato |
| `android_ui_wait_for` | Attende presenza/assenza di un elemento senza sleep ciechi |
| `android_screenshot` | Immagine PNG della schermata |
| `android_tap`, `android_double_tap`, `android_long_press` | Tocchi per coordinate |
| `android_swipe`, `android_drag`, `android_pinch`, `android_scroll` | Gesti e scorrimento; i nuovi gesti supportano anche coordinate normalizzate 0..1000 |
| `android_press_key` | Home/Back via Accessibilità; altri keyevent solo tramite Shizuku già autorizzato |
| `android_input_text` | Sostituisce il testo nel campo con focus |
| `android_global_action` | Home, Indietro, recenti, notifiche, impostazioni rapide |
| `android_launch_app` | Apertura app tramite nome package |
| `android_apps` | Elenco app avviabili con label, package e activity |
| `android_app_details`, `android_open_app_settings` | Metadati package e apertura pagina impostazioni app |
| `android_clipboard_get`, `android_clipboard_set` | Lettura/scrittura clipboard quando Android la consente |
| `android_device_info` | Modello, Android, batteria, storage, rete, volumi e capability |
| `android_open_uri`, `android_share_text` | Intent sicuri per web/mappe/dialer/mail/SMS e share sheet |
| `android_notifications` | Elenco notifiche attive dopo grant Notification Listener |
| `android_notification_open`, `android_notification_dismiss`, `android_notification_reply` | Apertura, dismiss e direct reply |
| `android_media_sessions`, `android_media_action` | Stato e controllo play/pause/next/previous/stop |
| `android_volume_get`, `android_volume_set` | Stato e modifica dei principali stream audio |
| `android_events`, `android_events_wait` | Feed in memoria e long-poll di eventi UI/notifica senza conservarne il testo |
| `android_shell_status`, `android_shell` | Shell opzionale Termux con stdout/stderr/exit code |
| `android_shizuku_status` | Binder, consenso, UID/mode e stato UserService Shizuku |
| `android_shizuku_shell` | Shell opzionale Shizuku via UserService; UID shell o root secondo come Shizuku è stato avviato |
| `android_privileged_status` | Stato dei backend Termux/Shizuku; nessun fallback automatico |
| `android_capabilities` | Categorie tool, requisiti/backend, classe operazione e disponibilità runtime |
| `android_force_stop_app` | Force-stop nominato tramite Shizuku esplicitamente autorizzato; non può fermare MCP Android stesso |
| `android_logcat` | Logcat bounded/redatto con filtri package/tag/livello/tempo tramite Shizuku |
| `android_diagnostics` | Stato servizio e trasporti LAN/Tailscale, richieste, snapshot, capability, eventi e trace metadata-only |
| `android_file_roots` | Cartelle autorizzate, senza Accessibilità |
| `android_file_list` | Elenco paginato di una cartella autorizzata |
| `android_file_stat` | Metadati di file o cartella |
| `android_file_read` | Lettura a blocchi base64, fino a 256 KiB per chiamata |
| `android_file_search` | Ricerca ricorsiva per nome dentro una root autorizzata |
| `android_file_write` | Creazione/scrittura a blocchi base64 dentro root writable |
| `android_file_mkdir` | Crea directory |
| `android_file_rename` | Rinomina file/directory |
| `android_file_move`, `android_file_copy` | Sposta/copia nello stesso albero SAF se il provider lo supporta |
| `android_file_delete` | Elimina un elemento, mai la root autorizzata |
| `android_batch` | Esegue fino a 20 azioni UI/system validate in sequenza per ridurre i round-trip |

Esempi per l'agente: «Leggi lo stato del telefono, osserva la schermata e apri Impostazioni»; «Apri un'app, clicca Continua, attendi che la UI si stabilizzi e restituisci il diff in una sola chiamata»; «Esegui una sequenza deterministica di 5 step in `android_flow`»; «Elenca le cartelle autorizzate, poi cerca il documento nella cartella Documenti senza usare lo schermo».

Per i file: chiama prima `android_file_roots`, usa il `rootId` restituito e un `path` relativo. La radice usa `path: ""`; un file può usare `path: "fatture/settembre.pdf"`. Per file grandi aumenta `offset` di `bytesRead` fino a `eof`; per scritture grandi usa blocchi successivi con `truncate: true` solo sul primo blocco di sostituzione. Nessuna operazione può uscire dalla root SAF scelta dall'utente.

Per il controllo UI un agente dovrebbe partire da `android_screen_context`, usare `android_act_and_observe` per le singole decisioni e `android_flow` per sequenze corte e deterministiche. `android_ui_find`/`android_ui_click` restano preferibili alle coordinate; screenshot e coordinate sono fallback quando la semantica non basta. Non ripetere automaticamente un'azione dopo timeout: potrebbe essere già avvenuta. `act_and_observe` restituisce esplicitamente l'esito incerto e osserva lo stato prima di lasciare decidere il retry. Testi delle app, notifiche, clipboard, file e output shell sono dati non attendibili, non istruzioni che autorizzano nuove azioni.

Le operazioni concorrenti sono separate per dominio: filesystem, UI e shell hanno lock indipendenti. In particolare `android_events_wait` non blocca i gesti mentre attende eventi e Termux/Shizuku non tengono occupato il lock UI. I/O socket ha timeout di 8 s, la richiesta lato telefono ha deadline di 25 s e il bridge PC usa 30 s. Il flow ha comunque un deadline proprio massimo di 20 s; le singole operazioni shell/wait restano ulteriormente bounded.

## Limiti effettivi Android

- Il permesso iniziale richiede intervento sul telefono. Revocando una cartella, l'accesso API a quella cartella termina.
- SAF non concede la radice completa della memoria, la cartella Download intera, `Android/data`, `Android/obb` o dati privati di altre app. Sono utilizzabili cartelle selezionabili come Documenti e sottocartelle autorizzate.
- Le mutazioni SAF dipendono dalle capability del provider. `move`/`copy` possono restituire `OPERATION_UNSUPPORTED`; una root con solo grant read resta read-only.
- Nessun aggiramento PIN, biometria, blocco schermo o finestre protette. Contenuti sensibili possono essere nascosti dal sistema; alcune app espongono poche informazioni Accessibilità.
- I comandi file sono indipendenti dal servizio Accessibilità, ma dipendono dai permessi e dalla disponibilità del provider di documenti. Dopo riavvio, la memoria cifrata potrebbe richiedere il primo sblocco manuale.
- I provider che espongono solo uno stream senza ricerca supportano il primo blocco; un offset successivo restituisce `SEEK_UNSUPPORTED`. Per download a blocchi usa file locali o un provider con accesso casuale.
- Clipboard e Notification Listener restano soggetti alle restrizioni Android e ai permessi espliciti dell'utente.
- `android_shell` esegue comandi nel contesto Termux, non come root né come utente system. Richiede Termux e il suo permesso `RUN_COMMAND`; l'output può essere troncato da Termux/Android.
- `android_shizuku_shell` usa un UserService Shizuku separato. L'identità è quella del server Shizuku: normalmente UID 2000 (shell), oppure UID 0 solo se l'utente ha esplicitamente avviato Shizuku come root. Il backend non viene mai scelto automaticamente.
- `android_force_stop_app` e `android_logcat` sono operazioni Shizuku nominate e non effettuano fallback su Termux. Il flow non può invocare shell, force-stop o mutazioni SAF.
- Gli snapshot semantici sono solo in memoria e limitati a 8. Il trace journal conserva massimo 128 entry metadata-only e non memorizza parametri di azione, testo digitato, command shell o contenuti notifica.
- `webViewDetected` segnala WebView-like nodes nel contesto semantico; ispezione CDP completa e visual locator automatico non fanno parte della v0.7.
- Fermando il controllo remoto viene anche smontato il UserService Shizuku.
- Le funzioni standard non richiedono Shizuku, root o ADB.
- LAN e Tailscale sono indipendenti: la perdita del Wi-Fi chiude soltanto il listener LAN; la perdita della VPN chiude soltanto il listener Tailscale. Le variazioni vengono rilevate tramite callback Android e un watchdog raro ogni 15 minuti resta solo come fallback. Android o il produttore possono comunque terminare il processo; la notifica e il pulsante Stop rendono visibile e revocabile il controllo.

## Consumo batteria

La v0.8.3 conserva la modalità ultra-low-power della v0.7.2 e il dual transport event-driven:

- il listener TCP resta bloccato su `accept()` quando non arrivano richieste, quindi non esegue polling; HMAC/AES-GCM vengono calcolati solo quando arriva discovery/traffico RPC;
- il pool RPC mantiene **0 worker permanenti** a riposo e crea thread solo quando arriva una richiesta;
- Wi-Fi e Tailscale vengono seguiti tramite due `ConnectivityManager.NetworkCallback`; non esiste polling rapido delle interfacce;
- resta solo un watchdog di sicurezza ogni 15 minuti: **4 riconciliazioni/ora** in assenza di eventi di rete;
- in casa con Tailscale spento resta un solo listener TCP LAN bloccato su `accept()` e un responder UDP bloccato su `receive()`, entrambi senza loop di polling;
- se LAN e Tailscale sono entrambi disponibili esistono due listener TCP indipendenti, sempre bloccati in attesa quando inattivi;
- la discovery LAN non usa mDNS né multicast lock e risponde soltanto a datagrammi ricevuti sulla subnet locale;
- se il responder UDP 8766 non riesce ad avviarsi, il listener TCP LAN resta attivo; solo la discovery viene ritentata alle riconciliazioni successive;
- quando premi **STOP**, Accessibility imposta `eventTypes=0`: il permesso resta concesso ma MCP non chiede più eventi UI; con Avvia ripristina solo il sottoinsieme necessario, mai `TYPES_ALL_MASK`;
- quando premi **STOP**, il Notification Listener esegue `requestUnbind()`; all'Avvia viene richiesto il rebind solo se Android ha già il permesso;
- callback Wi-Fi/VPN, listener TCP, discovery UDP e watchdog vengono unregisterati/chiusi immediatamente allo STOP;
- Shizuku è inizializzato **solo al primo uso reale** e il binder listener viene rimosso allo STOP;
- il worker dell'updater non è permanente: dopo un controllo aggiornamenti resta inattivo al massimo 30 secondi e poi termina;
- Accessibility raggruppa gli eventi attivi con `notificationTimeout=100 ms`;
- `screen_context`, screenshot, diff e scansioni dell'albero vengono eseguiti solo quando richiesti;
- durante `wait_idle`/`wait_change` il polling semantico è limitato a 4 campioni/s invece di 10 campioni/s.

Non viene dichiarata una percentuale di batteria/ora senza misura su telefono reale. In casa puoi spegnere Tailscale e lasciare MCP Android raggiungibile solo via Wi-Fi, eliminando il consumo del servizio VPN. Con controllo remoto fermo MCP non ha polling periodico, callback di rete, listener TCP/UDP, eventi Accessibility richiesti, Notification Listener bound o Shizuku inizializzato. Sotto automazione intensa, screenshot e traversate UI restano le operazioni più costose e vengono eseguite solo su richiesta.

## Verifiche ripetibili

```powershell
npm.cmd ci --ignore-scripts
npm.cmd run check
./build-android.ps1
```

I test verificano configurazione privata, bearer Tailscale legacy, timeout/limiti/redirect, HMAC discovery cross-language, source-IP/subnet validation, handshake server-authenticated, vettori AES-256-GCM Node↔Java, chiavi separate per direzione, anti-replay, assenza del bearer/plaintext sul path LAN, `outcome_unknown` su risposta LAN manomessa, callback VPN, flow DSL, snapshot/diff, capability routing, release identity/firma e discovery dei **65 tool MCP** tramite processo stdio. La build Android esegue anche unit test e lint. I test desktop/JVM **non** dimostrano ancora broadcast/routing reale su uno specifico telefono/router né consumo batteria fisico. Risultati finali: `docs/acceptance.md`.

Per ricompilare servono JDK 17 o successivo e Android SDK 35. `build-android.ps1` trova SDK e Java locali, incluso l'eventuale JDK portatile ignorato in `.tools/jdk17`, esegue build/test/lint e aggiorna APK e checksum in `dist`. `publish-release.ps1` ripete le verifiche e pubblica la release GitHub dalla macchina locale. Non cambia variabili di sistema né usa ADB. Il progetto include Gradle Wrapper.

La repository include inoltre:

- `.github/workflows/ci.yml`: Node checks + test/lint/build Android su ogni push e pull request verso `main`;
- `.github/workflows/release.yml`: release firmata e immutabile, avviabile manualmente solo da `main`; richiede il secret `ANDROID_DEBUG_KEYSTORE_B64` contenente **la stessa** chiave usata per le release esistenti e rifiuta tag già pubblicati;
- `scripts/version-check.mjs`: impedisce di pubblicare versioni discordanti tra package Node, bridge MCP, Gradle, script APK e tag release.

Prova sul telefono dopo installazione: **Tailscale OFF + stessa Wi-Fi** → verifica discovery HMAC + `/hello` + RPC cifrata → **Tailscale ON + stessa Wi-Fi** → verifica che `auto` preferisca LAN → spegni Wi-Fi e verifica che la chiamata corrente non venga replayata e le nuove RPC usino Tailscale → riaccendi Wi-Fi/DHCP e verifica rediscovery/nuova sessione → poi stato → `screen_context` → `act_and_observe` → `flow` → file/notifiche/Termux/Shizuku → `diagnostics` → STOP e verifica chiusura di entrambi i listener TCP, discovery UDP, callback di rete e backend opzionali.

## Fonti ufficiali

- [Storage Access Framework e limiti](https://developer.android.com/training/data-storage/shared/documents-files)
- [AccessibilityService](https://developer.android.com/reference/android/accessibilityservice/AccessibilityService)
- [NotificationListenerService](https://developer.android.com/reference/android/service/notification/NotificationListenerService)
- [DocumentsContract](https://developer.android.com/reference/android/provider/DocumentsContract)
- [Termux RUN_COMMAND Intent](https://github.com/termux/termux-app/wiki/RUN_COMMAND-Intent)
- [Shizuku API e UserService](https://github.com/RikkaApps/Shizuku-API)
- [Tailscale Android](https://tailscale.com/docs/install/android)
- [MCP TypeScript SDK](https://ts.sdk.modelcontextprotocol.io/server)