This is an experimental Android bring-up project for the NUU B30 5G. NUU just calls the phone the "NUU B30 5G"; I use "non-Pro" here because there is also a completely separate B30 Pro, and mixing those two up while dealing with firmware would be a spectacularly bad idea.
There is no stable custom ROM yet. Honestly, this is still the part where I document the device, preserve what I can, and figure out how not to turn a working phone into an expensive black rectangle. Do not flash anything from this repository unless that exact file and procedure are explicitly marked safe and you have verified your own recovery path.
This project does not distribute proprietary firmware, private keys, device-unique calibration data, modem identifiers, IMEI values, serial numbers, or user data. That boundary is intentional, not an inconvenience to work around.
Right now the work is mostly documentation, stock-recovery research, safe image-preservation planning, manufacturer-feature preservation, and reproducible extraction workflows. None of that is the glamorous part, but it is the plumbing that has to exist before an Android 16+ or LineageOS bring-up can be treated as more than a risky experiment.
| Field | Current value |
|---|---|
| Device | NUU B30 5G non-Pro |
| Stock Android | Android 14 / API 34 |
| System security patch | 2026-04-05 |
| Vendor Android | Android 12 |
| Vendor security patch | 2025-03-05 |
| Architecture | arm64-v8a |
| Project Treble | enabled |
| Dynamic partitions | enabled |
| A/B slots | enabled |
| Observed slot | _a in Android after unlock/update; post-unlock fastboot paste reported b |
| Bootloader | unlocked |
| Verified boot | orange |
| SoC family | MediaTek Dimensity 7050 family |
The first milestone is deliberately boring: build a complete, safe, reproducible device-research repository before trying to ship a ROM.
- Collect complete device information.
- Preserve stock configuration metadata.
- Document bootloader, recovery, and DSU behavior.
- Test GSIs without permanent flashing.
- Identify hardware compatibility issues.
- Prepare extraction and device-tree work without publishing proprietary binaries.
The staged bring-up plan, feature-preservation policy, and release criteria live in docs/bringup-plan.md.
Before doing anything involving permanent flashing, read docs/stock-preservation-plan.md. That is the current preservation boundary.
docs/project-scope-boundaries.md explains what belongs in the public project, what has to stay private, and what I am not building at all.
For the stock Intelligent Assistance work, use docs/manufacturer-feature-preservation.md with templates/manufacturer-feature-test-matrix.md. The point is to understand the feature before deciding whether to preserve, replace, or drop it.
See docs/pre-phase3-readiness.md for the current checklist before read-only bootloader research.
See docs/pre-phase4-readiness.md and docs/stage-status.md for the current stage status.
From macOS or Linux with adb installed:
adb devices
scripts/collect-device-info.shResults are written to logs/device-info-YYYYMMDD-HHMMSS/. Run the sanitizer before sharing logs:
python3 scripts/sanitize-output.py --dry-run logs/device-info-YYYYMMDD-HHMMSS
python3 scripts/sanitize-output.py --output-dir logs/sanitized logs/device-info-YYYYMMDD-HHMMSSAdditional read-only preservation helpers:
scripts/inventory-system-packages.sh
scripts/inventory-vendor-features.sh
scripts/collect-intelligent-assistance-info.sh final-stock-pass
scripts/collect-feature-package-details.sh final-stock-features
scripts/collect-telephony-sim-info.sh final-stock-sim-toolkit
scripts/collect-dsu-pretest.sh built-in-plain-arm64-experimentalThe repository scripts do not unlock the bootloader, flash partitions, erase data, switch slots, or dump protected partitions. The operator manually unlocked the bootloader outside this scripted workflow. Any future command that modifies boot-critical storage needs an explicit warning and a recovery path that has actually been verified. "It should probably boot" is not a recovery plan.