🧩 Allwinner Android 15 SDK — GRF (Build) Process Changes Explained

 

🔗 Related Article: Background of Allwinner’s Android 15 SDK and GRF Policy Adoption

Recently, Allwinner (AllwinnerTech) released a new Android 15 SDK for its A527 / A523 SoCs.
As mentioned in the previous post, starting from this version, Allwinner’s SDK structure and build process have changed — following Google’s GRF (Google Requirements Freeze) program.

 

🧠 Structural Changes Introduced by GRF Participation

Allwinner officially joined the Google GRF program starting from Android 13.
As a result, beginning with the Android 15 SDK, the build configuration and packaging structure have been slightly reorganized.

But don’t worry — the overall build flow remains almost identical to traditional Android BSP builds.
The only difference is that there’s now an additional step to merge the “frozen vendor code” with the latest Android framework, following GRF principles.

 

📂 SDK Layout Overview

When you open the Allwinner Android 15 SDK, you’ll notice that it contains two directories:

android13/   ← Vendor code (kernel, HAL, drivers, etc.)
android15/   ← Framework code (latest Android 15 AOSP base)

• android13/ → Frozen vendor BSP based on Google’s GRF requirements
• android15/ → Android 15 framework code (latest AOSP branch)

This means that even when building Android 15,
all hardware-related components such as kernel, HAL, and drivers are still referenced from the Android 13 tree.

 

⚙️ Allwinner Android 15 GRF Build Commands

Here’s the complete GRF build process for the Allwinner Android 15 SDK:

$ cd android15
android15$ source build/envsetup.sh     # Initialize Android build environment
android15$ lunch <product>-userdebug    # Select product and build variant
android15$ make -j16 -m ../android13    # GRF merge build (Framework + Vendor)
android15$ pack                         # Package the result into a single flashable image

💡 Command Explanation

CommandDescription

source build/envsetup.sh	Initializes the Android build environment
lunch <product>-userdebug	Selects the build target and variant (user/userdebug/eng)
make -j16 -m ../android13	Performs a GRF merge build (Framework + Vendor layers)
pack	Packages the generated binaries into a .img firmware image

🔍 Key Points Summary

ItemDescription

Policy	Google GRF (Google Requirements Freeze)
Vendor Code	Frozen at Android 13 (Vendor BSP)
Framework Code	Based on Android 15 (AOSP latest)
Build Method	Traditional Android build + -m option for vendor merge
Main Command	make -j16 -m ../android13
Result	Merged Android 15 image (Framework + Vendor)

🧩 In Short

• Android 13 = Vendor (frozen code)
• Android 15 = Framework (latest AOSP)
• Use the -m option in make to merge both layers
• The result: Android 13’s vendor layer operates seamlessly on Android 15’s framework

In other words, under the GRF policy, the Allwinner BSP is restructured to allow Android OS upgrades without modifying vendor code.

 

💬 Conclusion

Ultimately, the essence of GRF can be summarized as:

“Do kernel and HAL work in Android 13, but build in Android 15.”

While this may introduce some build path complexity for BSP developers,
in the long run, it reduces maintenance overhead and improves OS compatibility —
a positive step toward a more modular Android ecosystem.

---