Sử dụng Gradle để quản lý build version

Một trong những tính năng nổi bật của Android Studio là tích hợp Gradle và sử dụng nó như 1 build system dành cho Android. Chức năng tổng quát nhất đối với 1 build system là biên dịch mã nguồn trở thành file cài đặt để chạy ứng dụng (như đối với Android là build ra file .APK), tuy nhiên, Gradle không chỉ có như vậy, nó còn cung cấp cho ta nhiều tính năng hữu ích và thú vị khác. Bài viết này sẽ nói về phương pháp sử dụng gradle để quản lý build version trong Android studio.

Khái niệm về build variants

Build variant là những bản build khác nhau có thể được Gradle build ra. Các build variant đều dựa trên source code “lõi” của ứng dụng là các file JAVA code. Tuy nhiên, ta có thể định nghĩa các bản build khác nhau với những giá trị content khác nhau dựa vào các produc flavor. Để minh hoạ, ta sẽ tạo ra 1 project để test cho trực quan. Ta tạo 1 project có tên là BuildVersionGradleexample . Sau khi tạo xong, ta chọn vào file build.gradle (ở tầng app), sẽ thấy như sau:

Bây giờ ta sẽ thêm 2 product flavor (develop và product chẳng hạn) để tạo ra các bản build có nội dung khác nhau. Ta thêm đoạn code sau vào thẻ android:

Như hình trên ta thấy ta đã định nghĩa được 2 product flavor tương ứng với 2 bản build khác nhau và các cấu hình đối với mỗi bản build. Ở mỗi productFlavor, ta định nghĩa application id và hằng số BASE_URL để request tới trong mỗi phiên bản.

Bây giờ, ta sẽ vào MainActivity viết 1 chút code để hiển thị thông tin của mỗi bản build rồi sẽ so sánh sự khác biệt của 2 bản.

Ta sẽ viết 1 hàm lấy các thông tin đã định nghĩa (package name, BASE_URL) trong productFlavor. Hàm đó như sau:

Lưu ý

– Khi ta định nghĩa 1 filed bằng từ khoá buildConfigField, sau khi gradle build xong, từ khoá đó sẽ được tự động định nghĩa trong lớp BuildConfig, với giá trị mà ta đã gán. Đối với trường hợp này là BASE_URL

– Mặc định Android sẽ có 2 kiểu build (buildTypes) release và debug. Gradle mặc định sử dụng kiểu build debug để build nên ta không cần add thêm vào file build.gradle. Mặt khác, khi tạo project, android studio cũng tự động định nghĩa kiểu build release, nên ta cũng không cần định nghĩa luôn. Chỉ khi cần định nghĩa về các cấu hình để build, ta mới cần định nghĩa lại 2 kiểu buildType này. Như vậy hiện tại với mỗi productFlavors ta sẽ có 2 tuỳ chọn tương ứng với 2 buildType (debug và release)

Sau khi có information, ta sẽ hiển thị lên 1 textview để theo dõi kết quả:

Bây giờ, ta sẽ build phiên bản develop và xem thông tin được xuất ra bằng cách chọn vào mục Build Variants ở góc dưới bên trái màn hình, rồi chọn Build variants là developDebug:

Sau khi run chương trình, ta có kết quả

Làm tương tự với bản product, ta thu được

Như vậy là thông số ở mỗi bản build (application id, BASE_URL) sẽ thay đổi tuỳ vào giá trị ta đã định nghĩa đối với mỗi productFlavor. Ngoài việc định nghĩa các giá trị trong file build.gralde ra, ta cũng có thể định nghĩa các resource khác nhau để sử dụng với mỗi bản build tương ứng. Sau đây ta sẽ định nghĩa tên app và màu chữ hiển thị trong app đối với 2 productFlavor đã định nghĩa.

Ta thêm 2 thư mục tương ứng với 2 productFlavor, mỗi thư mục ta lại tạo các resource tương ứng như sau:

Ở file mỗi string.xml, ta định nghĩa app_name tương ứng với productFlavor của nó. Ví dụ đối với product:

<string name="app_name">buildversiongradleexampleProduct</string>

Ở file layout, ta sẽ thử đổi màu chữ (màu xanh đối với text hiển thị ở develop, đỏ với text ở product)

Ở file MainActivity.java ta thêm hàm getAppName() trả về tên của ứng dụng.

private String getAppName(){
    return    getApplicationInfo().loadLabel(getPackageManager()).toString();
}

Và chỉnh sửa lại hàm getInformation() để thêm appName vào chuỗi được hiển thị ra.

Build lại product debug:

Đối với bản develop

Ta thấy tên app và màu chữ đã được hiển thị đúng với các bản build khác nhau.

Như vậy tổng quát lại, ta có thể định nghĩa các configuration đối với mỗi bản buid để có thể build ra các phiên bản khác nhau của ứng dụng mà không cần phải chỉnh sửa source code. Tất cả chỉ cần làm duy nhất 1 lần khi cấu hình. Điều này giúp tiết kiệm thời gian và dễ dàng chỉnh sửa khi có sự thay đổi về yêu cầu giữa các phiên bản.

Ở lần sau mình sẽ viết về quản lý các version library và signing Config.