You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Подключить mcp-android так же как работает MCP PLAYRIGHT #436
docker-android
Это минимальный и настраиваемый Docker-образ, запускающий эмулятор Android в качестве сервиса.
Он основан на Alpine и включает поддержку KVM, а также Java Runtime Environment 11.
Позволяет настраивать версию Android, тип устройства и типы образов, а также поддерживает проброс портов для эмулятора и ADB.
Эмулятор работает в безголовом режиме, что делает его подходящим для CI-систем, и совместим с scrcpy для удалённого управления экраном Android.
Lang: Shell
https://github.com/HQarroum/docker-android
================
👁 News | 👁 Soft | 👁 Hacker
Так же стоит рассмотреть вариант где пользователь подключит свое устройство а агент будет иметь к нему доступ
The automated solution draft encountered an error:
The solver stopped before creating a pull request.
Reason: Repository setup halted - fork divergence requires user decision
What you can do
If the fork's default branch can be overwritten safely, rerun with --allow-fork-divergence-resolution-using-force-push-with-lease to allow a guarded force-with-lease sync.
If the fork has commits you need to preserve, resolve the divergence manually, then rerun the solver.
If this requires elevated Hive Mind access, ask a Hive Mind administrator to handle the affected fork or repository.
Administrator-only CLI details, if any, are printed in the solver terminal log rather than in this GitHub comment.
Можешь изучить как реализовать задачу?
Можно попробовать поюзать: docker-android Это минимальный и настраиваемый Docker-образ, запускающий эмулятор Android в качестве сервиса. Он основан на Alpine и включает поддержку KVM, а также Java Runtime Environment 11. Позволяет настраивать версию Android, тип устройства и типы образов, а также поддерживает проброс портов для эмулятора и ADB. Эмулятор работает в безголовом режиме, что делает его подходящим для CI-систем, и совместим с scrcpy для удалённого управления экраном Android. Lang: Shell https://github.com/HQarroum/docker-android ================ 👁 News | 👁 Soft | 👁 Hacker Так же стоит рассмотреть вариант где пользователь подключит свое устройство а агент будет иметь к нему доступ
Вот проект https://github.com/ProverCoderAI/docker-git Вот аналог с MCP Playright https://github.com/ProverCoderAI/rust-browser-connection
Изучу три репозитория и сведу варианты в конкретную архитектуру: Android через Docker/KVM или физическое устройство через ADB, с MCP/API-интерфейсом, безопасностью и этапами реализации.
Выделил ключевой инвариант: Android должен быть отдельным lifecycle/MCP-модулем, а не ad-hoc командами; агент и пользователь работают с одной сессией через общий визуальный/ADB-канал.
ТАк же было бы полезно понять как можно шерить доступ к своему телефону по сети. Что бы он мог его отлаживать не только по USB но и по сети
Разделю решение на два сценария: локальная Wi‑Fi/ADB‑отладка и безопасный удалённый доступ через интернет без публикации ADB наружу. Заодно проверю актуальный pairing‑протокол и требования к relay для каждого варианта.
Думал на протяжении 16m 53s
Да. Здесь нужно разделить локальную Wi‑Fi‑отладку и передачу доступа удалённому агенту через интернет.
1. Телефон и агент находятся в одной Wi‑Fi-сети
Для Android 11+ используется встроенный Wireless debugging:
Настройки→ Для разработчиков→ Беспроводная отладка→ Сопряжение устройства с помощью кода
На компьютере:
adb pair 192.168.1.25:37099# Ввести код, показанный телефоном.adb devices -l
Если после pairing устройство не подключилось автоматически, можно найти TLS endpoint через mDNS:
adb mdns track-services --proto-text
Нужно найти сервис _adb-tls-connect._tcp, затем:
adb connect 192.168.1.25:37895adb devices -l
После этого доступны обычные команды:
adb -s 192.168.1.25:37895 shelladb -s 192.168.1.25:37895 logcatadb -s 192.168.1.25:37895 install app-debug.apkscrcpy -s 192.168.1.25:37895
Android 11+ использует pairing и TLS, сохраняет доверие к рабочей станции, но штатный сценарий предполагает, что телефон и ADB-host находятся в одной беспроводной сети. Для автоматического обнаружения ADB использует mDNS.
Для docker-git я бы не запускал pairing внутри project-контейнера. mDNS плохо подходит как граница между локальной сетью, Docker-сетью и облачным сервером. Pairing и хранение ADB-ключа должны происходить на пользовательской машине, а проект должен получать уже абстрагированный доступ.
2. Старые Android или временный режим через USB
Android 10 и ниже позволяют сначала включить TCP/IP через USB:
adb devicesadb tcpip 5555
После отключения кабеля:
adb connect 192.168.1.25:5555adb devices -lscrcpy -s 192.168.1.25:5555
Это также поддерживает scrcpy.
Но порт 5555 нельзя публиковать в интернет:
Интернет ─X─> телефон:5555
Такой режим следует использовать только в доверенной LAN или внутри защищённой VPN. После работы:
adb disconnect 192.168.1.25:5555
3. Быстрый удалённый доступ через SSH
Для proof of concept можно не открывать телефон наружу, а передавать по SSH доступ к локальному ADB server.
На компьютере пользователя телефон сначала подключается к ADB — через USB или Wireless debugging:
adb devices -ladb start-server
Затем компьютер пользователя создаёт исходящий reverse SSH tunnel к серверу docker-git:
ssh -NT \ -R 127.0.0.1:15037:127.0.0.1:5037 \ relay-user@docker-git-host
На стороне docker-git-host:
ADB_SERVER_SOCKET=tcp:127.0.0.1:15037 adb devices -l
Эквивалентно:
adb -H 127.0.0.1 -P 15037 devices -l
ADB официально поддерживает подключение клиента к удалённому ADB server через параметры -H и -P. Сам ADB server обычно слушает локальный порт 5037.
Без SSH публиковать ADB server нельзя: соединение между ADB-клиентом и удалённым ADB server не шифруется. Документация scrcpy прямо рекомендует для удалённого сценария SSH tunnel.
Ограничение такого PoC
Удалённый клиент получает доступ не к одному телефону, а потенциально ко всем устройствам, которые видит локальный ADB server:
ADB server├── личный телефон├── тестовый телефон└── эмулятор
Поэтому проброс 5037 приемлем для эксперимента, но не как production-модель.
4. Рекомендуемая production-архитектура: Device Relay
Правильнее сделать отдельный небольшой Rust companion:
docker-git-device-relay
Архитектура:
Android phone │ ├── USB ADB └── Wi‑Fi ADB │ ▼User device relay │ исходящий mTLS/WSS ▼docker-git API │ ▼rust-android-connection │ MCP ▼Agent
У relay нет открытого входящего порта. Он сам устанавливает исходящее соединение с сервером, поэтому работает за NAT, домашним роутером и корпоративным firewall.
Relay хранит локально:
ADB private key;
pairing с телефоном;
реальный ADB serial;
информацию о доступных устройствах;
пользовательское разрешение на доступ.
Сервер получает только виртуальный идентификатор:
relay_7f2/device_pixel_8
а не прямой доступ к 5037 или 5555.
Протокол relay
При подключении:
{ "type": "relay.hello", "relayId": "relay_7f2", "devices": [ { "deviceId": "device_pixel_8", "serial": "192.168.1.25:37895", "model": "Pixel 8", "transport": "wifi", "state": "device" } ]}
Проект запрашивает временную аренду:
{ "type": "lease.acquire", "projectId": "dg-my-project", "deviceId": "device_pixel_8", "ttlSeconds": 3600}
Ответ:
{ "leaseId": "lease_a193", "epoch": 4, "expiresAt": "2026-06-23T18:00:00Z"}
Каждая операция содержит lease:
{ "type": "device.execute", "leaseId": "lease_a193", "epoch": 4, "requestId": "req_42", "operation": { "type": "tap", "x": 540, "y": 920 }}
Основной инвариант:
Lease(d)=p⇒∄q≠p:Lease(d)=qLease(d)=p⇒∃q=p:Lease(d)=q
И дополнительно:
epochrequest=epochsessionepochrequest=epochsession
Старая команда после переподключения или отзыва доступа автоматически отклоняется.
Какие операции разрешать
Relay не должен давать агенту произвольный ADB socket. Лучше передавать типизированные команды:
device.statusdevice.screenshotdevice.ui_dumpdevice.tapdevice.swipedevice.type_textdevice.press_keydevice.launch_appdevice.install_apkdevice.logcatdevice.push_workspace_filedevice.open_url
Опасные операции должны быть выключены:
raw_shellpull_arbitrary_filefactory_resetreboot_bootloaderuninstall_arbitrary_packageclear_app_data
Для них потребуется отдельное разрешение пользователя.
Просмотр экрана
Есть два независимых канала.
Для MVP relay выполняет:
adb -s "$SERIAL" exec-out screencap -p
и передаёт PNG серверу. Это достаточно для управления агентом и web-панели.
Для интерактивного видео relay запускает scrcpy локально и передаёт:
scrcpy video → WSS → docker-git panelpanel input → WSS → relay → scrcpy/ADB
Это лучше, чем запускать scrcpy на облачном сервере через удалённый ADB server: не нужны дополнительные двунаправленные port-forwarding tunnel’ы, видео кодируется рядом с телефоном, а ADB-ключ остаётся у пользователя.
Как встроить в rust-android-connection
Backend’ы должны реализовывать один интерфейс:
#[async_trait]pub trait AndroidTransport { async fn status(&self) -> Result<DeviceStatus>; async fn screenshot(&self) -> Result<Vec<u8>>; async fn ui_dump(&self) -> Result<UiTree>; async fn execute(&self, operation: AndroidOperation) -> Result<OperationResult>; async fn install_apk(&self, apk: &Path) -> Result<InstallResult>; async fn logcat(&self, filter: LogcatFilter) -> Result<String>;}
Реализации:
DockerEmulatorTransportHostAdbTransportRelayTransport
Таким образом MCP не знает, подключён телефон по USB, Wi‑Fi или через интернет:
android_snapshot()android_tap()android_install_apk()android_logcat()
работают одинаково.
Практический выбор
Для использования дома или в офисе:
Android Wireless debugging→ adb pair→ adb connect→ host-adb backend
Для быстрого удалённого прототипа:
локальный ADB server→ reverse SSH tunnel→ ADB_SERVER_SOCKET на сервере
Для продукта:
телефон по USB или Wi‑Fi→ локальный rust device relay→ исходящий mTLS/WSS→ lease-based Android backend
Рекомендуемый вариант для docker-git — именно relay. Он одновременно поддерживает USB и Wi‑Fi, работает через NAT, не публикует ADB-порты и позволяет пользователю в любой момент отозвать доступ.
Читать ресурс
Да. Оптимальная реализация — отдельный rust-android-connection, повторяющий архитектуру rust-browser-connection, а docker-android использовать только как основу эмуляторного backend’а.
Что показало изучение репозиториев
Описание HQarroum/docker-android частично устарело: README всё ещё говорит об Alpine и JRE 11, но текущий Dockerfile основан на eclipse-temurin:25. Текущий compose собирает образ с API 34, запускает его с privileged: true, пробрасывает /dev/kvm и задаёт 16 ГБ RAM и 16 CPU. Сам эмулятор запускается с -no-window, поэтому установленный в образе x11vnc сам по себе не даёт готового веб-интерфейса.
Есть и технический долг: при программном рендеринге используется swiftshader_indirect, а актуальная документация Android Emulator помечает этот режим как устаревший. Значит, образ нужно либо исправлять, либо жёстко фиксировать совместимую версию emulator package.
В docker-git уже реализована почти идеальная архитектурная модель:
один проект соответствует одному внешнему browser-контейнеру;
lifecycle управляется бинарником docker-git-browser-connection;
MCP предоставляется отдельным stdio-бинарником browser-connection;
noVNC и MCP гарантированно используют одну Chromium-сессию;
запуск ленивый и идемпотентный;
API умеет запускать sibling-контейнер, проверять readiness и проксировать UI/CDP.
Именно эту модель следует перенести на Android.
Целевая архитектура
Agent │ MCP stdio ▼android-connection │ ├──────────── AndroidSession(project_id) ─────────────┐ │ │Web panel ── API /a/<project>/... │ ▼ ┌──────────────────────────┐ │ Backend │ │ │ │ 1. Docker emulator │ │ 2. Host ADB │ │ 3. User device relay │ └──────────────────────────┘
Предлагаемый новый репозиторий:
ProverCoderAI/rust-android-connection├── src/core/│ ├── spec.rs│ ├── session.rs│ ├── state.rs│ ├── naming.rs│ └── lease.rs├── src/backends/│ ├── emulator.rs│ ├── host_adb.rs│ └── relay.rs├── src/adb/├── src/mcp.rs├── src/bin/android-connection.rs└── src/bin/docker-git-android-connection.rs
Два бинарника:
docker-git-android-connection start | status | stop | probe | attach | detachandroid-connection MCP stdio server для Codex / Claude / Gemini / Grok
Android не стоит добавлять внутрь rust-browser-connection: общими являются Docker lifecycle и правила именования, но CDP/noVNC и ADB/scrcpy — разные протоколы. Позже общую Docker-часть можно выделить в небольшой docker-git-runtime-core.
Формальные инварианты
Для проекта pp, Android-устройства dd и активной сессии ss:
∣Sessions(p)∣≤1∣Sessions(p)∣≤1McpSerial(p)=UiSerial(p)McpSerial(p)=UiSerial(p)ensure(ensure(p))=ensure(p)ensure(ensure(p))=ensure(p)PublicBind(5037)=PublicBind(5555)=∅PublicBind(5037)=PublicBind(5555)=∅Lease(d)=p⇒∄q≠p:Lease(d)=qLease(d)=p⇒∃q=p:Lease(d)=q
То есть MCP, screenshot, stream и пользовательское управление всегда работают с одним device_serial.
Backend 1: Docker-эмулятор
Как использовать docker-android
Не подключать upstream-образ напрямую через latest. Лучше сделать собственный фиксированный образ:
ghcr.io/provercoderai/android-emulator: api-34-google_apis-x86_64-<commit>
Из HQarroum/docker-android можно переиспользовать:
установку SDK и system image;
создание AVD;
запуск emulator;
/data для состояния AVD;
KVM;
boot monitoring.
Но необходимо изменить следующее:
Удалить privileged: true.
Передавать только --device /dev/kvm.
Не публиковать ADB-порты на хост.
Всегда использовать SKIP_AUTH=false.
Создавать отдельные ADB-ключи для проекта.
Исправить GPU-режим.
Добавить нормальный healthcheck.
Закрепить версии command-line tools, emulator и system image.
Добавить Docker labels проекта и backend’а.
Ограничить CPU, RAM и размер /data.
Linux-ускорение Android Emulator опирается на KVM и требует доступного /dev/kvm, поэтому первый поддерживаемый вариант должен быть Linux x86_64 с KVM. Сам upstream также активно поддерживает только x86/x86_64 Android images.
Для macOS, Windows и ARM-хостов лучше запускать эмулятор нативно на машине пользователя и подключать его через relay, а не пытаться протащить аппаратное ускорение через вложенную виртуализацию Docker Desktop.
Запуск sibling-контейнера
Rust lifecycle создаёт контейнер:
<project-container>-android
с параметрами примерно такого уровня:
docker run -d \ --name "$ANDROID_CONTAINER" \ --label docker-git.android=1 \ --label docker-git.project-container="$PROJECT_CONTAINER" \ --network "container:$PROJECT_CONTAINER" \ --device /dev/kvm \ --cpus "$CPU_LIMIT" \ --memory "$RAM_LIMIT" \ --shm-size 2g \ -v "$ANDROID_VOLUME:/data" \ "$PINNED_ANDROID_IMAGE"
При network=container:<project> Android-контейнер разделяет network namespace проекта. Поэтому не нужны публичные 5555, 5037 или случайно выделяемые host ports.
Readiness считается достигнутым только при выполнении всех условий:
container.running∧ adb.get_state == "device"∧ getprop(sys.boot_completed) == "1"∧ package_manager_responds
Состояния:
Missing → Starting → Booting → Ready → Stopping → Missing ├── Unauthorized └── Failed
Backend 2: локальное физическое устройство
Когда устройство подключено USB к тому же Linux-хосту, не стоит передавать весь /dev/bus/usb в агентский контейнер.
Безопаснее:
Android phone │ USB ▼host-side android relay / ADB owner │ authenticated local RPC ▼android-connection
Пользователь один раз подтверждает RSA-ключ на Android, а проект получает временную lease-сессию. Android требует пользовательского подтверждения ADB-ключа для USB debugging; это нельзя обходить скрытно.
Можно добавить режим host-adb, где Rust-модуль соединяется с заранее настроенным host ADB server, однако этот режим должен считаться доверенным локальным deployment’ом.
Backend 3: удалённое устройство пользователя
Для реального сценария «пользователь подключает свой телефон, а удалённый агент получает доступ» нужен небольшой companion:
docker-git-device-relay
Он запускается на машине пользователя и:
владеет USB/ADB-ключами локально;
сам обнаруживает устройства;
устанавливает исходящее mTLS/WebSocket-соединение;
не открывает входящие порты;
передаёт только типизированные операции;
отправляет screenshot или video stream;
позволяет немедленно отозвать доступ;
отображает, какой проект сейчас управляет устройством.
Схема:
Phone ─USB─ Local relay ═══ outbound secure channel ═══ docker-git API │ └── agent MCP
ADB wireless pairing в Android 11+ полезен для локальной сети, но официальный сценарий предполагает pairing и нахождение машины и устройства в одной сети. Поэтому он не заменяет relay для облачного docker-git.
Дополнительный экспериментальный вариант — browser relay через WebUSB на базе Tango/ya-webadb. Он даёт установку без отдельного desktop-приложения, но зависит от открытой вкладки, browser permissions и стабильности клиентского соединения, поэтому его лучше считать вторичным UX-режимом.
Экран и управление
Практичный MVP
Для первой версии полноценный видеопоток не требуется:
screenshot: adb exec-out screencap -p;
UI hierarchy: uiautomator dump;
tap: input tap;
swipe: input swipe;
text: input text;
key: input keyevent;
app launch: am start;
URL: am start -a android.intent.action.VIEW.
Web-панель может запрашивать PNG после каждого действия и дополнительно обновлять его с небольшой частотой. Для агента это уже полноценный интерфейс управления и намного проще поточного видео.
Узлы UI нужно возвращать с ревизией:
{ "revision": 42, "nodes": [ { "ref": "n17", "resourceId": "com.example:id/login", "text": "Войти", "bounds": [60, 820, 1020, 940] } ]}
Команда:
{ "ref": "n17", "revision": 42}
отклоняется, если ссылка устарела. Это защищает от нажатия не на тот элемент после смены экрана.
Для WebView, canvas, некоторых Compose-интерфейсов и secure windows accessibility tree может быть неполным. В этих случаях остаётся координатное управление по screenshot. Позже можно добавить адаптер UiAutomator2, не меняя MCP API.
Поток scrcpy
Следующим слоем следует добавить scrcpy gateway:
ADB serial └── pinned scrcpy server ├── video stream → authenticated WebSocket → panel └── control packets ← panel / agent
Scrcpy подходит и для эмулятора, и для физического устройства, работает через USB или TCP/IP, не требует root и не устанавливает постоянное приложение на устройство.
Таким образом сохраняется главный инвариант:
MCP serial = screenshot serial = scrcpy serial
ws-scrcpy можно изучать как протокольный прототип, но не брать в production без существенной переработки: сам проект предупреждает об отсутствии встроенной аутентификации и шифрования, а его scrcpy-часть расходится с актуальным upstream.
budtmo/docker-android можно использовать для быстрого emulator-only proof of concept с VNC, но это не решает единообразно физические устройства.
MCP-интерфейс
Минимальный набор:
android_status()android_snapshot()android_screenshot()android_tap(ref?, revision?, x?, y?)android_swipe(x1, y1, x2, y2, duration_ms?)android_type_text(text)android_press_key(key)android_launch_app(package, activity?)android_open_url(url)android_install_apk(workspace_path)android_logcat(package?, tail?)
android_screenshot лучше возвращать настоящим MCP image content с MIME image/png, а не data URL внутри текста: MCP поддерживает изображения как отдельный тип результата tool call.
Не следует включать по умолчанию:
android_shell(command)android_pull_file(arbitrary_path)android_reboot_bootloader()android_factory_reset()
Raw shell можно разрешать только отдельным capability:
ANDROID_ALLOW_RAW_SHELL=1
и обязательно журналировать.
Для физического личного телефона установка APK, удаление приложений, очистка данных и изменение системных настроек должны требовать дополнительного пользовательского подтверждения.
Конкретные изменения в docker-git
СлойИзмененияDomainДобавить AndroidBackend = "none" | "emulator" | "host-adb" | "relay" и Android-параметры в packages/container/src/core/domain.tsDefaults/CLIДобавить --android=emulator, --android-api, --android-device, resource limitsDockerfileУстанавливать по закреплённому commit оба Rust-бинарника в templates/dockerfile-prelude.tsComposeПередавать Android env, Docker host и limits в templates/docker-compose.tsAgent configsРегистрировать android-connection в Codex/Claude/Gemini/Grok entrypoint templatesLifecycleВ tasks.ts оставить только cleanup; запуск выполнять лениво через API или первый MCP callAPIДобавить project-android.ts, project-android-core.ts, contracts, schema и routesFrontendДобавить panel-android.tsx, screenshot canvas, actions и session statusTestsProperty tests, fake ADB backend, Linux/KVM integration smoke tests
Пример domain:
export type AndroidBackend = | "none" | "emulator" | "host-adb" | "relay"export interface TemplateConfig { // ... readonly androidBackend: AndroidBackend readonly androidApiLevel?: number readonly androidImageType?: "google_apis" | "google_apis_playstore" readonly androidDeviceProfile?: string readonly androidSerial?: string readonly androidCpuLimit?: string readonly androidRamLimit?: string readonly androidPersistData?: boolean}
Compose env:
MCP_ANDROID_ENABLE: "1"DOCKER_GIT_ANDROID_BACKEND: "emulator"DOCKER_GIT_ANDROID_CONTAINER_NAME: "${PROJECT_CONTAINER}-android"DOCKER_GIT_ANDROID_VOLUME_NAME: "${PROJECT_VOLUME}-android"DOCKER_GIT_ANDROID_API_LEVEL: "34"DOCKER_GIT_ANDROID_CPU_LIMIT: "4"DOCKER_GIT_ANDROID_RAM_LIMIT: "6g"
MCP config:
[mcp_servers.android]command = "android-connection"args = [ "--project", "dg-example", "--backend", "emulator"]
Текущий browser-модуль уже устанавливается в Dockerfile двумя бинарниками, а entrypoint оставляет ему владение ленивым start/reuse. Android должен повторить именно это правило, чтобы API, MCP и entrypoint не конкурировали за lifecycle.
API-контракт целесообразно сделать таким:
type ProjectAndroidSession = { projectId: string projectKey: string backend: AndroidBackend status: "missing" | "starting" | "booting" | "ready" | "offline" | "failed" containerName: string | null serial: string | null model: string | null apiLevel: number | null streamStatus: "disabled" | "starting" | "ready" | "failed" controlOwner: "agent" | "user" | "shared" leaseExpiresAt: string | null}
Маршруты:
GET /projects/:id/androidPOST /projects/:id/android/startDELETE /projects/:id/androidPOST /projects/:id/android/actionGET /a/:projectKey/screenshotWS /a/:projectKey/stream
Существующие ProjectBrowserSession, browser proxy paths и project-browser.ts можно использовать как непосредственный шаблон.
Последовательность реализации
M0 — технический spike
Запустить закреплённый Android-образ как sibling, дождаться boot completion, получить screenshot и выполнить tap.
M1 — Rust lifecycle
Реализовать deterministic spec, Docker backend, labels, limits, readiness, idempotent start/status/stop и cleanup.
M2 — MCP
Добавить snapshot, screenshot, input, app lifecycle, logcat и workspace-scoped APK install.
M3 — интеграция в docker-git
Domain, CLI, Dockerfile, compose env, agent configs, API и screenshot-панель.
M4 — scrcpy stream
Добавить один закреплённый протокол scrcpy, WebSocket gateway и браузерный decoder.
M5 — физическое устройство
Сначала host-adb, затем пользовательский relay с lease, consent, revoke и audit log.
M6 — hardening
Ограничение команд, session epochs, защита WebSocket, cleanup orphan-контейнеров, quotas и интеграционные тесты.
Критерии готовности
Повторный start возвращает тот же контейнер и ту же сессию.
MCP и панель показывают один device_serial.
На 0.0.0.0 не слушаются ADB-порты.
При отсутствии KVM возвращается диагностическая ошибка без полусозданных ресурсов.
Отключение relay немедленно блокирует новые команды.
APK устанавливается только из workspace.
Все действия имеют project, session_epoch, actor, timestamp и результат в audit log.
Пользовательское действие может приостановить агента или перевести управление в ручной режим.
Рекомендованный MVP: Linux/KVM, собственный закреплённый fork docker-android, Rust lifecycle, MCP через ADB, screenshot-панель и режим host-adb. Архитектуру relay следует заложить сразу, но поток scrcpy и удалённое пользовательское устройство можно добавлять без изменения базового MCP-контракта.
можно сделать инструмент rust-android-connection? Можешь показать как его сделать?
Соберу минимальный рабочий каркас rust-android-connection по модели rust-browser-connection: lifecycle CLI, MCP stdio, ADB и Docker-emulator backend, тесты и README.
Ключевое решение: ADB остаётся внешним доверенным процессом, а Rust управляет serial и политиками; для Docker-эмулятора команды пойдут через docker exec без публикации 5037/5555.
В MVP фиксирую два бинарника: lifecycle docker-git-android-connection для start/status/stop и MCP android-connection; команды будут типизированными, с явным adb -s <serial>.
Каркас уже собран: 18 файлов, 11 MCP-инструментов, project-scoped lifecycle, headless Android image и CI. Дополнительно усилены KVM-граница, workspace confinement APK и защита от shell-инъекций.
Ищем доступные инструменты
Думал на протяжении 48m 51s
Да. Я собрал полный starter-репозиторий:
Скачать rust-android-connection — ZIPСкачать TAR.GZ
Внутри два бинарника:
android-connection└── MCP stdio-сервер для управления выбранным Android-устройствомdocker-git-android-connection└── start/status/stop lifecycle для project-scoped эмулятора
Реализованы MCP-инструменты:
android_devicesandroid_statusandroid_snapshotandroid_screenshotandroid_tapandroid_swipeandroid_type_textandroid_press_keyandroid_launch_appandroid_open_urlandroid_logcatandroid_install_apk
Основные инварианты:
каждая операция выполняется через явный adb -s <serial>;
произвольного android_shell нет;
установка APK по умолчанию выключена;
APK можно установить только из заданного workspace;
Docker lifecycle не публикует 5037 или 5555;
URL и текст проходят проверку перед пересечением Android shell boundary;
screenshot возвращается как MCP image/png.
Явный выбор устройства через adb -s и получение PNG через adb exec-out screencap -p соответствуют официальному интерфейсу ADB. Формат screenshot-результата использует MCP image content с data и mimeType.
Быстрый запуск
unzip rust-android-connection-starter-20260623.zipcd rust-android-connection-starter-20260623cargo generate-lockfilecargo fmt --checkcargo testcargo build --release --bins
Подключение физического телефона:
adb devices -ltarget/release/android-connection \ --serial YOUR_DEVICE_SERIAL \ --workspace "$PWD"
MCP-конфигурация:
{ "mcpServers": { "android": { "command": "/absolute/path/android-connection", "args": [ "--serial", "YOUR_DEVICE_SERIAL", "--workspace", "/workspace" ] } }}
Для разрешения установки APK:
--allow-install
или:
export ANDROID_ALLOW_INSTALL=1
Docker-эмулятор
Собственный контролируемый образ:
docker build \ -f assets/Dockerfile.android \ --build-arg API_LEVEL=34 \ --build-arg IMAGE_TYPE=google_apis \ -t docker-git-android:api-34 \ assets
Lifecycle:
docker-git-android-connection start \ --project dg-my-project \ --network container:dg-my-project \ --image docker-git-android:api-34
Создаваемые ресурсы:
container: dg-my-project-androidvolume: dg-my-project-android-dataserial: 127.0.0.1:5555
Образ запускает Android Emulator с -no-window и -no-snapshot, то есть в headless-режиме без GUI.
Компиляцию Rust и реальный boot smoke-test в текущем окружении выполнить не удалось: здесь отсутствуют Rust, Docker и доступ для загрузки пакетов. TOML/JSON разобраны, shell-скрипты прошли bash -n, Python probe скомпилирован, а статические security-инварианты проверены. Точный статус и команды финальной проверки находятся в VALIDATION.md.
Activity
konard commentedon Jun 22, 2026
🚨 Solution Draft Failed
The automated solution draft encountered an error:
What you can do
--allow-fork-divergence-resolution-using-force-push-with-leaseto allow a guarded force-with-lease sync.Administrator-only CLI details, if any, are printed in the solver terminal log rather than in this GitHub comment.
🤖 Models used:
opus(claude-opus-4-8)claude-opus-4-8)Click to expand failure log (41KB)
Now working session is ended, feel free to review and add any feedback on the solution draft.
skulidropek commentedon Jun 23, 2026
доп контекст:
rust-android-connection-starter-20260623.zip
feat(container): render Android MCP (mobile-mcp) integration