ระบบบิลด์ Gradle ใน Android Studio ช่วยให้คุณรวมไฟล์ไบนารีภายนอกหรือโมดูลไลบรารีอื่นๆ ไว้ในบิลด์ของคุณเป็น Dependency ได้ Dependency จะอยู่บนเครื่องหรือในรีโพซิทอรีระยะไกลก็ได้ และระบบจะรวม Dependency แบบทรานซิทีฟที่ประกาศไว้โดยอัตโนมัติด้วย หน้านี้อธิบายวิธีใช้ Dependency กับโปรเจ็กต์ Android รวมถึงรายละเอียดเกี่ยวกับลักษณะการทำงานและการกําหนดค่าเฉพาะสําหรับปลั๊กอิน Android Gradle (AGP) หากต้องการทราบแนวคิดเชิงลึกเกี่ยวกับข้อกำหนดของ Gradle คุณควรดูคู่มือ Gradle สำหรับการจัดการข้อกำหนดด้วย แต่โปรดทราบว่าโปรเจ็กต์ Android ต้องใช้เฉพาะการกำหนดค่าข้อกำหนดที่ระบุไว้ในหน้านี้
เพิ่มไลบรารีหรือพึ่งพาของปลั๊กอิน
วิธีที่ดีที่สุดในการเพิ่มและจัดการ Dependency ของบิลด์คือการใช้แคตตาล็อกเวอร์ชัน ซึ่งเป็นวิธีที่โปรเจ็กต์ใหม่ใช้โดยค่าเริ่มต้น ส่วนนี้จะกล่าวถึงการกำหนดค่าประเภทต่างๆ ที่พบบ่อยที่สุดซึ่งใช้สำหรับโปรเจ็กต์ Android โปรดดูตัวเลือกเพิ่มเติมในเอกสารประกอบของ Gradle ดูตัวอย่างแอปที่ใช้แคตตาล็อกเวอร์ชันได้ที่พร้อมใช้งานใน Android แล้ว หากคุณตั้งค่าทรัพยากร Dependency ของบิลด์ไว้แล้วโดยไม่มีแคตตาล็อกเวอร์ชัน และมีโปรเจ็กต์หลายโมดูล เราขอแนะนำให้ย้ายข้อมูล
ดูคําแนะนําเกี่ยวกับการเพิ่มและจัดการทรัพยากร Dependency เนทีฟ (ไม่พบบ่อย) ได้ที่หัวข้อทรัพยากร Dependency เนทีฟ
ในตัวอย่างต่อไปนี้ เราเพิ่มทรัพยากร Dependency ของไฟล์ไบนารีระยะไกล (คลัง Macrobenchmark ของ Jetpack), ทรัพยากร Dependency ของโมดูลไลบรารีในเครื่อง (myLibrary
) และทรัพยากร Dependency ของปลั๊กอิน (ปลั๊กอิน Android Gradle) ลงในโปรเจ็กต์ ขั้นตอนทั่วไปในการเพิ่มทรัพยากร Dependency เหล่านี้ลงในโปรเจ็กต์มีดังนี้
เพิ่มอีเมลแทนสำหรับเวอร์ชันของ Dependency ที่ต้องการในส่วน
[versions]
ของไฟล์แคตตาล็อกเวอร์ชันที่ชื่อlibs.versions.toml
(ในไดเรกทอรีgradle
ในมุมมองโปรเจ็กต์หรือสคริปต์ Gradle ในมุมมอง Android)[versions] agp = "8.3.0" androidx-macro-benchmark = "1.2.2" my-library = "1.4" [libraries] ... [plugins] ...
ชื่อแทนสามารถใส่ขีดกลางหรือขีดล่างได้ ตัวแฝงเหล่านี้จะสร้างค่าที่ฝังอยู่ซึ่งคุณอ้างอิงในสคริปต์การสร้างได้ การอ้างอิงจะขึ้นต้นด้วยชื่อแคตตาล็อก ซึ่งเป็นส่วน
libs
ของlibs.versions.toml
เมื่อใช้แคตตาล็อกเวอร์ชันเดียว เราขอแนะนำให้คงค่าเริ่มต้น "libs" ไว้เพิ่มอีเมลแทนสำหรับทรัพยากร ในส่วน
[libraries]
(สำหรับไบนารีระยะไกลหรือโมดูลไลบรารีในเครื่อง) หรือ[plugins]
(สำหรับปลั๊กอิน) ของไฟล์libs.versions.toml
[versions] ... [libraries] androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" } my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" } [plugins] androidApplication = { id = "com.android.application", version.ref = "agp" }
ไลบรารีบางรายการมีอยู่ในข้อมูลรายการวัสดุ (BOM) ที่เผยแพร่ซึ่งจัดกลุ่มไลบรารีและเวอร์ชันของไลบรารี คุณรวม BOM ในแคตตาล็อกเวอร์ชันและไฟล์บิลด์ได้ แล้วปล่อยให้ BOM จัดการเวอร์ชันเหล่านั้นให้คุณ ดูรายละเอียดได้ที่หัวข้อการใช้ใบรายการวัสดุ
เพิ่มการอ้างอิงถึงนามแฝงของการพึ่งพาลงในสคริปต์บิลด์ของข้อบังคับที่ต้องใช้การพึ่งพา แปลงขีดล่างและขีดกลางของอีเมลแทนที่ด้วยจุดเมื่อคุณอ้างอิงจากสคริปต์บิลด์ สคริปต์การบิลด์ระดับโมดูลของเราจะมีลักษณะดังนี้
Kotlin
plugins { alias(libs.plugins.androidApplication) } dependencies { implementation(libs.androidx.benchmark.macro) implementation(libs.my.library) }
Groovy
plugins { alias 'libs.plugins.androidApplication' } dependencies { implementation libs.androidx.benchmark.macro implementation libs.my.library }
การอ้างอิงปลั๊กอินจะมี
plugins
ต่อจากชื่อแคตตาล็อก และการอ้างอิงเวอร์ชันจะมีversions
ต่อจากชื่อแคตตาล็อก (การอ้างอิงเวอร์ชันไม่ค่อยพบบ่อยนัก โปรดดูตัวอย่างการอ้างอิงเวอร์ชันใน Dependency ที่มีหมายเลขเวอร์ชันเดียวกัน) การอ้างอิงไลบรารีไม่มีตัวระบุlibraries
คุณจึงใช้versions
หรือplugins
ขึ้นต้นชื่อแทนไลบรารีไม่ได้
กำหนดค่าทรัพยากร Dependency
ในบล็อก dependencies
คุณสามารถประกาศการพึ่งพาไลบรารีได้โดยใช้การกำหนดค่าการพึ่งพารูปแบบใดรูปแบบหนึ่ง (เช่น implementation
ที่แสดงก่อนหน้านี้) การกําหนดค่าการพึ่งพาแต่ละรายการจะให้คําแนะนําที่แตกต่างกันแก่ Gradle เกี่ยวกับวิธีใช้การพึ่งพา ตารางต่อไปนี้อธิบายการกำหนดค่าแต่ละรายการที่คุณใช้สำหรับทรัพยากร Dependency ในโปรเจ็กต์ Android ได้
การกำหนดค่า | ลักษณะการทำงาน |
---|---|
implementation |
Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์และแพ็กเกจการพึ่งพาไปยังเอาต์พุตการสร้าง เมื่อโมดูลกำหนดค่า implementation Dependency จะเป็นการแจ้งให้ Gradle ทราบว่าคุณไม่ต้องการให้โมดูลเปิดเผย Dependency ไปยังโมดูลอื่นๆ ในเวลาคอมไพล์ กล่าวคือ ทรัพยากร Dependency จะไม่พร้อมใช้งานกับโมดูลอื่นๆ ที่ขึ้นอยู่กับโมดูลปัจจุบัน
การใช้การกำหนดค่าทรัพยากร Dependency นี้แทน |
api |
Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์และเอาต์พุตการสร้าง เมื่อโมดูลมี api Dependency อยู่ แสดงว่าโมดูลดังกล่าวต้องการส่งออก Dependency นั้นไปยังโมดูลอื่นๆ แบบทรานซิทีฟ เพื่อให้โมดูลอื่นๆ ใช้งานได้ทั้งในช่วงรันไทม์และช่วงคอมไพล์
ใช้การกำหนดค่านี้อย่างระมัดระวังและใช้กับ Dependency ที่คุณจำเป็นต้องส่งออกไปยังผู้บริโภคต้นทางรายอื่นแบบทรานซิทีฟเท่านั้น หาก |
compileOnly |
Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์เท่านั้น (กล่าวคือ จะไม่เพิ่มลงในเอาต์พุตการสร้าง) ซึ่งจะมีประโยชน์เมื่อคุณสร้างโมดูล Android และต้องใช้ทรัพยากรในระหว่างการคอมไพล์ แต่คุณเลือกที่จะแสดงทรัพยากรดังกล่าวที่รันไทม์หรือไม่ก็ได้ ตัวอย่างเช่น หากคุณใช้ไลบรารีที่มีเฉพาะคำอธิบายประกอบเวลาคอมไพล์ ซึ่งโดยทั่วไปจะใช้ในการสร้างโค้ดแต่มักไม่รวมอยู่ในเอาต์พุตของบิลด์ คุณอาจทำเครื่องหมายไลบรารีนั้น compileOnly
หากคุณใช้การกำหนดค่านี้ โมดูลไลบรารีของคุณต้องมีเงื่อนไขรันไทม์เพื่อตรวจสอบว่ามีการพึ่งพาหรือไม่ จากนั้นเปลี่ยนลักษณะการทํางานเพื่อให้ยังคงทํางานได้หากไม่ได้ระบุ วิธีนี้ช่วยจํากัดขนาดของแอปสุดท้ายได้ด้วยการไม่เพิ่มการพึ่งพาชั่วคราวที่ไม่จําเป็น
หมายเหตุ: คุณใช้การกำหนดค่า |
runtimeOnly |
Gradle จะเพิ่มการพึ่งพาลงในเอาต์พุตการสร้างเท่านั้นเพื่อใช้ระหว่างรันไทม์ กล่าวคือ ไม่ได้เพิ่มลงใน classpath ของคอมไพล์
รูปแบบนี้ไม่ค่อยได้ใช้บน Android แต่มักใช้ในแอปพลิเคชันเซิร์ฟเวอร์เพื่อติดตั้งใช้งานการบันทึก เช่น ไลบรารีอาจใช้ API การบันทึกที่ไม่มีการติดตั้งใช้งาน ผู้ใช้งานไลบรารีดังกล่าวสามารถเพิ่มไลบรารีนั้นเป็นการพึ่งพา implementation และรวมการพึ่งพา runtimeOnly ไว้สําหรับการใช้งานการบันทึกจริง
|
ksp |
การกำหนดค่าเหล่านี้จัดหาไลบรารีที่ประมวลผลคำอธิบายประกอบและสัญลักษณ์อื่นๆ ในโค้ดของคุณก่อนที่จะคอมไพล์ โดยปกติแล้ว เครื่องมือเหล่านี้จะตรวจสอบโค้ดหรือสร้างโค้ดเพิ่มเติม ซึ่งจะช่วยลดโค้ดที่คุณจำเป็นต้องเขียน หากต้องการเพิ่มการพึ่งพาดังกล่าว คุณต้องเพิ่มลงในเส้นทางคลาสของโปรแกรมประมวลผลคำอธิบายประกอบโดยใช้การกำหนดค่า ปลั๊กอิน Android Gradle จะถือว่า Dependency เป็นตัวประมวลผลคำอธิบายประกอบหากไฟล์ JAR ของ Dependency นั้นๆ มีไฟล์ต่อไปนี้
หากพบเครื่องประมวลผลคำอธิบายประกอบที่อยู่ในเส้นทางคอมไพล์ ปลั๊กอินจะสร้างข้อผิดพลาดในการสร้าง
เมื่อตัดสินใจว่าจะใช้การกําหนดค่าใด ให้พิจารณาสิ่งต่อไปนี้
ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้ตัวประมวลผลคำอธิบายประกอบได้ที่เพิ่มตัวประมวลผลคำอธิบายประกอบ |
lintChecks |
ใช้การกําหนดค่านี้เพื่อรวมไลบรารีที่มีการตรวจสอบ Lint ที่คุณต้องการให้ Gradle เรียกใช้เมื่อสร้างโปรเจ็กต์แอป Android โปรดทราบว่า AAR ที่มีไฟล์ |
lintPublish |
ใช้การกำหนดค่านี้ในโปรเจ็กต์คลัง Android เพื่อรวมการตรวจสอบ Lint ที่ต้องการให้ Gradle คอมไพล์เป็นไฟล์ lint.jar และแพ็กเกจใน AAR ซึ่งจะทำให้โปรเจ็กต์ที่ใช้ AAR ของคุณใช้การตรวจสอบ Lint เหล่านั้นด้วย หากก่อนหน้านี้คุณใช้การกำหนดค่า lintChecks เพื่อรวมการตรวจสอบ Lint ไว้ใน AAR ที่เผยแพร่ คุณต้องย้ายข้อมูลการพึ่งพาเหล่านั้นเพื่อใช้การกำหนดค่า lintPublish แทน
Kotlindependencies { // Executes lint checks from the ":checks" project at build time. lintChecks(project(":checks")) // Compiles lint checks from the ":checks-to-publish" into a // lint.jar file and publishes it to your Android library. lintPublish(project(":checks-to-publish")) } Groovydependencies { // Executes lint checks from the ':checks' project at build time. lintChecks project(':checks') // Compiles lint checks from the ':checks-to-publish' into a // lint.jar file and publishes it to your Android library. lintPublish project(':checks-to-publish') } |
กำหนดค่าทรัพยากร Dependency สำหรับตัวแปรบิลด์ที่เฉพาะเจาะจง
การกําหนดค่าทั้งหมดก่อนหน้านี้จะใช้กับตัวแปรบิลด์ทั้งหมด หากต้องการประกาศการพึ่งพาสำหรับชุดแหล่งที่มาของตัวแปรบิลด์ที่เฉพาะเจาะจงหรือชุดแหล่งที่มาของการทดสอบแทน คุณต้องใส่อักษรตัวพิมพ์ใหญ่ในชื่อการกําหนดค่าและใส่ชื่อตัวแปรบิลด์หรือชุดแหล่งที่มาของการทดสอบไว้ข้างหน้า
เช่น หากต้องการเพิ่มทรัพยากร Dependency ของไบนารีระยะไกลเฉพาะกับเวอร์ชันผลิตภัณฑ์ "ฟรี" โดยใช้การกำหนดค่า implementation
ให้ใช้
Kotlin
dependencies { freeImplementation("com.google.firebase:firebase-ads:21.5.1") }
Groovy
dependencies { freeImplementation 'com.google.firebase:firebase-ads:21.5.1' }
อย่างไรก็ตาม หากต้องการเพิ่มข้อกําหนดของตัวแปรที่รวมรสชาติผลิตภัณฑ์และประเภทบิลด์ คุณต้องเริ่มต้นชื่อการกําหนดค่า ดังนี้
Kotlin
// Initializes a placeholder for the freeDebugImplementation dependency configuration. val freeDebugImplementation by configurations.creating dependencies { freeDebugImplementation(project(":free-support")) }
Groovy
configurations { // Initializes a placeholder for the freeDebugImplementation dependency configuration. freeDebugImplementation {} } dependencies { freeDebugImplementation project(":free-support") }
วิธีเพิ่ม implementation
Dependencies สําหรับการทดสอบในเครื่องและการทดสอบที่มีเครื่องมือวัดจะมีลักษณะดังนี้
Kotlin
dependencies { // Adds a remote binary dependency only for local tests. testImplementation("junit:junit:4.12") // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation("androidx.test.espresso:espresso-core:3.6.1") }
Groovy
dependencies { // Adds a remote binary dependency only for local tests. testImplementation 'junit:junit:4.12' // Adds a remote binary dependency only for the instrumented test APK. androidTestImplementation 'androidx.test.espresso:espresso-core:3.6.1' }
อย่างไรก็ตาม การกําหนดค่าบางอย่างไม่เหมาะสําหรับสถานการณ์นี้ ตัวอย่างเช่น เนื่องจากโมดูลอื่นๆ ไม่สามารถพึ่งพา androidTest
คุณจึงได้รับคำเตือนต่อไปนี้หากใช้การกำหนดค่า androidTestApi
WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with 'androidTestImplementation'.
ลำดับการขึ้นต่อกัน
ลำดับที่คุณแสดงรายการทรัพยากร จะเป็นตัวบ่งชี้ลำดับความสำคัญของแต่ละรายการ โดยคลังแรกจะมีลำดับความสำคัญสูงกว่าคลังที่สอง คลังที่สองจะมีลำดับความสำคัญสูงกว่าคลังที่สาม และต่อไปเรื่อยๆ ลำดับนี้มีความสำคัญในกรณีที่มีการผสานทรัพยากรหรือมีการรวมองค์ประกอบไฟล์ Manifest เข้ากับแอปจากไลบรารี
เช่น หากโปรเจ็กต์ประกาศสิ่งต่อไปนี้
- การพึ่งพา
LIB_A
และLIB_B
(ตามลำดับ) - และ
LIB_A
ขึ้นอยู่กับLIB_C
และLIB_D
(ตามลําดับดังกล่าว) - และ
LIB_B
ยังขึ้นอยู่กับLIB_C
ด้วย
ลำดับการขึ้นต่อกันแบบคงที่จะเป็นดังนี้
LIB_A
LIB_D
LIB_B
LIB_C
วิธีนี้ช่วยให้ทั้ง LIB_A
และ LIB_B
ลบล้าง LIB_C
ได้ และ LIB_D
ยังคงมีลําดับความสําคัญสูงกว่า LIB_B
เนื่องจาก LIB_A
(ซึ่งขึ้นอยู่กับ LIB_D
) มีลําดับความสําคัญสูงกว่า LIB_B
ดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีผสานไฟล์ Manifest จากแหล่งที่มา/ข้อกําหนดของโปรเจ็กต์ต่างๆ ได้ที่ผสานไฟล์ Manifest หลายไฟล์
ข้อมูลการขึ้นต่อกันสำหรับ Play Console
เมื่อสร้างแอป AGP จะรวมข้อมูลเมตาที่อธิบายทรัพยากร Dependency ของไลบรารีที่คอมไพล์ไว้ในแอปของคุณ เมื่ออัปโหลดแอป Play Console จะตรวจสอบข้อมูลเมตานี้เพื่อแจ้งเตือนปัญหาที่ทราบเกี่ยวกับ SDK และทรัพยากร Dependency ที่แอปของคุณใช้ และในบางกรณีจะให้ความคิดเห็นที่นําไปใช้แก้ปัญหาได้
ระบบจะบีบอัด เข้ารหัสด้วยคีย์การรับรองของ Google Play และจัดเก็บไว้ในบล็อกการรับรองของแอปรุ่น เราขอแนะนำให้เก็บไฟล์นี้ไว้เพื่อให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีและปลอดภัย คุณเลือกไม่ใช้ได้โดยการรวมบล็อก dependenciesInfo
ต่อไปนี้ในไฟล์ build.gradle.kts
ของโมดูล
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
ดูข้อมูลเพิ่มเติมเกี่ยวกับนโยบายและปัญหาที่อาจเกิดขึ้นกับ Dependency ได้ที่หน้าการสนับสนุนของเราเกี่ยวกับการใช้ SDK ของบุคคลที่สามในแอป
ข้อมูลเชิงลึกของ SDK
Android Studio จะแสดงคำเตือนเกี่ยวกับ Lint ในไฟล์แคตตาล็อกเวอร์ชันและกล่องโต้ตอบโครงสร้างโปรเจ็กต์สำหรับ SDK สาธารณะในดัชนี SDK ของ Google Play เมื่อมีปัญหาต่อไปนี้
- ผู้เขียนได้ทําเครื่องหมาย SDK ว่าล้าสมัย
- SDK ละเมิดนโยบายของ Play
คำเตือนเป็นสัญญาณที่คุณควรอัปเดตทรัพยากร Dependency เหล่านั้น เนื่องจากการใช้เวอร์ชันเก่าอาจทำให้คุณไม่สามารถเผยแพร่ไปยัง Google Play Console ได้ในอนาคต
เพิ่มการพึ่งพาบิลด์โดยไม่ใช้แคตตาล็อกเวอร์ชัน
เราขอแนะนำให้ใช้แคตตาล็อกเวอร์ชันเพื่อเพิ่มและจัดการการพึ่งพา แต่โปรเจ็กต์ง่ายๆ อาจไม่จําเป็นต้องใช้ ต่อไปนี้คือตัวอย่างของไฟล์บิลด์ที่ไม่ได้ใช้แคตตาล็อกเวอร์ชัน
Kotlin
plugins { id("com.android.application") } android { ... } dependencies { // Dependency on a remote binary implementation("com.example.android:app-magic:12.3") // Dependency on a local library module implementation(project(":mylibrary")) }
Groovy
plugins { id 'com.android.application' } android { ... } dependencies { // Dependency on a remote binary implementation 'com.example.android:app-magic:12.3' // Dependency on a local library module implementation project(':mylibrary') }
ไฟล์บิลด์นี้ประกาศการพึ่งพาไลบรารี "app-magic" เวอร์ชัน 12.3 ภายในกลุ่มเนมสเปซ "com.example.android" การประกาศการขึ้นต่อกันของไบนารีระยะไกลเป็นชื่อย่อสำหรับรายการต่อไปนี้
Kotlin
implementation(group = "com.example.android", name = "app-magic", version = "12.3")
Groovy
implementation group: 'com.example.android', name: 'app-magic', version: '12.3'
ไฟล์บิลด์ยังประกาศการพึ่งพาโมดูลไลบรารี Android ชื่อ "mylibrary" ด้วย โดยชื่อนี้ต้องตรงกับชื่อไลบรารีที่กําหนดด้วย include:
ในไฟล์ settings.gradle.kts
เมื่อคุณสร้างแอป ระบบบิลด์จะคอมไพล์โมดูลไลบรารีและแพ็กเกจเนื้อหาที่คอมไพล์แล้วไว้ในแอป
ไฟล์บิลด์จะประกาศการพึ่งพาปลั๊กอิน Gradle ของ Android (com.application.android
) ด้วย หากมีโมดูลหลายรายการที่ใช้ปลั๊กอินเดียวกัน คุณจะมีปลั๊กอินได้เพียงเวอร์ชันเดียวใน classpath ของบิลด์ในโมดูลทั้งหมด คุณควรระบุข้อกำหนดของพูลินในสคริปต์บิลด์รูทพร้อมเวอร์ชันและระบุว่าไม่ต้องใช้แทนการระบุเวอร์ชันในสคริปต์บิลด์ของโมดูลแต่ละรายการ การเพิ่ม apply false
จะบอกให้ Gradle บันทึกเวอร์ชันของปลั๊กอิน แต่ไม่ได้ใช้ปลั๊กอินนั้นในบิลด์รูท
โดยปกติแล้วสคริปต์บิลด์รูทจะว่างเปล่ายกเว้นบล็อก plugins
นี้
Kotlin
plugins { id("org.jetbrains.kotlin.android") version "1.9.0" apply false }
ดึงดูด
plugins { id ‘com.android.application’ version ‘8.3.0-rc02’ apply false }
หากมีโปรเจ็กต์โมดูลเดียว คุณสามารถระบุเวอร์ชันอย่างชัดเจนในสคริปต์บิลด์ระดับโมดูลและปล่อยสคริปต์บิลด์ระดับโปรเจ็กต์ว่างไว้ได้ ดังนี้
Kotlin
plugins { id("com.android.application") version "8.3.0" }
Groovy
plugins { id 'com.android.application' version '8.3.0-rc02' }