ระบบบิลด์ของ Android จะคอมไพล์ทรัพยากรและซอร์สโค้ดของแอป แล้วแพ็ก เป็น APK หรือ Android App Bundle ที่คุณสามารถทดสอบ, นำไปใช้งาน, ลงนาม และ จัดจำหน่ายได้
ในภาพรวมการสร้าง Gradle และโครงสร้างการสร้าง Android เราได้พูดถึงแนวคิดการสร้างและโครงสร้างของแอป Android ตอนนี้ก็ถึงเวลาที่จะกำหนดค่าการสร้างแล้ว
อภิธานศัพท์การบิลด์ Android
Gradle และปลั๊กอิน Android Gradle ช่วยคุณกำหนดค่าด้านต่อไปนี้ ของการบิลด์
- ประเภทการสร้าง
-
ประเภทบิลด์จะกำหนดพร็อพเพอร์ตี้บางอย่างที่ Gradle ใช้เมื่อสร้างและ แพ็กเกจแอป โดยปกติแล้วจะมีการกำหนดค่าประเภทบิลด์สำหรับ ขั้นตอนต่างๆ ของวงจรการพัฒนา
เช่น ประเภทบิลด์ดีบัก จะเปิดใช้ตัวเลือกการแก้ไขข้อบกพร่องและลงนามในแอปด้วยคีย์ดีบัก ขณะที่ ประเภทบิลด์รีลีสอาจลดขนาด ทำให้สับสน และลงนามในแอปด้วยคีย์รีลีส สำหรับการเผยแพร่
คุณต้องกำหนดประเภทบิลด์อย่างน้อย 1 ประเภทเพื่อ สร้างแอป Android Studio จะสร้างประเภทบิลด์ดีบักและรีลีส โดยค่าเริ่มต้น หากต้องการเริ่มปรับแต่งการตั้งค่าการแพ็กเกจสำหรับแอป โปรดดูวิธีกำหนดค่าประเภทบิลด์
- รสชาติของผลิตภัณฑ์
- Product Flavor แสดงถึงแอปเวอร์ชันต่างๆ ที่คุณสามารถ เผยแพร่ให้ผู้ใช้ เช่น เวอร์ชันฟรีและเวอร์ชันที่ต้องชำระเงิน คุณสามารถ ปรับแต่ง Product Flavor เพื่อใช้โค้ดและทรัพยากรที่แตกต่างกันขณะแชร์ และนำส่วนที่ใช้ร่วมกันในแอปทุกเวอร์ชันกลับมาใช้ใหม่ได้ Product Flavor เป็นตัวเลือก และคุณต้องสร้างด้วยตนเอง หากต้องการเริ่มสร้างแอปเวอร์ชันต่างๆ ให้ดูวิธีกำหนดค่า Product Flavor
- สร้างตัวแปร
- ตัวแปรบิลด์คือผลลัพธ์ที่ได้จากการรวมประเภทบิลด์และรสชาติผลิตภัณฑ์ และ เป็นการกำหนดค่าที่ Gradle ใช้เพื่อสร้างแอปของคุณ การใช้ตัวแปรบิลด์จะช่วยให้ คุณสร้างเวอร์ชันดีบักของรสชาติผลิตภัณฑ์ได้ในระหว่างการพัฒนา และสร้างเวอร์ชันรีลีสที่ลงชื่อของรสชาติผลิตภัณฑ์เพื่อการจัดจำหน่ายได้ แม้ว่าคุณจะไม่ได้กำหนดค่าตัวแปรของบิวด์โดยตรง แต่คุณก็กำหนดค่า ประเภทบิวด์และรสชาติของผลิตภัณฑ์ที่ประกอบกันเป็นตัวแปรของบิวด์ได้ การสร้างประเภทบิลด์ หรือรสชาติผลิตภัณฑ์เพิ่มเติมจะสร้างตัวแปรบิลด์เพิ่มเติมด้วย หากต้องการดูวิธีสร้างและจัดการตัวแปรของบิลด์ โปรดอ่านภาพรวมกำหนดค่าตัวแปรของบิลด์
- รายการในไฟล์ Manifest
- คุณระบุค่าสำหรับพร็อพเพอร์ตี้บางอย่างของไฟล์ Manifest ในการกำหนดค่าตัวแปรบิลด์ได้ ค่าการสร้างเหล่านี้จะลบล้างค่าที่มีอยู่ใน ไฟล์ Manifest ซึ่งจะมีประโยชน์หากคุณต้องการสร้างแอปหลายรูปแบบ ที่มีชื่อแอปพลิเคชัน, SDK เวอร์ชันขั้นต่ำ หรือ SDK เวอร์ชันเป้าหมายแตกต่างกัน เมื่อมีไฟล์ Manifest หลายรายการ เครื่องมือผสานไฟล์ Manifest จะ ผสานการตั้งค่าไฟล์ Manifest
- การขึ้นต่อกัน
- ระบบบิลด์จะจัดการการอ้างอิงโปรเจ็กต์จากระบบไฟล์ในเครื่อง และจากที่เก็บข้อมูลระยะไกล ซึ่งหมายความว่าคุณไม่ต้องค้นหา ดาวน์โหลด และคัดลอกแพ็กเกจไบนารีของ Dependency ลงในไดเรกทอรีโปรเจ็กต์ด้วยตนเอง ดูข้อมูลเพิ่มเติมได้ที่หัวข้อเพิ่มการพึ่งพาบิลด์
- การลงนาม
- ระบบบิลด์ช่วยให้คุณระบุการตั้งค่าการลงนามในการกำหนดค่าบิลด์ และลงนามในแอปโดยอัตโนมัติในระหว่างกระบวนการบิลด์ได้ ระบบบิลด์จะลงนามเวอร์ชันแก้ไขข้อบกพร่องด้วยคีย์และ ใบรับรองเริ่มต้นโดยใช้ข้อมูลเข้าสู่ระบบที่ทราบเพื่อหลีกเลี่ยงการแจ้งรหัสผ่านในเวลาบิลด์ ระบบบิลด์จะไม่ลงนามในเวอร์ชันรีลีส เว้นแต่คุณจะ กำหนดค่าการลงนามสำหรับบิลด์นี้อย่างชัดเจน หากไม่มีคีย์รุ่น คุณสามารถสร้างคีย์ได้ตามที่อธิบายไว้ในลงนามในแอป การสร้างรุ่นที่ลงนามแล้ว เป็นสิ่งจำเป็นสำหรับการเผยแพร่แอปผ่าน App Store ส่วนใหญ่
- การลดขนาดโค้ดและทรัพยากร
- ระบบบิลด์ช่วยให้คุณระบุไฟล์กฎ ProGuard ที่แตกต่างกันสำหรับ แต่ละบิลด์ตัวแปรได้ เมื่อสร้างแอป ระบบบิลด์จะใช้ชุดกฎที่เหมาะสมเพื่อลดขนาด โค้ดและทรัพยากรโดยใช้เครื่องมือลดขนาดในตัว เช่น R8 การย่อขนาดโค้ดและทรัพยากรจะช่วยลดขนาด APK หรือ AAB ได้
- การรองรับ APK หลายรายการ
- ระบบบิลด์ช่วยให้คุณสร้าง APK ต่างๆ โดยอัตโนมัติ ซึ่งแต่ละ APK จะมีเฉพาะโค้ดและทรัพยากรที่จำเป็น สำหรับความหนาแน่นของหน้าจอหรือ Application Binary Interface (ABI) ที่เฉพาะเจาะจง ดูข้อมูลเพิ่มเติมได้ที่ สร้าง APK หลายรายการ อย่างไรก็ตาม การเผยแพร่ AAB รายการเดียวเป็น แนวทางที่แนะนำ เนื่องจากมีตัวเลือกการแยกตามภาษาเพิ่มเติมจาก ความหนาแน่นของหน้าจอและ ABI ขณะเดียวกันก็ไม่จำเป็นต้องอัปโหลด อาร์ติแฟกต์หลายรายการไปยัง Google Play แอปใหม่ทั้งหมดที่ส่งหลังจากเดือนสิงหาคม 2021 จะต้องใช้ AAB
เวอร์ชัน Java ในบิลด์ Android
ไม่ว่าคุณจะเขียนซอร์สโค้ดใน Java, Kotlin หรือทั้ง 2 ภาษา คุณต้องเลือก JDK หรือเวอร์ชันภาษา Java สําหรับบิลด์ในหลายที่ ดูรายละเอียดได้ที่เวอร์ชัน Java ในบิลด์ Android
สร้างไฟล์การกำหนดค่าบิลด์
การสร้างการกำหนดค่าบิลด์ที่กำหนดเองกำหนดให้คุณต้องทำการเปลี่ยนแปลงไฟล์การกำหนดค่าบิลด์อย่างน้อย 1 ไฟล์ ไฟล์ข้อความธรรมดาเหล่านี้ใช้ภาษาเฉพาะโดเมน (DSL) เพื่ออธิบายและจัดการตรรกะการสร้างโดยใช้สคริปต์ Kotlin ซึ่งเป็นรูปแบบหนึ่งของภาษา Kotlin นอกจากนี้ คุณยังใช้ Groovy ซึ่งเป็น ภาษาแบบไดนามิกสำหรับเครื่องเสมือน Java (JVM) เพื่อกำหนดค่าบิลด์ได้ด้วย
คุณไม่จำเป็นต้องทราบสคริปต์ Kotlin หรือ Groovy เพื่อเริ่มกำหนดค่าบิลด์ เนื่องจากปลั๊กอิน Android Gradle จะแนะนำองค์ประกอบ DSL ส่วนใหญ่ที่คุณต้องการ ดูข้อมูลเพิ่มเติมเกี่ยวกับ DSL ของปลั๊กอิน Android Gradle ได้ที่ เอกสารอ้างอิง DSL สคริปต์ Kotlin ยังขึ้นอยู่กับ Gradle Kotlin DSL พื้นฐานด้วย
เมื่อเริ่มโปรเจ็กต์ใหม่ Android Studio จะสร้างไฟล์เหล่านี้บางส่วนให้คุณโดยอัตโนมัติและป้อนข้อมูลตามค่าเริ่มต้นที่เหมาะสม ดูภาพรวมของไฟล์ที่สร้างได้ที่ โครงสร้างการบิลด์ Android
ไฟล์ Gradle Wrapper
Gradle Wrapper (gradlew
) เป็นแอปพลิเคชันขนาดเล็กที่รวมอยู่ในซอร์สโค้ด
ของคุณ ซึ่งจะดาวน์โหลดและเปิดใช้ Gradle เอง
ซึ่งจะช่วยให้การดำเนินการบิลด์มีความสอดคล้องกันมากขึ้น นักพัฒนาแอปจะดาวน์โหลดซอร์สโค้ดของแอปพลิเคชันและเรียกใช้ gradlew
ซึ่งจะดาวน์โหลดการกระจาย Gradle
ที่จำเป็น และเปิดใช้ Gradle เพื่อสร้างแอปพลิเคชัน
ไฟล์ gradle/wrapper/gradle-wrapper.properties
มีพร็อพเพอร์ตี้ distributionUrl
ที่อธิบายว่าใช้ Gradle เวอร์ชันใดในการเรียกใช้บิลด์
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
ไฟล์การตั้งค่า Gradle
ไฟล์ settings.gradle.kts
(สำหรับ Kotlin DSL) หรือไฟล์
settings.gradle
(สำหรับ Groovy DSL) จะอยู่ในรูท
ของไดเรกทอรีโปรเจ็กต์ ไฟล์การตั้งค่านี้กำหนดการตั้งค่าที่เก็บระดับโปรเจ็กต์
และแจ้งให้ Gradle ทราบว่าควรมีโมดูลใดบ้างเมื่อสร้างแอป
โปรเจ็กต์แบบหลายโมดูลต้องระบุแต่ละโมดูลที่ควรอยู่ในบิลด์สุดท้าย
สำหรับโปรเจ็กต์ส่วนใหญ่ ไฟล์จะมีลักษณะดังต่อไปนี้โดยค่าเริ่มต้น
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
Groovy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. Here we * define the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
ไฟล์บิลด์ระดับบนสุด
ไฟล์ build.gradle.kts
ระดับบนสุด (สำหรับ Kotlin DSL) หรือ
ไฟล์ build.gradle
(สำหรับ Groovy DSL) จะอยู่ในไดเรกทอรีโปรเจ็กต์รูท โดยปกติแล้วจะกำหนดเวอร์ชันทั่วไปของปลั๊กอินที่โมดูลในโปรเจ็กต์ใช้
ตัวอย่างโค้ดต่อไปนี้อธิบายการตั้งค่าเริ่มต้นและองค์ประกอบ DSL ใน สคริปต์บิลด์ระดับบนสุดหลังจากสร้างโปรเจ็กต์ใหม่
Kotlin
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id("com.android.application") version "8.11.0" apply false id("com.android.library") version "8.11.0" apply false id("org.jetbrains.kotlin.android") version "2.1.20" apply false }
Groovy
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id 'com.android.application' version '8.11.0' apply false id 'com.android.library' version '8.11.0' apply false id 'org.jetbrains.kotlin.android' version '2.1.20' apply false }
ไฟล์บิลด์ระดับโมดูล
ไฟล์ build.gradle.kts
ระดับโมดูล (สำหรับ Kotlin DSL) หรือ
ไฟล์ build.gradle
(สำหรับ Groovy DSL) จะอยู่ในไดเรกทอรี project/module/
แต่ละรายการ ซึ่งช่วยให้คุณ
กำหนดการตั้งค่าบิลด์สำหรับโมดูลที่เฉพาะเจาะจงซึ่งไฟล์นี้อยู่ได้ การกำหนดค่า
การตั้งค่าการสร้างเหล่านี้ช่วยให้คุณระบุตัวเลือกการแพ็กเกจที่กำหนดเองได้ เช่น
ประเภทการสร้างและผลิตภัณฑ์เพิ่มเติม รวมถึงลบล้างการตั้งค่าใน
main/
ไฟล์ Manifest ของแอปหรือสคริปต์การสร้างระดับบนสุด
การตั้งค่า Android SDK
ไฟล์บิลด์ระดับโมดูลสำหรับแอปพลิเคชันของคุณมีการตั้งค่าที่ระบุ เวอร์ชัน Android SDK ที่ใช้เมื่อคอมไพล์ เลือกลักษณะการทำงานของแพลตฟอร์ม และ ระบุเวอร์ชันขั้นต่ำที่แอปพลิเคชันของคุณทำงาน
-
compileSdk
-
compileSdk
จะกำหนดว่า API ของ Android และ Java ใดบ้างที่พร้อมใช้งานเมื่อคอมไพล์ซอร์สโค้ด หากต้องการใช้ฟีเจอร์ล่าสุดของ Android ให้ใช้ Android SDK เวอร์ชันล่าสุดเมื่อคอมไพล์API ของแพลตฟอร์ม Android บางรายการอาจไม่พร้อมใช้งาน ใน API ระดับเก่า คุณสามารถ ป้องกันการใช้ฟีเจอร์ใหม่ๆ แบบมีเงื่อนไข หรือใช้ ไลบรารีความเข้ากันได้ของ AndroidX เพื่อใช้ฟีเจอร์ใหม่ๆ กับ Android API ระดับต่ำกว่า ได้
Android SDK แต่ละรายการมีชุดย่อยของ Java API สำหรับใช้ในแอปพลิเคชัน ตารางที่ ฉันใช้ Java API ใดในซอร์สโค้ด Java หรือ Kotlin ได้บ้าง แสดงระดับ Java API ที่พร้อมใช้งานตามเวอร์ชัน Android SDK API ของ Java เวอร์ชันใหม่กว่าจะได้รับการรองรับใน Android เวอร์ชันก่อนหน้าผ่าน การแปลง ซึ่งต้อง เปิดใช้ในการสร้าง
Android Studio จะแสดงคำเตือนหาก
compileSdk
ขัดแย้ง กับ Android Studio, AGP หรือข้อกำหนดการขึ้นต่อกันของไลบรารีในโปรเจ็กต์ เวอร์ชันปัจจุบัน -
minSdk
-
minSdk
ระบุ Android เวอร์ชันต่ำสุดที่คุณต้องการให้แอป รองรับ การตั้งค่าminSdk
จะจำกัดอุปกรณ์ที่ติดตั้งแอปของคุณได้การรองรับ Android เวอร์ชันที่ต่ำกว่าอาจต้องมีการตรวจสอบแบบมีเงื่อนไขเพิ่มเติม ในโค้ดหรือการใช้ไลบรารีความเข้ากันได้ของ AndroidX มากขึ้น คุณควร พิจารณาค่าใช้จ่ายในการบำรุงรักษาสำหรับการรองรับเวอร์ชันที่ต่ำกว่าเทียบกับ เปอร์เซ็นต์ของผู้ใช้ที่ยังคงใช้เวอร์ชันที่ต่ำกว่าเหล่านั้น ดูแผนภูมิเวอร์ชันในวิซาร์ดโปรเจ็กต์ใหม่ของ Android Studio เพื่อดูเปอร์เซ็นต์การใช้งานเวอร์ชันปัจจุบัน
เมื่อแก้ไขโค้ดใน Android Studio หรือเรียกใช้การตรวจสอบระหว่างการบิลด์ Lint จะเตือนเกี่ยวกับ API ที่คุณใช้ซึ่งไม่พร้อมใช้งานใน
minSdk
คุณควรแก้ไขโดย กำหนดเงื่อนไขสำหรับฟีเจอร์ใหม่กว่า หรือใช้Appcompat
เพื่อให้มีความเข้ากันได้แบบย้อนหลัง -
targetSdk
-
targetSdk
มีไว้สำหรับวัตถุประสงค์ 2 ประการ ได้แก่- ซึ่งจะกำหนดลักษณะการทำงานของแอปพลิเคชันในระหว่างรันไทม์
- โดยจะยืนยันเวอร์ชัน Android ที่คุณทดสอบ
หากคุณเรียกใช้ในอุปกรณ์ที่ใช้ Android เวอร์ชันสูงกว่า
targetSdk
Android จะเรียกใช้แอปในโหมดความเข้ากันได้ ซึ่งทำงานคล้ายกับเวอร์ชันที่ต่ำกว่าที่ระบุไว้ในtargetSdk
ตัวอย่างเช่น เมื่อ API 23 เปิดตัวโมเดลสิทธิ์รันไทม์ ไม่ใช่ทุกแอปที่พร้อมนำไปใช้ในทันที การตั้งค่าtargetSdk
เป็น 22 จะช่วยให้แอปเหล่านั้นทำงานในอุปกรณ์ API 23 ได้โดยไม่ต้องใช้สิทธิ์รันไทม์ และใช้ฟีเจอร์ที่รวมอยู่ในcompileSdk
เวอร์ชันล่าสุดได้ นโยบายการจัดจำหน่ายของ Google Play บังคับใช้ นโยบายเพิ่มเติมเกี่ยวกับระดับ API เป้าหมายค่าของ
targetSdk
ต้องน้อยกว่าหรือเท่ากับ ค่าของcompileSdk
หมายเหตุ: ค่าของ compileSdk
และ targetSdk
ไม่จำเป็นต้องเหมือนกัน โปรดคำนึงถึงหลักการพื้นฐานต่อไปนี้
compileSdk
ช่วยให้คุณเข้าถึง API ใหม่ๆ ได้targetSdk
กำหนดลักษณะการทำงานของรันไทม์ของแอปtargetSdk
ต้องน้อยกว่าหรือเท่ากับcompileSdk
ตัวอย่างสคริปต์บิลด์ของโมดูลแอป
สคริปต์การสร้างโมดูลแอป Android ตัวอย่างนี้จะระบุองค์ประกอบและการตั้งค่า DSL พื้นฐานบางอย่าง
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace = "com.example.myapp" /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk = 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdk = 21 // Specifies the API level used to test the app. targetSdk = 33 // Defines the version number of your app. versionCode = 1 // Defines a user-friendly version name for your app. versionName = "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ getByName("release") { isMinifyEnabled = true // Enables code shrinking for the release build type. proguardFiles( getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" ) } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions += "tier" productFlavors { create("free") { dimension = "tier" applicationId = "com.example.myapp.free" } create("paid") { dimension = "tier" applicationId = "com.example.myapp.paid" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation(project(":lib")) implementation("androidx.appcompat:appcompat:1.7.1") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
Groovy
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace 'com.example.myapp' /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdk 21 // Specifies the API level used to test the app. targetSdk 33 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store or an Android device simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation project(":lib") implementation 'androidx.appcompat:appcompat:1.7.1' implementation fileTree(dir: 'libs', include: ['*.jar']) }
ไฟล์ Gradle Properties
นอกจากนี้ Gradle ยังมีไฟล์พร็อพเพอร์ตี้ 2 ไฟล์ซึ่งอยู่ในไดเรกทอรีโปรเจ็กต์ราก ที่คุณใช้ระบุการตั้งค่าสำหรับชุดเครื่องมือบิลด์ Gradle ได้ด้วย
-
gradle.properties
- คุณกำหนดการตั้งค่า Gradle ทั่วทั้งโปรเจ็กต์ได้ที่นี่ เช่น ขนาดฮีปสูงสุดของ Gradle Daemon ดูข้อมูลเพิ่มเติมได้ที่สภาพแวดล้อมในการสร้าง
-
local.properties
-
กำหนดค่าพร็อพเพอร์ตี้สภาพแวดล้อมในเครื่องสำหรับระบบบิลด์ ซึ่งรวมถึง
รายการต่อไปนี้
ndk.dir
- เส้นทางไปยัง NDK เลิกใช้งานพร็อพเพอร์ตี้นี้แล้ว ระบบจะติดตั้ง NDK เวอร์ชันที่ดาวน์โหลดไว้ในไดเรกทอรีndk
ภายในไดเรกทอรี Android SDKsdk.dir
- เส้นทางไปยัง Android SDKcmake.dir
- เส้นทางไปยัง CMakendk.symlinkdir
- ใน Android Studio 3.5 ขึ้นไป จะสร้าง Symlink ไปยัง NDK ซึ่งอาจสั้นกว่าเส้นทาง NDK ที่ติดตั้ง
แมป NDK ไปยังเส้นทางที่สั้นลง (Windows เท่านั้น)
ใน Windows เครื่องมือในโฟลเดอร์ NDK ที่ติดตั้ง เช่น ld.exe
จะมีเส้นทางยาว
เครื่องมือไม่รองรับเส้นทางที่ยาว
หากต้องการสร้างเส้นทางที่สั้นลง ให้ตั้งค่าพร็อพเพอร์ตี้ local.properties
ใน ndk.symlinkdir
เพื่อขอให้ปลั๊กอิน Android Gradle สร้างลิงก์สัญลักษณ์ไปยัง NDK เส้นทางของ Symlink นั้นอาจสั้นกว่าโฟลเดอร์ NDK ที่มีอยู่
เช่น ndk.symlinkdir = C:\
จะทำให้เกิดลิงก์สัญลักษณ์ต่อไปนี้
C:\ndk\19.0.5232133
ซิงค์โปรเจ็กต์กับไฟล์ Gradle
เมื่อคุณทำการเปลี่ยนแปลงไฟล์การกำหนดค่าบิลด์ในโปรเจ็กต์ Android Studio จะกำหนดให้คุณซิงค์ไฟล์โปรเจ็กต์เพื่อให้สามารถ นำเข้าการเปลี่ยนแปลงการกำหนดค่าบิลด์และเรียกใช้การตรวจสอบบางอย่างเพื่อให้แน่ใจว่า การกำหนดค่าจะไม่ทำให้เกิดข้อผิดพลาดในการบิลด์
หากต้องการซิงค์ไฟล์โปรเจ็กต์ ให้คลิกซิงค์เลยในแถบการแจ้งเตือนที่ปรากฏขึ้นเมื่อคุณทำการเปลี่ยนแปลง ดังที่แสดงในรูปที่ 2 หรือคลิกซิงค์โปรเจ็กต์
จากแถบเมนู หาก Android Studio พบข้อผิดพลาดในการกำหนดค่า เช่น ซอร์สโค้ดใช้ฟีเจอร์ API ที่ใช้ได้ในระดับ API ที่สูงกว่า
compileSdkVersion
เท่านั้น
หน้าต่างข้อความจะอธิบายปัญหา

ชุดแหล่งที่มา
Android Studio จะจัดกลุ่มซอร์สโค้ดและทรัพยากรสำหรับแต่ละโมดูล
ไว้ในชุดแหล่งที่มาอย่างเป็นตรรกะ เมื่อคุณสร้างโมดูลใหม่ Android Studio
จะสร้างmain/
ชุดแหล่งที่มาภายในโมดูล ชุดแหล่งที่มาของโมดูล
main/
มีโค้ดและทรัพยากรที่ใช้โดยตัวแปรบิลด์ทั้งหมด
ไดเรกทอรีชุดแหล่งที่มาเพิ่มเติมเป็นตัวเลือก และ Android
Studio จะไม่สร้างไดเรกทอรีเหล่านี้ให้คุณโดยอัตโนมัติเมื่อคุณกําหนดค่าบิลด์
ตัวแปรใหม่ อย่างไรก็ตาม การสร้างชุดแหล่งที่มาที่คล้ายกับ main/
จะช่วย
จัดระเบียบไฟล์และทรัพยากรที่ Gradle ควรใช้เมื่อสร้างแอปเวอร์ชันใดเวอร์ชันหนึ่งเท่านั้น
-
src/main/
- ชุดแหล่งที่มานี้มีโค้ดและทรัพยากรที่ใช้ร่วมกันในตัวแปรบิลด์ทั้งหมด
-
src/buildType/
- สร้างชุดแหล่งที่มานี้เพื่อรวมโค้ดและทรัพยากรสำหรับ ประเภทบิลด์ที่เฉพาะเจาะจงเท่านั้น
-
src/productFlavor/
-
สร้างชุดแหล่งที่มานี้ให้มีโค้ดและทรัพยากรสำหรับรสชาติผลิตภัณฑ์
ที่เฉพาะเจาะจงเท่านั้น
หมายเหตุ: หากกำหนดค่าบิลด์ให้รวมรสชาติผลิตภัณฑ์หลายรายการ คุณจะสร้างไดเรกทอรีชุดแหล่งที่มาสำหรับชุดค่าผสมรสชาติผลิตภัณฑ์แต่ละชุดระหว่างมิติข้อมูลรสชาติได้โดยทำดังนี้
src/productFlavor1ProductFlavor2/
-
src/productFlavorBuildType/
- สร้างชุดแหล่งข้อมูลนี้เพื่อให้มีโค้ดและทรัพยากรสำหรับตัวแปรบิลด์ที่เฉพาะเจาะจงเท่านั้น
เช่น หากต้องการสร้างแอปเวอร์ชัน "fullDebug" ระบบบิลด์จะผสานโค้ด การตั้งค่า และทรัพยากรจากชุดแหล่งที่มาต่อไปนี้
-
src/fullDebug/
(ชุดแหล่งที่มาของตัวแปรบิลด์) -
src/debug/
(ชุดแหล่งที่มาของประเภทบิลด์) -
src/full/
(ชุดแหล่งที่มาของรสชาติผลิตภัณฑ์) -
src/main/
(ชุดแหล่งข้อมูลหลัก)
หมายเหตุ: เมื่อสร้างไฟล์หรือไดเรกทอรีใหม่ใน Android Studio ให้ใช้ตัวเลือกเมนูไฟล์ > ใหม่ เพื่อสร้าง สำหรับชุดแหล่งข้อมูลที่เฉพาะเจาะจง ชุดแหล่งที่มาที่คุณเลือกได้จะอิงตามการกำหนดค่าบิลด์ และ Android Studio จะสร้างไดเรกทอรีที่จำเป็นโดยอัตโนมัติหากยังไม่มี
หากชุดแหล่งที่มาที่แตกต่างกันมีไฟล์เดียวกันในเวอร์ชันที่ต่างกัน Gradle จะใช้ลำดับความสำคัญต่อไปนี้เมื่อตัดสินใจว่าจะใช้ไฟล์ใด แหล่งที่มา ที่อยู่ทางซ้ายจะลบล้างไฟล์และการตั้งค่าของแหล่งที่มาที่อยู่ทาง ขวา
build variant > build type > product flavor > main source set > library dependencies
ซึ่งจะช่วยให้ Gradle ใช้ไฟล์ที่เฉพาะเจาะจงกับตัวแปรบิลด์ที่คุณ พยายามสร้างได้ในขณะที่นำกิจกรรม ตรรกะของแอปพลิเคชัน และ ทรัพยากรที่ใช้ร่วมกันในแอปเวอร์ชันอื่นๆ มาใช้ซ้ำ
เมื่อผสานไฟล์ Manifest หลายไฟล์ Gradle จะใช้ลำดับความสำคัญเดียวกันเพื่อให้แต่ละตัวแปรบิลด์สามารถ กำหนดคอมโพเนนต์หรือสิทธิ์ที่แตกต่างกันในไฟล์ Manifest สุดท้ายได้ ดูข้อมูลเพิ่มเติมเกี่ยวกับ การสร้างชุดแหล่งข้อมูลที่กำหนดเองได้ที่สร้างชุดแหล่งข้อมูล
แคตตาล็อกเวอร์ชัน
หากบิลด์มีหลายโมดูลที่มีการอ้างอิงร่วมกัน หรือคุณมีหลายโปรเจ็กต์อิสระที่มีการอ้างอิงร่วมกัน เราขอแนะนำให้คุณใช้แคตตาล็อกเวอร์ชันหรือบิลออฟแมททีเรียล (BOM) เพื่อระบุเวอร์ชันทั่วไป
ระบบบิลด์อื่นๆ
การสร้างแอป Android ด้วย Bazel เป็นไปได้ แต่ยังไม่รองรับอย่างเป็นทางการ Android Studio ไม่รองรับโปรเจ็กต์ Bazel อย่างเป็นทางการ
ดูข้อมูลเพิ่มเติมเกี่ยวกับข้อจำกัดปัจจุบันของการสร้างด้วย Bazel ได้ที่ปัญหาที่ทราบ