{"id":47967,"plugin_id":"plugins_6ac02c0d8d5c8191954e28f89c26a21d","kind":"skill","collection_source":"skill_api","comparison_source":null,"observed_at":"2026-10-24T13:35:07.404Z","digest":"be8b9f7c5953bfb9e062e40b21ed62518cc7ba96510e5453b9c1cfeb35381bf7","against":null,"payload":{"description":"Use for MiniDroid, the bundled minidroid-x86_64 runtime, MiniDroidManager.apk, ART/Bionic/linker64 bootstrapping, APK lifecycle, Android resources/views, MiniDroid bridges, package/process/storage management, ADB integration, add-ons, Android compatibility packs, runtime testing, debugging, patching and release work.","included_files":[{"relative_path":"references/OFFICIAL_PROJECT.md","size_in_bytes":701},{"relative_path":"references/PROJECT_STATE.md","size_in_bytes":1795}],"name":"minidroid","skill_md_contents":"---\nname: minidroid\ndescription: Use for MiniDroid, the bundled minidroid-x86_64 runtime, MiniDroidManager.apk, ART/Bionic/linker64 bootstrapping, APK lifecycle, Android resources/views, MiniDroid bridges, package/process/storage management, ADB integration, add-ons, Android compatibility packs, runtime testing, debugging, patching and release work.\n---\n\n# MiniDroid\n\nMiniDroid is a portable Android compatibility runtime for Linux x86_64. It is not a full Android OS, emulator, VM, WSA clone, or containerized system image.\n\n## Prime directive\n\nPreserve the architectural goal:\n\n**As much Android compatibility as possible, as little Android system as necessary.**\n\nThe working runtime path is conceptually:\n\n`Linux -> Android linker64 -> Bionic -> ART -> Java core/framework -> DEX/APK -> MiniDroid host bridges`\n\nDo not replace this with a full Android boot, system_server stack, Android VM, or emulator merely because that would be easier.\n\n## Bundled runtime\n\nThe plugin includes the user-supplied runtime archive at:\n\n`assets/minidroid-x86_64.zip`\n\nTreat that archive as the project snapshot to inspect, test, patch or extract when the task needs concrete files. Do not invent files or APIs that are not present.\n\nBefore making implementation claims, inspect the current runtime and tests. Prefer evidence from the bundled files and actual executions over assumptions.\n\n## Existing snapshot structure\n\nThe bundled archive contains, among other things:\n\n- `bin/minidroid`\n- `bin/minidroid-bridge`\n- `bin/adb`\n- `manager/MiniDroidManager.apk`\n- `framework/framework.jar`\n- `framework/framework-res.apk`\n- `framework/minidroid-framework-patch.jar`\n- `host/minidroid-window-x11`\n- Android ART/Bionic/APEX runtime files under `rootfs/`\n- tests under `TESTS/`\n- `MANIFEST.sha256`\n- license and third-party notice material\n\nRead `references/PROJECT_STATE.md` for the intended engineering baseline and open work.\n\n## Engineering rules\n\n1. Inspect first. Do not patch blindly.\n2. Preserve all working ART/Bionic/linker behavior.\n3. Create a checkpoint before risky changes.\n4. After each substantial change, rerun relevant regression tests.\n5. Never report a UI button or backend as functional unless the actual operation succeeds.\n6. Do not hide missing behavior behind unconditional PASS messages or fake return values.\n7. Use explicit, diagnosable error codes for unimplemented or failed operations.\n8. Keep the runtime relocatable; do not introduce absolute build paths.\n9. No root, chroot, host `/apex` mount, Android SDK/JDK, Python or build tree may be required at runtime unless the user explicitly changes that requirement.\n10. Respect the core compressed-size target of <=100 MiB; prefer leaving reserve rather than filling it.\n11. Keep runtime data, app data, add-ons and imported images separate.\n12. Preserve and update license/provenance metadata when adding binaries or libraries.\n\n## APK runtime\n\nAn APK is not a JAR. Treat APK execution as:\n\n`APK -> AndroidManifest.xml -> package/application/activity -> resources/assets/native libs -> framework -> MiniDroid host backend`\n\nWhen debugging APK startup, separate these failure domains:\n\n- manifest / binary AXML\n- DEX / multidex\n- Application bootstrap\n- Looper/lifecycle\n- Activity attach/state\n- resources.arsc\n- binary XML layout\n- Views/widgets\n- host window backend\n- input\n- JNI/native libraries\n- missing framework APIs/services\n\nDo not introduce Binder/system_server simply to satisfy one incidental framework initialization if a small compatible local façade is sufficient and semantically safe.\n\n## GUI architecture\n\nThe product manager remains an Android app:\n\n`MiniDroidManager.apk -> Application -> MainActivity -> Android Views -> MiniDroid graphics bridge -> Linux window`\n\nDo not replace the product manager with Qt, GTK, Tk or another native GUI. Host-native helpers are acceptable as backend implementation details.\n\nWayland is preferred where practical; X11 is an acceptable fallback. The bundled snapshot includes an X11 host window helper.\n\n## Manager bridge\n\n`MiniDroidSystem` / `minidroid-bridge` is the privileged path for manager operations.\n\nPrivileged operations include:\n\n- package management\n- process management\n- storage/data/cache\n- backup/restore\n- logs/crash information\n- runtime health/doctor\n- compatibility scans\n- display profile\n- shared folders\n- ADB control\n- add-on management\n- system-image/compatibility-pack management\n\nDo not rely on package name alone for privilege. Normal APKs must not receive manager privileges.\n\n## Package/process behavior\n\nPackage operations should be transactional where practical.\n\nInstall should validate the APK, parse package/version/ABI, register DEX, extract compatible native libraries, create app data and update package state.\n\nUpdate should preserve app data unless explicitly requested otherwise.\n\nUninstall should distinguish removing the app from removing app+data.\n\nA launch operation must only be reported successful when the runtime actually started the app. Do not treat a headless bootstrap that immediately exits as a running GUI application.\n\n## Data isolation\n\nKeep per-app data outside the immutable core, for example under a user data root with separate package directories for files/cache/code/native state.\n\nApps must not automatically receive unrestricted access to the Linux home directory. Shared folders are explicit user grants.\n\n## ADB\n\nBundling `adb` alone is not sufficient for MiniDroid to be an ADB target.\n\nA complete MiniDroid ADB path requires the device side as well: transport, authentication, shell bridge, package bridge and logging bridge (and adbd or a compatible implementation).\n\nTarget behavior includes:\n\n- `adb devices` sees MiniDroid\n- `adb shell`\n- `adb install`\n- `adb uninstall`\n- `adb logcat`\n\nPrefer local transport first. Do not expose TCP 5555 by default. Network ADB must require explicit opt-in.\n\n## Add-ons and Android images\n\nThe core runtime is immutable from the add-on system's point of view. Add-ons live separately, are verifiable, enable/disable cleanly, uninstall cleanly, and roll back on failure.\n\nA full Android image is only a **component source / compatibility pack input**. It must not replace the MiniDroid architecture or cause MiniDroid to boot a complete Android system.\n\nImage workflow:\n\n`inspect/import -> verify hashes -> identify format/partitions/APEX/framework/native libraries -> determine useful dependency closure -> build separate add-on -> test -> activate`\n\nDo not blindly copy a system image over the core runtime.\n\n## Google components\n\nThe MiniDroid core remains Google-free. Proprietary Google components must not be redistributed as part of the core. Any optional installation must be explicit, removable, license/source aware and use a lawful source.\n\n## Testing discipline\n\nUse targeted gates while developing, then run the wider release suite.\n\nCore gates should include linker/Bionic/ART/Java/DEX, relocation, JNI/System.loadLibrary, APK manifest/multidex/native ABI, Application/Activity, resources/XML/View rendering, manager boot, package install/launch/stop/uninstall, data isolation, add-ons and any ADB/GLES/audio feature that is claimed supported.\n\nA crash or unsupported API should produce an actionable diagnostic instead of silently succeeding.\n\n## Release discipline\n\nBefore calling a build finished:\n\n- build from the verified runtime tree\n- verify `MANIFEST.sha256`\n- verify manager APK integrity/signature where applicable\n- run `minidroid doctor`\n- run relocation smoke tests\n- test the manager as an Android app\n- test real package operations\n- update implemented/test/size/license/limitations reports\n- ensure the compressed core stays within the configured size budget\n\n## Working style for user requests\n\nWhen the user provides a newer MiniDroid ZIP, source tree or log, treat it as authoritative over this bundled snapshot.\n\nWhen asked to \"fix everything\", do not respond only with a plan. Inspect the project, make the highest-value concrete fixes possible, run tests, report exact remaining blockers, and produce a new archive when file-editing tools are available.\n\nWhen the user asks for commands, prefer complete copy-pasteable commands and avoid requiring them to program manually.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}