platform_system_core
repository·main·Indexed 22 days ago
https://github.com/aosp-mirror/platform_system_coreCore system components and tools from the AOSP mirror, including bootstat for recording and logging boot event metrics, cli-test for command-line tool integration testing, and fastboot utilities such as the fastboot_fuzzer and Fuzzy Fastboot for automated conformance and penetration testing of device-side fastboot protocol implementations.
What's inside platform_system_core
- Fuzzy Fastboot (FF) is a standalone automated conformance and penetration testing tool designed to validate device-side fastboot protocol implementations. It is used to identify implementation bugs, ensure conformance to the fastboot specification, and verify that the bootloader safely handles malicious or malformed inputs. The tool is generic and uses an extensible XML configuration file to generate device-specific tests.
Overview of Android's shell and utilities
mainAndroid's command-line environment has evolved from using a custom
toolboxbinary to primarily usingtoyboxfor most utilities. The shell itself has usedmkshsince IceCreamSandwich.Key components include:
- Shell:
mksh(since IceCreamSandwich). - Core Utilities:
toyboxprovides the majority of command-line tools. - Specialized Tools: Certain commands are provided by specific distributions rather than toybox, such as
bzip2tools,awk(one-true-awk), andbc(Gavin Howard's bc). - Legacy/Specific Tools: Some tools like
getevent,getprop,setprop,start, andstopare provided by thetoolboxbinary.
- Shell:
Overview of the Android Init Language
mainThe Android Init Language is a line-oriented configuration language used to define system behavior. It consists of five main classes of statements:
- Actions: Named sequences of commands triggered by specific events.
- Commands: Individual instructions executed within actions or services.
- Services: Programs launched and optionally restarted by the
initprocess. - Options: Modifiers applied to services to control their execution environment.
- Imports: Mechanisms to include other
.rcfiles.
Syntax Rules
- Tokens: Separated by whitespace.
- Escaping: Use C-style backslash (
\) to insert whitespace into a token or for line-folding (if\is the last character on a line). - Quoting: Use double quotes (
"") to prevent whitespace from breaking text into multiple tokens. - Comments: Lines starting with
#(leading whitespace allowed) are comments. - Property Expansion: System properties can be expanded using
${property.name}. This is useful for concatenation, e.g.,import /init.recovery.${ro.hardware}.rc. - Sections: Actions and Services implicitly declare new sections. All subsequent commands or options belong to the most recently declared section. Commands/options appearing before any section are ignored.
Overview of Android Live-LocK Daemon (llkd)
mainThe Android Live-LocK Daemon (
llkd) is a component designed to catch and mitigate kernel deadlocks. It provides a default standalone implementation, but developers can also integrate thellkdcode into other services as part of a main loop or as a separate thread using thelibllkdlibrary.llkduses two primary detection scenarios:- Persistent D or Z state: Monitors threads in uninterruptible sleep (D) or zombie (Z) states. If no progress is made within a specified timeout,
llkdkills the process. If the process persists, it triggers a kernel panic to provide a detailed bug report. - Persistent stack signature: (Available on
userdebugorengbuilds only). Monitors threads for specific kernel symbols in their stack (via/proc/pid/stack). If a listed symbol persists longer than the timeout,llkdkills the process and may trigger a kernel panic.
- Persistent D or Z state: Monitors threads in uninterruptible sleep (D) or zombie (Z) states. If no progress is made within a specified timeout,
Overview of libfiemap
mainlibfiemapis a library designed to create block devices backed by storage in read-write partitions. It is primarily used bygsidto manage Dynamic System Updates. The library works by usinglibfiemap_writerto allocate large files within a filesystem and then tracking their extents.Key use cases include:
- Creating images that act as block devices (e.g., creating a
system_gsiimage). - Mapping images as block devices while
/datais mounted. - Mapping images as block devices during first-stage init (using logic similar to dynamic partitions).
- Creating images that act as block devices (e.g., creating a
Fastboot Protocol Overview
mainThe fastboot protocol is a host-driven, synchronous mechanism for communicating with bootloaders over USB or Ethernet (TCP/UDP). It is designed to be straightforward to implement across various platforms including Linux, macOS, and Windows.
USB Requirements
- Requires two bulk endpoints (in and out).
- Max Packet Size depends on speed:
- Full-speed: 64 bytes
- High-speed: 512 bytes
- Super Speed: 1024 bytes
TCP/UDP Requirements
- The device acts as the server, and the fastboot client acts as the client.
- The device must be reachable via IP.
Map images as block devices on Metadata Encrypted Devices
mainOn devices using metadata encryption,
/datais mounted from an intermediatedm-default-keydevice rather than directly from/dev/block/by-name/data. Because the underlying device is not marked as in-use,libfiemapcan create newdm-lineardevices on top of it.In this scenario, the block device for an image consists of a single device-mapper device containing a
dm-lineartable entry for each extent in the backing file.How Actions work in the Init Language
mainActions are named sequences of commands triggered by an event. When a trigger matches, the action is added to a execution queue.
Syntax
on <trigger> [&& <trigger>]* <command> <command>Execution Flow
- Triggers are evaluated. If multiple triggers are joined by
&&, all must be true at the moment of the trigger event. - Actions are added to the queue based on the order the file was parsed, then sequentially within the file.
- Commands within an action are executed in sequence.
Important Behaviors
- Past Events: If a condition (like a property check) becomes true after the trigger event has already occurred, the action will not execute.
- Async Writes: If
ro.property_service.async_persist_writesistrue, there is no guaranteed ordering between persistent (persist.*) and non-persistentsetpropcommands within an action.
on boot setprop a 1 setprop b 2 on boot && property:true=true setprop c 1 setprop d 2- Triggers are evaluated. If multiple triggers are joined by
Understand Android Init triggers and conditions
mainTriggers define when an action (a set of commands) should execute. They consist of event triggers and property triggers.
Trigger Types
- Event Triggers: Based on boot stages (e.g.,
early-init,boot). Satisfied wheninitreaches that stage. - Property Triggers: Format
property:<name>=<value>. Satisfied when a property matches a value. Use*as a wildcard.
Combining Triggers
Multiple triggers can be combined using the
&&(AND) operator.Execution Logic and Nuances
- One-time check: All property triggers are checked once when the
bootevent finishes. - Property changes: After the one-time check,
property:a=bis checked wheneverais created or changed tob. - AND logic: For
property:a=b && property:c=d, the action triggers if:- Both are true during the one-time check.
abecomesbwhilecis alreadyd.cbecomesdwhileais alreadyb.
- Event + Property:
on property:a=b && post-fsonly executes ifpost-fsis triggered whileais alreadyb. It will NOT trigger ifabecomesbafterpost-fshas already occurred.
- Event Triggers: Based on boot stages (e.g.,
How Services work in the Init Language
mainServices are programs that
initlaunches and can optionally restart if they exit.Syntax
service <name> <pathname> [ <argument> ]* <option> <option> ...Key Constraints
- Uniqueness: Service names must be unique. If a second service is defined with an existing name, it is ignored and an error is logged.
- Options: Services are modified by various options (see Service Options Reference) which control capabilities, namespaces, and lifecycle behavior.
Track image mapping state and resource cleanup
mainTo prevent catastrophic data corruption (e.g., writing to a
dm-lineardevice whose underlying blocks are no longer owned by the original file),libfiemapimplements state tracking:- Property Tracking: When mapping an image, a property named
gsid.mapped_image.<name>is created and set to the path of the block device. - Dependency Tracking: A status file is created at
/metadata/gsi/<subdir>/<name>.status. Each line in this file denotes a dependency on either a device-mapper node or a loop device. - Cleanup: When deleting a block device, the system reads the
.statusfile to ensure all associated resources (loop devices or device-mapper nodes) are properly released.
- Property Tracking: When mapping an image, a property named
UDP Protocol v1 Overview and Packet Format
mainThe Fastboot UDP protocol provides a reliable communication layer over UDP. The device listens on UDP port
5554. Communication is host-driven: the device only sends packets in response to a host packet. If the host does not receive a response within 500ms, it re-transmits.Packet Structure
Each UDP packet follows this format:
Byte # 0 1 2 - 3 4+ Contents ID Flags Seq # Data - ID (1 byte):
0x00: Error0x01: Query0x02: Initialization0x03: Fastboot
- Flags (1 byte): The least significant bit (
C) is the continuation flag. IfC=1, the data is too large and continues in the next packet. All other bits must be0. - Seq # (2 bytes): A big-endian sequence number. The host increments this by 1 for each new packet. The device must respond with the same sequence number.
- Data (variable): The payload of the packet.
- ID (1 byte):