AAB — nó là gì, khác biệt với APK và nguyên lý hoạt động

AAB là gì

AAB (Android App Bundle) là định dạng xuất bản do Google phát triển để thay thế APK phân phối qua Google Play. Bên trong AAB là một kho lưu trữ ZIP với phần mở rộng .aab chứa mã đã biên dịch, tài nguyên và siêu dữ liệu. Sự khác biệt chính: AAB không được cài đặt trực tiếp trên thiết bị.

Cách hoạt động

Nhà phát triển tải AAB lên Google Play Console. Khi người dùng cố gắng cài đặt ứng dụng, Google Play phân tích cấu hình thiết bị: mật độ màn hình (DPI), kiến trúc CPU, ngôn ngữ và phiên bản Android. Dựa trên phân tích này, một APK tối thiểu chỉ chứa các thành phần cần thiết được tạo ra.

Lịch sử áp dụng

Google đã giới thiệu AAB vào năm 2018 tại hội nghị I/O. Từ tháng 8 năm 2021, định dạng này trở thành bắt buộc đối với tất cả ứng dụng mới trên Google Play. Các ứng dụng hiện tại có thể tiếp tục sử dụng APK, nhưng ứng dụng mới chỉ được xuất bản ở định dạng AAB.

AAB khác gì so với APK

Sự khác biệt giữa AAB và APK là cơ bản: APK là tệp cài đặt hoàn chỉnh sẵn sàng để cài đặt. AAB là một vùng chứa với các thành phần nguồn cần được xử lý.

APK phù hợp để phân phối bên ngoài Google Play — qua trang web, email hoặc hệ thống MDM doanh nghiệp. AAB gắn liền với cơ sở hạ tầng của Google Play và không thể cài đặt trực tiếp. Để kiểm tra AAB, công cụ bundletool được sử dụng để mô phỏng việc tạo APK trên máy cục bộ.

Cấu trúc tệp AAB

Cấu trúc bên trong của AAB tương tự APK nhưng chứa các thư mục và tệp bổ sung để mô tả các mô-đun và phụ thuộc của chúng.

Mô-đun cơ sở (base)

Mô-đun base là thành phần bắt buộc của AAB. Nó chứa mã chính, tài nguyên và manifest của ứng dụng. Không có mô-đun cơ sở, ứng dụng không thể được xây dựng. Tất cả các mô-đun khác là tùy chọn và được kết nối qua Dynamic Delivery.

Định dạng Protobuf

Cấu hình AAB sử dụng Protocol Buffers (protobuf) thay vì XML. Các tệp .pb nhỏ gọn hơn và được phân tích nhanh hơn bởi cơ sở hạ tầng máy chủ của Google. Công cụ bundletool chuyển đổi protobuf sang định dạng có thể đọc được để gỡ lỗi.

Dynamic Delivery và các mô-đun ứng dụng

Dynamic Delivery là công nghệ chính mà AAB dựa trên. Nó cho phép phân phối cho người dùng chỉ những phần của ứng dụng phù hợp với thiết bị và ngôn ngữ của họ, cũng như tải các mô-đun bổ sung theo yêu cầu.

Các loại mô-đun

Các mô-đun Install-time được tải cùng với APK cơ sở trong quá trình cài đặt. Các mô-đun Conditional chỉ được phân phối khi đáp ứng các điều kiện — ví dụ: mô-đun có nội dung cho màn hình 4K. Các mô-đun On-demand được tải theo yêu cầu của người dùng trong ứng dụng.

Play Asset Delivery (PAD)

Đối với tài nguyên lớn (lên đến 2 GB), Play Asset Delivery được sử dụng thay cho tệp OBB. PAD hỗ trợ cùng ba chế độ phân phối: install-time, fast-follow (ngay sau khi cài đặt) và on-demand.

// Tải mô-đun theo yêu cầu qua SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Cấu hình mô-đun trong Gradle

Mỗi mô-đun động được mô tả trong một tệp build.gradle riêng với loại phân phối được chỉ định. Một mô-đun có thể chứa tài nguyên, mã và manifest riêng, độc lập với ứng dụng cơ sở.

Xây dựng AAB qua Gradle

Việc xây dựng AAB được thực hiện thông qua Android Gradle Plugin với tác vụ bundleRelease (hoặc bundleDebug). Kết quả là tệp .aab trong thư mục build/outputs/bundle/.

Cấu hình xây dựng

Không cần cấu hình đặc biệt để xây dựng AAB — Android Gradle Plugin hỗ trợ bundle theo mặc định. Chỉ cần chỉ định tác vụ bundle thay vì assemble.

// build.gradle.kts — xây dựng AAB với chữ ký
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Tác vụ: ./gradlew bundleRelease

Kiểm tra cục bộ qua bundletool

Google cung cấp công cụ bundletool để tạo APK từ AAB trên máy cục bộ. Lệnh `bundletool build-apks --bundle=app.aab --output=app.apks` tạo một bộ APK để kiểm tra trên các cấu hình thiết bị khác nhau.

bundletool cũng có thể giải nén AAB, hiển thị cấu hình của nó và xác minh tính toàn vẹn của chữ ký trước khi tải lên Google Play Console. Để gỡ lỗi, lệnh `bundletool dump manifest --bundle=app.aab` được sử dụng để hiển thị manifest của mô-đun cơ sở.

Cấu hình split trong AAB

Theo mặc định, AAB chia tài nguyên thành ba chiều: ngôn ngữ, mật độ màn hình (density) và kiến trúc CPU (abi). Nhà phát triển có thể tắt bất kỳ sự phân chia nào trong build.gradle — ví dụ: nếu ứng dụng chỉ hỗ trợ tiếng Anh. Việc tắt phân chia có nghĩa là tài nguyên cho tất cả các biến thể sẽ được đưa vào APK cơ sở.

Tối ưu hóa tài nguyên — AAB tự động chuyển đổi PNG sang WebP mà không giảm chất lượng, nén tài nguyên không sử dụng và loại bỏ các chuỗi trùng lặp. Các tối ưu hóa này được áp dụng ở phía Google Play khi tạo APK cuối cùng. Kết quả là người dùng nhận được APK nhỏ hơn 15–25% so với kho lưu trữ đầy đủ.

Xuất bản AAB trên Google Play

Quy trình xuất bản AAB trong Google Play Console chỉ khác APK ở định dạng tệp tải lên. Bảng điều khiển chấp nhận .aab, kiểm tra cấu trúc, chữ ký và cấu hình mô-đun, sau đó tạo APK cho từng loại thiết bị.

App Signing by Google Play

Khi tải AAB lên, Google Play đảm nhận việc quản lý khóa chữ ký. Nhà phát triển tải lên gói đã được ký bằng khóa upload và Google ký lại các APK được tạo bằng khóa riêng của mình. Điều này đơn giản hóa việc luân chuyển khóa và khôi phục quyền truy cập nếu mất keystore.

Kiểm tra trước khi phát hành

Google Play Console cung cấp kiểm tra AAB tích hợp: bạn có thể tải xuống APK đã tạo cho một thiết bị cụ thể hoặc chạy kiểm tra nội bộ qua các track Internal Testing, Closed Alpha và Open Beta.

Các vấn đề thường gặp với AAB và giải pháp

Việc chuyển đổi sang AAB có thể gây ra vấn đề, đặc biệt là trong các dự án có nhiều mô-đun động hoặc cấu hình tài nguyên phức tạp.

Lỗi cấu hình mô-đun

Nếu một mô-đun động tham chiếu đến tài nguyên của mô-đun cơ sở với tên không chính xác, Google Play sẽ từ chối AAB ở giai đoạn xác minh. Giải pháp — sử dụng kiểm tra lint trước khi xây dựng và kiểm tra tất cả các mô-đun qua bundletool cục bộ.

Phân chia ngôn ngữ và tác động đến hiệu suất

Việc phân chia theo ngôn ngữ có thể làm chậm khởi động ứng dụng nếu tài nguyên cho ngôn ngữ hiện tại được tải động. Khuyến nghị của Google là không phân chia ngôn ngữ nếu có ít hơn 10 ngôn ngữ hoặc sử dụng install-time cho những ngôn ngữ phổ biến nhất.

Tương thích với SDK bên thứ ba

Một số SDK (phân tích, quảng cáo, bản đồ) yêu cầu quyền truy cập vào toàn bộ manifest và tài nguyên. Việc kiểm tra tính tương thích với AAB là bước bắt buộc trước khi di chuyển. Hầu hết các SDK lớn (Firebase, Google Ads, Crashlytics) đều hỗ trợ đầy đủ AAB từ năm 2022. Để xác minh tính tương thích, bundletool với cờ --validate được sử dụng để mô phỏng việc tạo APK phía máy chủ.

Quản lý phiên bản AAB

AAB sử dụng versionCode từ manifest của mô-đun cơ sở. Không giống như APK, AAB cũng hỗ trợ versionCode riêng cho từng mô-đun — điều này cho phép cập nhật các phần riêng lẻ của ứng dụng mà không cần cài đặt lại hoàn toàn. Dynamic Delivery theo dõi các mô-đun đã cài đặt và chỉ phân phối các thành phần đã thay đổi trong quá trình cập nhật qua Google Play.

Giám sát và phân tích AAB

Google Play Console cung cấp phân tích chi tiết cho từng AAB: bao nhiêu APK đã được tạo, split nào được yêu cầu, kích thước tải xuống trung bình trên mỗi thiết bị. Android Vitals hiển thị các chỉ số hiệu suất của APK đã tạo. Dữ liệu này giúp tối ưu hóa cấu hình split và giảm kích thước tải xuống cho các loại thiết bị khác nhau.