เพิ่มการพึ่งพิงบิวด์

ระบบบิลด์ Gradle ใน Android Studio ช่วยให้คุณรวมไบนารีภายนอกหรือโมดูลไลบรารีอื่นๆ ไว้ในบิลด์ของคุณเป็น Dependency ได้ ไลบรารีดังกล่าวอาจอยู่ในเครื่องหรือในที่เก็บระยะไกล และระบบจะรวมไลบรารีที่เกี่ยวข้องทั้งหมดที่ประกาศไว้โดยอัตโนมัติด้วย หน้านี้อธิบายวิธีใช้ Dependency กับโปรเจ็กต์ Android รวมถึงรายละเอียดเกี่ยวกับลักษณะการทำงานและการกําหนดค่าเฉพาะสำหรับปลั๊กอิน Android Gradle (AGP) ดูคำแนะนำเชิงแนวคิดที่ละเอียดยิ่งขึ้นเกี่ยวกับ Dependency ของ Gradle ได้ที่คู่มือ Gradle สำหรับการจัดการ Dependency แต่โปรดทราบว่าโปรเจ็กต์ Android ต้องใช้เฉพาะการกำหนดค่า Dependency ที่ระบุไว้ในหน้านี้

เพิ่มไลบรารีหรือพึ่งพาของปลั๊กอิน

วิธีที่ดีที่สุดในการเพิ่มและจัดการ Dependency ของบิลด์คือการใช้แคตตาล็อกเวอร์ชัน ซึ่งเป็นวิธีที่โปรเจ็กต์ใหม่ใช้โดยค่าเริ่มต้น ส่วนนี้จะกล่าวถึงการกำหนดค่าประเภทต่างๆ ที่พบบ่อยที่สุดซึ่งใช้สำหรับโปรเจ็กต์ Android โปรดดูตัวเลือกเพิ่มเติมในเอกสารประกอบของ Gradle ดูตัวอย่างแอปที่ใช้แคตตาล็อกเวอร์ชันได้ที่พร้อมใช้งานใน Android แล้ว หากคุณตั้งค่าการพึ่งพาบิลด์ไว้แล้วโดยไม่มีแคตตาล็อกเวอร์ชันและมีโปรเจ็กต์หลายโมดูล เราขอแนะนำให้ย้ายข้อมูล

ดูคําแนะนําเกี่ยวกับการเพิ่มและจัดการทรัพยากร Dependency เนทีฟ (ไม่พบบ่อย) ได้ที่หัวข้อทรัพยากร Dependency เนทีฟ

ในตัวอย่างต่อไปนี้ เราเพิ่มทรัพยากร Dependency ของไฟล์ไบนารีระยะไกล (คลัง Macrobenchmark ของ Jetpack), ทรัพยากร Dependency ของโมดูลไลบรารีในเครื่อง (myLibrary) และทรัพยากร Dependency ของปลั๊กอิน (ปลั๊กอิน Android Gradle) ลงในโปรเจ็กต์ ขั้นตอนทั่วไปในการเพิ่มทรัพยากร Dependency เหล่านี้ลงในโปรเจ็กต์มีดังนี้

  1. เพิ่มอีเมลแทนสำหรับเวอร์ชันของ 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" ไว้เช่นเดิม

  2. เพิ่มอีเมลแทนสำหรับทรัพยากร ในส่วน [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 ในแคตตาล็อกเวอร์ชันและไฟล์บิลด์ แล้วให้ระบบจัดการเวอร์ชันเหล่านั้นให้คุณ ดูรายละเอียดได้ที่หัวข้อการใช้ใบรายการวัสดุ

  3. เพิ่มการอ้างอิงถึงแอลกอริทึมการพึ่งพาลงในสคริปต์บิลด์ของข้อบังคับที่ต้องใช้การพึ่งพา แปลงขีดล่างและขีดกลางของอีเมลแทนที่ด้วยจุดเมื่อคุณอ้างอิงจากสคริปต์บิลด์ สคริปต์การสร้างระดับโมดูลของเราจะมีลักษณะดังนี้

    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 เกี่ยวกับวิธีใช้การพึ่งพา ตารางต่อไปนี้อธิบายการกําหนดค่าแต่ละรายการที่คุณสามารถใช้กับทรัพยากรในโปรเจ็กต์ Android

การกำหนดค่า ลักษณะการทำงาน
implementation Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์และแพ็กเกจการพึ่งพาไปยังเอาต์พุตการสร้าง เมื่อโมดูลกำหนดค่า implementation Dependency จะเป็นการแจ้งให้ Gradle ทราบว่าคุณไม่ต้องการให้โมดูลเปิดเผย Dependency ไปยังโมดูลอื่นๆ ในเวลาคอมไพล์ กล่าวคือ โมดูลอื่นๆ ที่พึ่งพาโมดูลปัจจุบันจะใช้งานทรัพยากรดังกล่าวไม่ได้

การใช้การกำหนดค่านี้แทน api อาจส่งผลให้เวลาในการบิลด์ดีขึ้นอย่างมาก เนื่องจากจะลดจำนวนโมดูลที่ระบบบิลด์ต้องคอมไพล์อีกครั้ง ตัวอย่างเช่น หาก implementation Dependency เปลี่ยน API ของ Dependency นั้น Gradle จะคอมไพล์เฉพาะ Dependency นั้นและโมดูลที่ขึ้นอยู่กับ Dependency นั้นโดยตรงอีกครั้ง แอปและข้อบังคับการทดสอบส่วนใหญ่ควรใช้การกำหนดค่านี้

api Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์และเอาต์พุตการสร้าง เมื่อโมดูลมี api Dependency อยู่ แสดงว่าโมดูลดังกล่าวต้องการส่งออก Dependency นั้นไปยังโมดูลอื่นๆ แบบทรานซิทีฟ เพื่อให้โมดูลอื่นๆ ใช้งานได้ทั้งในช่วงรันไทม์และช่วงคอมไพล์

ใช้การกำหนดค่านี้อย่างระมัดระวังและใช้กับ Dependency ที่คุณจำเป็นต้องส่งออกไปยังผู้บริโภคต้นทางรายอื่นแบบทรานซิทีฟเท่านั้น หากapi Dependency เปลี่ยน API ภายนอก Gradle จะคอมไพล์โมดูลทั้งหมดที่มีสิทธิ์เข้าถึง Dependency นั้นอีกครั้งเมื่อคอมไพล์ การมีapi Dependency จํานวนมากอาจทําให้เวลาสร้างนานขึ้นอย่างมาก โมดูลไลบรารีควรใช้ Dependency implementation แทน เว้นแต่คุณจะต้องการแสดง API ของ Dependency ไปยังโมดูลแยกต่างหาก

compileOnly Gradle จะเพิ่มการพึ่งพาลงในเส้นทางคอมไพล์เท่านั้น (กล่าวคือจะไม่เพิ่มลงในเอาต์พุตการสร้าง) ซึ่งจะมีประโยชน์เมื่อคุณสร้างโมดูล Android และต้องใช้ทรัพยากรในระหว่างการคอมไพล์ แต่คุณเลือกที่จะแสดงทรัพยากรดังกล่าวได้เมื่อรันไทม์ ตัวอย่างเช่น หากคุณใช้ไลบรารีที่มีเฉพาะคำอธิบายประกอบเวลาคอมไพล์ ซึ่งโดยทั่วไปจะใช้ในการสร้างโค้ดแต่มักไม่รวมอยู่ในเอาต์พุตของบิลด์ คุณอาจทำเครื่องหมายไลบรารีนั้น compileOnly

หากคุณใช้การกำหนดค่านี้ โมดูลไลบรารีของคุณต้องมีเงื่อนไขรันไทม์เพื่อตรวจสอบว่ามีการพึ่งพาหรือไม่ จากนั้นเปลี่ยนลักษณะการทํางานเพื่อให้ยังคงทํางานได้หากไม่ได้ระบุ วิธีนี้ช่วยจํากัดขนาดของแอปสุดท้ายโดยไม่เพิ่มการพึ่งพาชั่วคราวที่ไม่จําเป็น

หมายเหตุ: คุณใช้การกำหนดค่า compileOnly กับ Dependency ของไฟล์เก็บถาวร Android (AAR) ไม่ได้

runtimeOnly Gradle จะเพิ่มการพึ่งพาลงในเอาต์พุตการสร้างเท่านั้นเพื่อใช้ระหว่างรันไทม์ กล่าวคือ ไม่ได้เพิ่มลงใน classpath ของคอมไพล์ รูปแบบนี้ไม่ค่อยได้ใช้บน Android แต่มักใช้ในแอปพลิเคชันเซิร์ฟเวอร์เพื่อติดตั้งใช้งานการบันทึก เช่น ไลบรารีอาจใช้ API การบันทึกที่ไม่มีการติดตั้งใช้งาน ผู้ใช้งานไลบรารีดังกล่าวสามารถเพิ่มไลบรารีนั้นเป็นการพึ่งพา implementation และรวมการพึ่งพา runtimeOnly ไว้สําหรับการใช้งานการบันทึกจริง
ksp
kapt
annotationProcessor

การกําหนดค่าเหล่านี้จะจัดหาไลบรารีที่ประมวลผลคําอธิบายประกอบและสัญลักษณ์อื่นๆ ในโค้ดก่อนที่จะคอมไพล์ โดยปกติแล้ว เครื่องมือเหล่านี้จะตรวจสอบโค้ดหรือสร้างโค้ดเพิ่มเติม ซึ่งจะช่วยลดโค้ดที่คุณจำเป็นต้องเขียน

หากต้องการเพิ่มการพึ่งพาดังกล่าว คุณต้องเพิ่มลงในเส้นทางคลาสของโปรแกรมประมวลผลคำอธิบายประกอบโดยใช้การกำหนดค่า ksp, kapt หรือ annotationProcessor การใช้การกําหนดค่าเหล่านี้จะช่วยปรับปรุงประสิทธิภาพการสร้างโดยแยก classpath ของคอมไพล์ออกจาก classpath ของโปรแกรมประมวลผลคําอธิบายประกอบ หาก Gradle พบตัวประมวลผลแอตทริบิวต์กำกับในเส้นทางการคอมไพล์ ระบบจะปิดใช้งาน การหลีกเลี่ยงการคอมไพล์ ซึ่งส่งผลเสียต่อเวลาสร้าง (Gradle 5.0 ขึ้นไปจะไม่สนใจตัวประมวลผลแอตทริบิวต์กำกับที่พบในเส้นทางการคอมไพล์)

ปลั๊กอิน Android Gradle จะถือว่า Dependency เป็นตัวประมวลผลคำอธิบายประกอบหากไฟล์ JAR ของ Dependency นั้นๆ มีไฟล์ต่อไปนี้

META-INF/services/javax.annotation.processing.Processor

หากพบเครื่องประมวลผลคำอธิบายประกอบที่อยู่ในเส้นทางคอมไพล์ ปลั๊กอินจะสร้างข้อผิดพลาดในการสร้าง

ksp เป็นผู้ประมวลผลสัญลักษณ์ Kotlin และทำงานโดยคอมไพเลอร์ Kotlin

kapt และ apt เป็นเครื่องมือแยกต่างหากที่ประมวลผลคำอธิบายประกอบก่อนที่คอมไพเลอร์ Kotlin หรือ Java จะทำงาน

เมื่อตัดสินใจว่าจะใช้การกําหนดค่าใด ให้พิจารณาสิ่งต่อไปนี้

  • หากตัวประมวลผลพร้อมใช้งานเป็นตัวประมวลผลสัญลักษณ์ Kotlin ให้ใช้เป็น ksp Dependency ดูรายละเอียดเกี่ยวกับการใช้โปรแกรมประมวลผลสัญลักษณ์ Kotlin ได้ที่หัวข้อย้ายข้อมูลจาก kapt ไปยัง ksp
  • หากตัวประมวลผลไม่พร้อมใช้งานในฐานะตัวประมวลผลสัญลักษณ์ Kotlin ให้ทำดังนี้
    • หากโปรเจ็กต์มีซอร์สโค้ด Kotlin (แต่รวมซอร์สโค้ด Java ได้ด้วย) ให้ใช้ kapt เพื่อรวมซอร์สโค้ด
    • หากโปรเจ็กต์ใช้เฉพาะซอร์สโค้ด Java ให้ใช้ annotationProcessor เพื่อรวมซอร์สโค้ดนั้น

ดูข้อมูลเพิ่มเติมเกี่ยวกับการใช้โปรแกรมประมวลผลคำอธิบายประกอบได้ที่เพิ่มโปรแกรมประมวลผลคำอธิบายประกอบ

lintChecks

ใช้การกําหนดค่านี้เพื่อรวมไลบรารีที่มีการตรวจสอบ Lint ที่คุณต้องการให้ Gradle เรียกใช้เมื่อสร้างโปรเจ็กต์แอป Android

โปรดทราบว่า AAR ที่มีไฟล์ lint.jar จะเรียกใช้การตรวจสอบที่ระบุไว้ในไฟล์ lint.jar นั้นโดยอัตโนมัติ คุณจึงไม่ต้องเพิ่มการพึ่งพา lintChecks อย่างชัดแจ้ง ซึ่งจะช่วยให้คุณกำหนดไลบรารีและการตรวจสอบ Lint ที่เกี่ยวข้องได้ในข้อกำหนดเพียงรายการเดียว เพื่อให้มั่นใจว่าการตรวจสอบจะทำงานเมื่อผู้ใช้ใช้ไลบรารีของคุณ

lintPublish ใช้การกำหนดค่านี้ในโปรเจ็กต์คลัง Android เพื่อรวมการตรวจสอบ Lint ที่ต้องการให้ Gradle คอมไพล์เป็นไฟล์ lint.jar และแพ็กเกจใน AAR ซึ่งจะทำให้โปรเจ็กต์ที่ใช้ AAR ของคุณใช้การตรวจสอบ Lint เหล่านั้นด้วย หากก่อนหน้านี้คุณใช้การกำหนดค่า lintChecks ของทรัพยากรภายนอกเพื่อรวมการตรวจสอบ Lint ไว้ใน AAR ที่เผยแพร่ คุณต้องย้ายข้อมูลทรัพยากรภายนอกเหล่านั้นเพื่อใช้การกำหนดค่า lintPublish แทน

Kotlin

dependencies {
  // 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"))
}

Groovy

dependencies {
  // 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')
}

กำหนดค่าการพึ่งพาสำหรับตัวแปรของบิวด์ที่เฉพาะเจาะจง

การกําหนดค่าทั้งหมดก่อนหน้านี้จะใช้กับตัวแปรบิลด์ทั้งหมด หากต้องการประกาศการพึ่งพาสำหรับชุดแหล่งที่มาของตัวแปรบิลด์ที่เฉพาะเจาะจงหรือชุดแหล่งที่มาของการทดสอบแทน คุณต้องใส่อักษรตัวพิมพ์ใหญ่ในชื่อการกําหนดค่าและใส่ชื่อตัวแปรบิลด์หรือชุดแหล่งที่มาของการทดสอบไว้ข้างหน้า

เช่น หากต้องการเพิ่มข้อกำหนดเบื้องต้นของไบนารีระยะไกลลงในตัวแปรผลิตภัณฑ์ "ฟรี" เท่านั้นโดยใช้การกำหนดค่า implementation ให้ใช้คำสั่งนี้

Kotlin

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

Groovy

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

อย่างไรก็ตาม หากต้องการเพิ่มข้อกําหนดของตัวแปรที่รวม Flavor ผลิตภัณฑ์และประเภทบิลด์ คุณต้องเริ่มต้นชื่อการกําหนดค่า ดังนี้

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 ด้วย

จากนั้นลําดับความเกี่ยวข้องแบบคงที่จะเป็นดังนี้

  1. LIB_A
  2. LIB_D
  3. LIB_B
  4. 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

คำเตือนเป็นสัญญาณว่าคุณควรอัปเดตไลบรารีเหล่านั้น เนื่องจากการใช้เวอร์ชันที่ล้าสมัยอาจทำให้คุณเผยแพร่ไปยัง 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) ด้วย หากมีโมดูลหลายรายการที่ใช้ปลั๊กอินเดียวกัน คุณจะมีปลั๊กอินได้เพียงเวอร์ชันเดียวในคลาสพาธการบิลด์ของโมดูลทั้งหมด คุณควรระบุข้อกำหนดของพูลินในสคริปต์บิลด์รูทพร้อมเวอร์ชันและระบุว่าไม่ต้องใช้แทนการระบุเวอร์ชันในสคริปต์บิลด์ของโมดูลแต่ละรายการ การเพิ่ม apply false จะบอกให้ Gradle บันทึกเวอร์ชันของปลั๊กอิน แต่ไม่ได้ใช้ปลั๊กอินนั้นในบิลด์รูท โดยปกติแล้วสคริปต์บิลด์รูทจะว่างเปล่ายกเว้นบล็อก plugins นี้

Kotlin

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

Groovy

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'
}