Confirm a slim device is actually slim before it is ready
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- ios, typescript
- Ambito
- devtools, infrastructure, mobile-dev
Direzione di ricerca
No files, tests, or entry points are named in the issue. First trace the device readiness and simlock doctor paths, then resolve the open questions before implementation; done means the listed completion conditions hold for slim, full, crash-recovery, and older-runtime cases without Android-specific core changes.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Request: #152
Problem
A slim device reports featureProfile: "reduced" as soon as the disable commands ran and the device rebooted. Nothing looks at the running device afterwards.
launchctl disable accepts a label the runtime does not have, so a daemon Apple renamed or removed is "disabled" with no effect. A slim device can be heavier than reported, and nobody is told. Operators who size capacity on slim devices lose memory they think they have. Anyone upgrading to a new iOS runtime cannot tell whether slim mode still works there.
Two facts are missing today:
- After the slim reboot: is every service Simlock meant to disable in fact not running?
- For an installed runtime: which labels in Simlock's disable list does that runtime not have?
Who it is for
- Operators who turn on
ios.slim.enabledand plan capacity on the savings. - Operators upgrading to a new iOS runtime.
- Agents and people who read
featureProfileon a lease.
Outcome
- Before a slim device is reported ready, Simlock checks the running device against the set it meant to disable. Every lease path goes through readiness, so no lease is granted on an unchecked slim device.
- A device that passes is reported
reduced, as today. The check adds no boot. - A device that fails is slimmed and rebooted once more. If it still fails, the device is still ready and the lease is still granted. One event names the device and the services still running.
simlock doctorreports, per installed iOS runtime, the labels in the disable list that the runtime does not have. It boots nothing to find out.- The check, the event, and the doctor finding have one platform-neutral shape: platform, device, what was expected off, what was found on. A future Android slim mode (#151) reuses them without a core change.
Non-goals
- Failing a boot or a lease because the check failed. A failed or skipped slim never fails the lease.
- Re-enabling services, updating the label list, or otherwise fixing drift.
- Checking
--fulldevices, crash-recovery reboots, or runtimes below iOS 18.5. Nothing was applied on them. - Checking a device again after it is ready, or while it is leased.
- Measuring memory or process counts. The check is per service, not per byte.
- Android slim mode itself (#151).
Completion conditions
- With slim on, a device whose whole disable set is off after the slim reboot is granted with
featureProfile: "reduced", andsimlock eventsshowsdevice.slimmedand no failure event for that boot. - When a service in the disable set is still running after the slim reboot, Simlock applies the set and reboots once more before the device is ready.
- When a service is still running after that retry, the lease is granted, and
simlock eventsshows exactly one event for that boot naming the device and every service still running. - A check that passes on the first try adds no boot to the lease.
- With slim on,
simlock doctornames each installed iOS runtime that lacks a label from the disable list, and the missing labels, without booting a device. With slim off it reports nothing. - A
--fulllease, a crash-recovery reboot, and a boot on a runtime below iOS 18.5 produce no check, no retry, and no event. - The event payload and the doctor finding carry the same fields for every platform, and nothing outside the iOS driver names launchd.
Open questions
- After a failed retry, is the device reported
reducedorfull? Recommended:reduced. The services that did stop are gone, and a falsefullmakes push or StoreKit fail with no explanation (ADR 0002 point 10 reasons the same way). - Does
doctorreport drift for a runtime no device has booted on yet? Recommended: yes. Drift is a property of the installed runtime and should be visible before the first lease. - Does a label the runtime does not have count as passing the readiness check? Recommended: yes. It cannot be running. It is drift, which
doctorreports, not a failed check. - After a failed retry, does the next plain reboot of that device (idle shutdown, then boot, no erase) run the whole pass again, or trust the idempotence marker? Recommended: trust the marker. The event is the record, and a device that cannot converge would otherwise cost three boots on every boot.
- When the first check fails and the retry passes, is that visible? Recommended: no separate event;
device.slimmedsays the pass took two attempts.
Written by an agent.
- Lingua principale
- TypeScript
- Stelle
- 14
- Fork
- 0
- Merge medio
- 1g 3h
- PR unite (30g)
- 49
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di callstackincubator/simlock
-
bug:ready
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
callstackincubator/simlock#79 · 6 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
task:draft
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
callstackincubator/simlock#164 ·
I maintainer di solito rispondono entro 1 giorno
-
task:draft
Difficoltà 5/5 Più di una settimana Idoneità per principianti 38/100
callstackincubator/simlock#163 ·
I maintainer di solito rispondono entro 1 giorno
-
feature:spec
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
callstackincubator/simlock#162 ·
I maintainer di solito rispondono entro 1 giorno
-
feature:spec
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
callstackincubator/simlock#160 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di callstackincubator/simlock
Issue simili
-
needs:triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
ai-discovered
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
jessepollak/home#1627 ·
I maintainer di solito rispondono entro 1 giorno
-
agent-canvas bug llm priority:low ready-for-dev
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
OpenHands/OpenHands#17806 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
radius-project/ai-extensions#923 ·
I maintainer di solito rispondono entro 1 giorno