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
Slim mode is iOS-only. An Android emulator runs with full guest RAM and every background package the system image ships, so it costs more memory and CPU than an agent workload needs. Capacity is derived from the machine's RAM and CPU, so heavy emulators mean fewer devices per machine.
Who runs into this
Anyone running several Android emulators at once on one Mac or CI host: parallel coding agents, and operators sizing a worker.
What you would like to happen
An opt-in Android slim mode, set by the operator in config the same way ios.slim.* is:
The emulator boots in a low-memory profile with a configurable guest RAM size.
A known list of background packages the workload does not need is disabled.
The lease reports featureProfile: "reduced", and --full opts a lease out, as on iOS.
It applies only to devices Simlock created.
Anything else
#148 already covers headless, GPU, audio, and boot animation. This request is the part it leaves out: guest RAM and background packages.
Closed as not planned: the approach changed. Android slim will be a guest RAM cap only, with the size set by the operator. Disabling background packages is dropped. Low-RAM mode becomes something a lease request asks for, kept apart from slim. A new issue will cover slim Android emulators and link back here.
Correction to the comment above: no new slim issue will follow. Measurements on an M3 Pro with emulator 36.5.11 showed that a guest RAM cap cannot make an Android emulator lighter on current images:
On API 35 and 36 the emulator raises any guest RAM below 2048 MB to 2048 MB (Increasing RAM size to 2048MB). API 24 honours 1024 MB.
Every SDK profile avdmanager creates (Pixel 6, 8, 9, 9 Pro XL, Tablet, Fold, Medium Phone, Automotive) already has 2 GB or less.
A stock emulator costs the host about 2.0 to 2.6 GB: the guest fills its RAM within seconds of boot, plus 0.5 to 0.65 GB for the emulator itself, with nothing shared between emulators.
So a slim Android device would be the same as a full one. The bigger density gain is in the Android capacity defaults (4 GiB per emulator, and a count limit of min(cpu/4, ram/8 GiB)), which will be raised separately. Slim can be reconsidered if the device profile library (#483) gives full devices more than 2 GB.
Activity
V3RON commentedon Sep 28, 2026
Being specified in #159. This issue stays open until that feature ships.
Written by an agent.
Generated by Claude Code
V3RON commentedon Oct 12, 2026
Closed as not planned: the approach changed. Android slim will be a guest RAM cap only, with the size set by the operator. Disabling background packages is dropped. Low-RAM mode becomes something a lease request asks for, kept apart from slim. A new issue will cover slim Android emulators and link back here.
Written by an agent.
V3RON commentedon Oct 12, 2026
Correction to the comment above: no new slim issue will follow. Measurements on an M3 Pro with emulator 36.5.11 showed that a guest RAM cap cannot make an Android emulator lighter on current images:
Increasing RAM size to 2048MB). API 24 honours 1024 MB.avdmanagercreates (Pixel 6, 8, 9, 9 Pro XL, Tablet, Fold, Medium Phone, Automotive) already has 2 GB or less.So a slim Android device would be the same as a full one. The bigger density gain is in the Android capacity defaults (4 GiB per emulator, and a count limit of
min(cpu/4, ram/8 GiB)), which will be raised separately. Slim can be reconsidered if the device profile library (#483) gives full devices more than 2 GB.Written by an agent.