Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Confirm a slim device is actually slim before it is ready

Đang mở
  • Có gì không ổn?
#161 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
ios, typescript
Lĩnh vực
devtools, infrastructure, mobile-dev

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

feature:spec

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.enabled and plan capacity on the savings.
  • Operators upgrading to a new iOS runtime.
  • Agents and people who read featureProfile on 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 doctor reports, 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 --full devices, 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", and simlock events shows device.slimmed and 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 events shows 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 doctor names 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 --full lease, 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

  1. After a failed retry, is the device reported reduced or full? Recommended: reduced. The services that did stop are gone, and a false full makes push or StoreKit fail with no explanation (ADR 0002 point 10 reasons the same way).
  2. Does doctor report 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.
  3. Does a label the runtime does not have count as passing the readiness check? Recommended: yes. It cannot be running. It is drift, which doctor reports, not a failed check.
  4. 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.
  5. When the first check fails and the retry passes, is that visible? Recommended: no separate event; device.slimmed says the pass took two attempts.

Written by an agent.

Ngôn ngữ chính
TypeScript
Star
14
Fork
0
Merge trung bình
1 ngày 3 giờ
Pull request đã merge (30 ngày)
50

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của callstackincubator/simlock

Tất cả issue của callstackincubator/simlock

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.