Your systems capstone

This core capstone assesses a bounded skill: tracing one Android 14 framework-to-HAL request and reasoning from a supplied evidence packet. The packet is synthetic. Source-only completion is valid; no device, build, patch, or hardware is required. Passing this capstone demonstrates an introductory, bounded investigation—not Android expertise or device certification.

Before you start#

Required earlier lessons: Android’s security model, Binder: app to system service, HAL, Treble, and the vendor boundary, Following One Framework Service: Vibration, and Compatibility Testing: CTS, VTS, and What a Result Means. If you cannot distinguish source evidence from runtime evidence, review Debug, test & contribute.

Learning goals#

You will produce a traceable layer diagram, separate observed/supplied facts from inference and unknowns, rank at least two plausible hypotheses, and recommend the next safe test without pretending that synthetic evidence was executed. A real engineering claim requires additional build/test evidence as described below.

Practice#

Core evidence packet — synthetic

Every line below is a fictional teaching datum. It does not represent an AOSP test, emulator run, vendor device, or actual Android log.

PACKET ID: SYNTH-VIB-01
Source baseline requested for analysis: AOSP android-14.0.0_r1
Scenario: an app reports that vibration did not occur

1. Source-map note: Android 14 VibratorManagerService.vibrate(...)
   delegates to vibrateInternal(...).
2. Source-map note: the service enforces VIBRATE permission, checks a
   request token and input validity, then performs policy/arbitration.
3. Source-map note: the framework vibrator HAL contract is stable AIDL;
   a VINTF declaration describes an interface, not a healthy process.
4. Synthetic runtime summary: dumpsys vibrator_manager says “No active vibration”.
5. Synthetic log summary: one request was recorded as ignored by user
   settings. No AVC denial was present in the supplied excerpt.
6. Synthetic interface summary: expected HAL service is declared in a
   manifest excerpt; no registration or transaction trace is supplied.
7. Synthetic hardware summary: emulator target type; physical actuator
   capability is unknown.

The source-map notes are checked against Android 14 VibratorManagerService.java and the IVibrator.aidl contract, but they are not a substitute for checking the actual code. The VINTF documentation describes the device manifest as the "static component of what the device can provide to the framework," which is why a declaration is not evidence of a running, healthy service. The runtime summaries are stipulated facts for this exercise only. No source excerpt, log file, manifest, test result, or physical measurement is actually attached.

Required deliverable

Create one investigation packet with these sections:

1. Scope and provenance: state SYNTH-VIB-01, identify the Android 14 tag as requested baseline, and explicitly mark the runtime data synthetic/not executed.
2. Flow diagram: app/API → Binder/service → framework policy → HAL contract/client → vendor implementation → kernel/hardware. Label which edges are source-map, supplied synthetic evidence, or unknown.
3. Claim/evidence/limit table: at least four claims. For each, cite a method/source location or packet item, say what it supports, and what it does not support.
4. Hypotheses: rank at least two causes and name a falsifying check for each. Include an alternative to the strongest hypothesis.
5. Safe next-step plan: name one source check and one possible targeted test or virtual-target observation; state prerequisites, expected discriminating outcomes, and one test limitation. Do not run hardware commands.
6. Verdict: one short maintainer-style statement separating fact, inference, and unknown.

Model solution (small example)

Flow: app request → Binder VibratorManagerService → permission/token/input validation → user-setting arbitration → framework HAL client → declared stable AIDL interface → vendor process/driver/actuator. The service-to-policy/source edges are supported by Android 14 source. The “ignored by settings” statement is a synthetic supplied datum. Registration, successful HAL transaction, driver operation, and physical vibration remain unknown.

Ranked hypotheses: (1) User settings/policy suppressed this request: strongest because the synthetic log explicitly says so; falsify by checking the request’s policy inputs and a controlled permitted request in a supported disposable test. (2) The policy message is incomplete or not causally tied to the observed request, and a later HAL/implementation failure occurred: check a correlated request ID/timestamp and interface transaction/result evidence. Another possibility is emulator capability/behavior rather than a production hardware fault. The packet cannot choose among real runtime causes because it is synthetic and lacks correlated logs.

Verdict: “In this synthetic packet, the strongest explanation is framework policy suppression, consistent with the supplied settings summary. The source path supports that such arbitration exists. There is no executed runtime evidence for HAL registration, a vendor call, driver behavior, or physical vibration, so no hardware root cause is established.” This is a model of bounded reasoning, not the only acceptable wording.

Optional engineering extensions

• Build extension: build/boot the course’s pinned AOSP Android 14 target in an appropriate Linux/Cuttlefish environment; record manifest/revision, target, build result, and boot evidence. A successful build is not a successful test.
• Patch extension: make a harmless change in an owned AOSP checkout, identify an existing focused test from its module configuration, run that test, and report exact command/result. Do not alter permissions, SELinux policy, verified boot, credentials, partitions, or a personal device for this capstone.
• Compatibility extension: use the CTS/VTS lesson to justify a relevant test module and interpret its actual result. Do not call an unrun test a pass.

These extensions are not required for the core source-only checkpoint. A learner claiming engineering implementation competence must provide actual build/test artifacts, not just the model solution. Advanced claims require still more, as the next-step gates below specify.

Knowledge check#

1. Does a manifest declaration prove the HAL service is registered and healthy?
2. The synthetic dump reports no active vibration. Can you conclude that the kernel driver failed?
3. Why is a missing AVC line weak evidence against SELinux involvement?
4. What additional evidence would turn the model’s likely policy explanation into a runtime-supported conclusion?

Answers#

1. No. Declaration, registration, successful invocation, and hardware behavior are separate states.
2. No. The request may have been denied or suppressed earlier; the dump is a snapshot and the packet explicitly reports a settings ignore.
3. The excerpt can be incomplete, filtered, or from the wrong time/process; refusals can also happen above SELinux. Absence in a short excerpt is not proof of absence.
4. A real, revision-identified target; a correlated reproduction and service log/state; source path for the relevant policy decision; and a controlled repeat that changes the relevant setting while observing the outcome. Even then, record target limitations.

Checkpoint#

Score each criterion 0 (missing/incorrect), 1 (partly supported), or 2 (clear and evidence-bounded): (a) diagram marks layers and evidence types; (b) four claims cite packet/source and limits; (c) two ranked hypotheses have falsifying checks; (d) safe next-step plan separates source and possible runtime test; (e) verdict explicitly says synthetic/not executed and identifies unknown hardware layers. Ready for core requires at least 8/10 and no zero in (b) or (e). Below threshold: revise the zero/partial rows; do not compensate for fabricated runtime evidence with points elsewhere. Ready for core means source-only investigation competence on this bounded exercise, not Android expertise.

Remediation: confused API/service/HAL? Revisit Following One Framework Service and HAL/Treble. Confused declared versus registered or test result meaning? Revisit Compatibility Testing. Confused root/SELinux evidence? Revisit Android’s security model. If you have no real target, remain source-only and mark runtime claims not yet evidenced.

What further claims require

There is no universal number of lessons or one capstone that makes someone an Android expert. A credible engineering implementation claim needs a reviewable patch, reproducible build, relevant test execution, and target-specific result. A compatibility claim needs appropriate CTS/VTS coverage and configuration evidence, not one passing module. A kernel/native claim needs exact-build symbols/logs and a traced userspace/kernel boundary. A performance claim needs a repeatable workload, trace/metrics, baseline comparison, and uncertainty/measurement limits. A security-policy claim needs policy rationale, narrow rules, relevant policy tests, and review. An OTA/recovery claim needs state-machine evidence and virtual/supplied-data validation; this curriculum does not authorize generic flashing instructions. These are specialist evidence gates, not boxes checked by reading.

Independent engineering and advanced-practice gate

The small core packet above is deliberately introductory. Do not use its 8/10 threshold as the graduation standard for the full advanced path. To demonstrate what you can actually do after the complete course, build a separate portfolio. Every required row below needs its own evidence; strengths in one row cannot compensate for fabricated or missing evidence in another.

Ready for the stated engineering scope means every engineering row is supported by actual artifacts and the reviewer can reproduce the bounded result. Advanced practice evidenced additionally requires the unfamiliar failure and specialist work, with justified methods and explicit limits. Repeat this process on further changes, releases, or targets to test transfer. Neither label certifies expertise across all Android subsystems; sustained independently reviewed work is the path toward that expertise.

For a deeper source-only extension, choose one mechanism from the added chapters and apply it to a different interface or scenario: HAL startup and registration, version/capability evolution, root authority transitions, mount-view lifetime, DMA ownership, or graphics fence timing. Explain the original design problem, the exact enforcement/ownership point, a failure path, and one counterexample to your explanation. A renamed copy of the worked example is not independent transfer; an executed Python model is not an Android runtime test.

Sources#

• AOSP VibratorManagerService.java, Android 14.0.0_r1 — verified: vibrate delegates to vibrateInternal, which checks the VIBRATE permission, a non-null token, and effect validity before policy checks.
• Vibrator HAL AIDL, Android 14.0.0_r1 — verified: IVibrator is marked @VintfStability; this is the HAL contract, not evidence of a running service.
• VINTF documentation — verified: the device manifest describes the static component the device provides to the framework.
• AOSP SystemVibratorManager.java, Android 14.0.0_r1 — verified: client-side SystemVibratorManager gets IVibratorManagerService from the service manager; compare with the service and HAL boundaries rather than treating the packet's diagram as runtime evidence.
• Earlier lessons: Binder, HAL/Treble, security model, and CTS/VTS.