🧩 Allwinner Android 15 SDK — GRF Integration and Build Structure Explained

Recently, Allwinner (AllwinnerTech) released the new Android 15 SDK for the A527 and A523 SoCs.
However, upon closer inspection, this SDK is quite different from previous versions — not only in structure but also in how it is built.

So, what changed?
The main reason is that Google’s GRF (Google Requirements Freeze) program has been officially introduced into Allwinner’s BSP starting with Android 15.

📘 What Is GRF? (Google Requirements Freeze)

GRF is Google’s long-term vendor compatibility program for SoC manufacturers.
In simple terms, it allows vendors like Allwinner, Qualcomm, or MediaTek to avoid re-modifying their kernel, HAL, drivers, and firmware each time Android releases a new version.

Once a vendor baseline (frozen version) is defined, that code can be reused across four consecutive Android releases without modification.

🔍 GRF Policy Example

Android VersionVendor VersionStatus

Android 13	Vendor 13	Baseline (frozen)
Android 14	Vendor 13	Reused (1st upgrade)
Android 15	Vendor 13	Reused (2nd upgrade)
Android 16	Vendor 13	Reused (3rd upgrade)
Android 17	Vendor 17	New freeze starts

➡️ In other words, if the vendor (SoC) code is frozen at Android 13, it can continue to work through Android 16 without modification.
Assuming one Android release per year, that means roughly four years of upgrade compatibility with no vendor-level changes required.

That’s great for maintainability — though it inevitably makes custom modifications (kernel / driver tweaks) more complicated 😅.

🧠 Structural Changes in the Allwinner Android 15 SDK

One major difference in the newly released SDK is that it now includes two Android trees:
an Android 13 folder and an Android 15 folder.

Previously, if you downloaded the “Android 13 SDK,” it contained only the Android 13 codebase.
Now, under the GRF model, both coexist.

📂 SDK Layout Overview

LayerContentModification Source

Vendor Layer	BOOT, INIT_BOOT, VENDOR_BOOT, VENDOR, VENDOR_DLKM — all hardware-specific HAL and BSP components	Modified in Android 13
Framework Layer	SYSTEM, PRODUCT (GMS, apps, libcore, ART, etc.)	Modified in Android 14+

android13/  → frozen vendor SDK (Allwinner stable BSP)
android15/  → framework SDK (latest Google AOSP version)​

• Vendor SDK: the frozen codebase from Android 13
• Framework SDK: the up-to-date AOSP base used from Android 14 onward

Building the final firmware requires merging both SDKs — that’s the core of the GRF build process.

⚙️ Build Structure Under GRF

So effectively, Allwinner’s Android 15 SDK works like this:

• Vendor code: reused from Android 13
• Framework code: updated to Android 15 (AOSP-based)
• Build system: merges both (13 + 15) into a single image

In short, hardware-related work (kernel, bootloader, drivers) should still be done in the Android 13 vendor tree,
while the actual build and framework are handled under Android 15.

🤯 In other words: you tweak the kernel in 13, but you build everything in 15.
Complex? Oh yes — quite a bit. 😂

📑 Reference Documentation

Within the SDK package, you’ll find an important document:

📄 Android_GRF_编译指南.pdf

It describes the new GRF-compliant SDK layout, build sequence, and packaging method in detail.
Understanding that guide will help you build successfully under the new structure —
though if you’ve been used to the legacy Allwinner build style, it may feel a bit unfamiliar at first.

🧩 Summary

ItemDescription

Policy	Google GRF (Google Requirements Freeze)
Core change	Vendor layer frozen, framework layer separated
Maintenance	Vendor code valid for up to four Android versions
SDK layout	android13/ (vendor) + android14/15/ (framework)
Build reference	Android_GRF_编译指南.pdf
Advantage	Reduced vendor maintenance burden
Drawback	More difficult to customize or port kernels/drivers

💬 Conclusion

With GRF now officially adopted, Allwinner’s BSP structure is clearly moving toward a
“dual-layer” build model: Framework / Vendor separation.

In short:

“Configure kernel in Android 13, build in Android 15.”

That’s the new way forward for Allwinner Android development —
and while it adds a bit of complexity, it also brings long-term stability and upgrade flexibility.