A small, local command-line tool for creating .brd device-profile files used by ARAS for development, compatibility testing, and reproducible Android environments.
A .brd file describes how an Android environment should identify itself at the software level, allowing developers to test applications against different device configurations without rebuilding the guest image.
Android applications can make decisions based on the device information reported by the operating system.
For development and compatibility testing, it is useful to reproduce those reported values without maintaining a separate guest image for every configuration.
board provides a small, versioned profile format for doing exactly that.
Profiles are:
- local
- user-created
- explicitly selected by the user
- portable between development environments
- independent of ARAS accounts or services
- not distributed through a central profile store
ARAS ships with a neutral default identity (pocket). Users can create their own profiles when they need to reproduce a particular device configuration.
Profiles describe software-reported device identity. They do not create or claim the underlying physical hardware.
A useful device profile should contain values observed from the device or obtained from reliable public device specifications.
For example, developers may collect Android properties from a device using:
adb shell getpropor use publicly documented device specifications.
board validate checks whether a .brd file is structurally valid. It does not verify that the values correspond to a particular manufacturer's hardware.
A syntactically valid profile can therefore still contain incorrect information.
A profile can specify:
- brand
- manufacturer
- model
- device codename
- human-readable device name
These correspond to software-visible device identity fields.
A profile may optionally specify:
- SoC manufacturer
- SoC model
- GPU model
These three values are treated as one group and must either all be present or all be absent.
When omitted, ARAS retains its native chip information.
Format version 3 additionally supports:
| Flag | Field | Android property | Charset |
|---|---|---|---|
--board <token> |
Board | ro.product.board |
[A-Za-z0-9._-] |
--hardware <token> |
Hardware | ro.hardware / ro.boot.hardware |
token |
--build-id <text> |
Build ID | ro.build.display.id |
text |
--gles-version <token> |
OpenGL ES version | ro.opengles.version |
token |
Each field is independent. A profile may contain any subset of these fields.
A label-only profile leaves the corresponding native values unchanged.
--gles-version accepts the Android integer representation, for example:
196609 = OpenGL ES 3.1
196610 = OpenGL ES 3.2
ARAS only accepts values supported by its graphics stack. A profile cannot add graphics capabilities that the underlying renderer does not provide.
The ARAS default is 196609 (ES 3.1). ES 3.2 is not achievable on this stack: it requires geometry shaders, which Metal provides no equivalent for, so ANGLE cannot expose GL_EXT_geometry_shader and therefore cannot advertise ES 3.2. Declaring 3.2 anyway would let an app start and then break on the first 3.2 entry point — worse than being rejected at the door. An override is honored only when it matches what the driver actually supports; this value is settable for measurement, not for making an unsupported claim.
The same default applies whether the identity comes from a profile override or from ARAS's built-in identity.
A .brd profile is an identity/configuration layer, not a hardware emulator.
It does not provide:
- physical hardware
- a different GPU implementation
- a different CPU
- a different bootloader
- a different security processor
- a different TEE
- hardware-backed cryptographic keys
- a different Android API level
- graphics features unavailable to the underlying renderer
- hardware-backed device attestation
Those properties remain determined by the underlying ARAS environment.
In particular, changing software-reported identity should not be interpreted as changing Google certification, Play Integrity status, SafetyNet status, or other hardware/security attestations.
Applications that require those services should be tested using the appropriate supported testing configuration.
Chip and GPU identity are intentionally treated as a single group.
A profile must provide:
soc manufacturer
soc model
gpu model
together, or provide none of them.
This prevents incomplete profiles such as specifying a chip without its corresponding GPU.
For example:
--soc-manufacturer "Qualcomm" \
--soc-model "Snapdragon 8 Elite" \
--gpu-model "Adreno 830"Leaving all three unspecified is completely valid.
Every .brd file contains an author field.
The author is simply metadata supplied by the person creating the profile. ARAS displays it as:
self-reported, not verified
The author field is not a manufacturer signature, certification, or proof of ownership.
board is deliberately simple:
- no account
- no sign-in
- no network connection
- no telemetry
- no phone-home mechanism
- no central profile repository
- no ARAS-run profile marketplace
- no automatic profile downloads
Profiles can be exchanged directly between developers or teams.
Create a profile interactively:
board createInspect a profile:
board inspect <file>View profile metadata and contents:
board view <file>Validate a profile:
board validate <file>Show available commands:
board helpboard create \
--brand samsung \
--manufacturer Samsung \
--model SM-S948B \
--codename SM_S948B \
--name "Galaxy S26 Ultra" \
--author anonymousAn extended development profile can additionally specify the technical identity:
board create \
--brand samsung \
--manufacturer Samsung \
--model SM-S948B \
--codename SM_S948B \
--name "Galaxy S26 Ultra" \
--author anonymous \
--soc-manufacturer "Qualcomm" \
--soc-model "..." \
--gpu-model "..." \
--board ... \
--hardware ... \
--build-id "..." \
--gles-version 196609Use values appropriate to the device configuration being reproduced.
The .brd format is intentionally small and versioned.
It is not intended to provide secrecy. board is open source, so the format is inherently inspectable.
The binary format instead provides:
- explicit versioning
- predictable field layouts
- strict validation
- compact profiles
- resistance to accidental structural modification
- direct consumption by the ARAS identity layer
A .brd is therefore closer to a small device-profile payload than a general-purpose configuration file.
See brd_format.h for the exact format specification.
board is provided as a development and compatibility-testing tool.
Device profiles allow developers to reproduce software-reported Android device configurations when testing applications across different environments.
Users are responsible for how they use profiles and for complying with the terms, licenses, policies, and requirements applicable to the applications and services they test.
A profile does not provide physical device capabilities, manufacturer authorization, Google certification, or hardware-backed security credentials.
Changing software-reported device properties does not guarantee that an application will accept an environment, and does not change the application's own security, licensing, account, anti-abuse, or integrity requirements.
Developers testing applications that enforce environment or device requirements should use the application's supported testing mechanisms where available.
board does not distribute manufacturer profiles or claim that user-created profiles are official, authorized, certified, or endorsed by any device manufacturer.
Profile metadata is self-reported by its creator.
Device names, manufacturers, product names, trademarks, and other identifiers contained in user-created profiles remain the property of their respective owners.
board does not grant any trademark, certification, distribution, or authorization rights to those names or identifiers.
makeRun the test suite:
make testRequirements:
- C99-compatible compiler
- libc
No additional dependencies are required.