ภาพรวมความเข้ากันได้ของอุปกรณ์

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

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

อย่างไรก็ตาม คุณสามารถระบุข้อกำหนดของฟีเจอร์แอปและควบคุมประเภทอุปกรณ์ที่สามารถติดตั้งแอปของคุณจาก Google Play Store ได้หากจำเป็น เอกสารนี้อธิบายวิธีควบคุมอุปกรณ์ที่มีสิทธิ์เข้าถึงแอปของคุณและวิธีเตรียมแอปให้เข้าถึงกลุ่มเป้าหมายที่เหมาะสม

"ความเข้ากันได้" หมายถึงอะไร

ในส่วนของการพัฒนาแอป Android นั้น ความเข้ากันได้มี 2 ประเภท ได้แก่ ความเข้ากันได้กับอุปกรณ์และ ความเข้ากันได้กับแอป

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

ในฐานะนักพัฒนาแอป คุณไม่จำเป็นต้องกังวลว่าอุปกรณ์จะเข้ากันได้กับ Android หรือไม่ เนื่องจากมีเพียงอุปกรณ์ที่เข้ากันได้กับ Android เท่านั้นที่จะมี Google Play Store ดังนั้น หากผู้ใช้ติดตั้งแอปของคุณจาก Google Play Store แสดงว่าผู้ใช้กำลังใช้อุปกรณ์ที่เข้ากันได้กับ Android

อย่างไรก็ตาม คุณต้องพิจารณาว่าแอปของคุณเข้ากันได้กับการกำหนดค่าอุปกรณ์ที่อาจเกิดขึ้นแต่ละรายการหรือไม่ เนื่องจาก Android ทำงานในการกำหนดค่าอุปกรณ์ที่หลากหลาย ฟีเจอร์บางอย่างจึงไม่พร้อมใช้งานในอุปกรณ์บางเครื่อง ตัวอย่างเช่น อุปกรณ์บางชนิดอาจไม่มีเซ็นเซอร์เข็มทิศ ดังนั้น หากฟังก์ชันหลักของแอปต้องใช้เซ็นเซอร์เข็มทิศ แอปก็จะเข้ากันได้กับอุปกรณ์ที่มีฟีเจอร์ดังกล่าวเท่านั้น

ควบคุมความพร้อมใช้งานของแอปในอุปกรณ์

Android รองรับฟีเจอร์หลากหลายประเภทที่แอปของคุณใช้ประโยชน์ได้ผ่าน API ของแพลตฟอร์ม ฟีเจอร์บางอย่างอิงตามฮาร์ดแวร์ เช่น เซ็นเซอร์เข็มทิศ บางอย่างอิงตามซอฟต์แวร์ เช่น วิดเจ็ตของแอป และบางอย่างขึ้นอยู่กับเวอร์ชันของแพลตฟอร์ม อุปกรณ์บางเครื่องอาจไม่รองรับทุกฟีเจอร์ ดังนั้นคุณอาจต้องควบคุมความพร้อมใช้งานของแอปในอุปกรณ์ตามฟีเจอร์ที่แอปต้องใช้

หากต้องการให้แอปมีฐานผู้ใช้ที่ใหญ่ที่สุดเท่าที่จะเป็นไปได้ ให้รองรับการกำหนดค่าอุปกรณ์ให้มากที่สุดเท่าที่จะทำได้โดยใช้ APK หรือ AAB เดียว ในสถานการณ์ส่วนใหญ่ คุณสามารถทำได้โดยการปิดใช้ฟีเจอร์ที่ไม่บังคับขณะรันไทม์และ ระบุทรัพยากรแอป ที่มีตัวเลือกอื่นสำหรับการกำหนดค่าต่างๆ เช่น เลย์เอาต์ที่แตกต่างกันสำหรับหน้าจอขนาดต่างๆ หากจำเป็น คุณสามารถจำกัดความพร้อมใช้งานของแอปในอุปกรณ์บางเครื่องผ่าน Google Play Store ตามลักษณะของอุปกรณ์ต่อไปนี้

ฟีเจอร์ของอุปกรณ์

Android กำหนด รหัสฟีเจอร์สำหรับฟีเจอร์ฮาร์ดแวร์หรือซอฟต์แวร์ใดๆ ที่อาจไม่พร้อมใช้งานในอุปกรณ์บางเครื่อง เพื่อจัดการความพร้อมใช้งานของแอปตามฟีเจอร์ของอุปกรณ์ ตัวอย่างเช่น รหัสฟีเจอร์สำหรับเซ็นเซอร์เข็มทิศคือ FEATURE_SENSOR_COMPASS และรหัสฟีเจอร์สำหรับวิดเจ็ตของแอปคือ FEATURE_APP_WIDGETS

หากจำเป็น คุณสามารถป้องกันไม่ให้ผู้ใช้ติดตั้งแอปเมื่ออุปกรณ์ไม่มีฟีเจอร์ที่จำเป็นได้โดยการประกาศฟีเจอร์โดยใช้ <uses-feature> ในไฟล์ Manifest ของแอป

ตัวอย่างเช่น หากแอปของคุณไม่สมเหตุสมผลที่จะทำงานในอุปกรณ์ที่ไม่มีเซ็นเซอร์เข็มทิศ คุณสามารถประกาศให้เซ็นเซอร์เข็มทิศเป็นข้อกำหนดได้ด้วยแท็ก Manifest ต่อไปนี้

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

Google Play Store จะเปรียบเทียบฟีเจอร์ที่แอปต้องใช้กับฟีเจอร์ที่พร้อมใช้งานในอุปกรณ์ของผู้ใช้แต่ละรายเพื่อพิจารณาว่าแอปของคุณเข้ากันได้กับอุปกรณ์แต่ละเครื่องหรือไม่ หากอุปกรณ์ไม่มีฟีเจอร์ทั้งหมดที่แอปต้องใช้ ผู้ใช้จะติดตั้งแอปของคุณไม่ได้

อย่างไรก็ตาม หากฟังก์ชันหลักของแอป ไม่จำเป็นต้องใช้ฟีเจอร์ของ อุปกรณ์ ให้ตั้งค่า required แอตทริบิวต์เป็น "false" และตรวจสอบฟีเจอร์ของอุปกรณ์ขณะรันไทม์ หากฟีเจอร์ของแอปไม่พร้อมใช้งานในอุปกรณ์ปัจจุบัน ให้ลดระดับฟีเจอร์ของแอปที่เกี่ยวข้องอย่างค่อยเป็นค่อยไป ตัวอย่างเช่น คุณสามารถค้นหาว่าฟีเจอร์พร้อมใช้งานหรือไม่โดยเรียกใช้ hasSystemFeature() ดังนี้

Kotlin

if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature()
}

Java

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature();
}

ดูข้อมูลเกี่ยวกับตัวกรองทั้งหมดที่คุณใช้เพื่อควบคุมความพร้อมใช้งาน ของแอปผ่าน Google Play Store ได้ที่ เอกสารประกอบตัวกรองใน Google Play

เวอร์ชันของแพลตฟอร์ม

อุปกรณ์ต่างๆ อาจใช้แพลตฟอร์ม Android เวอร์ชันต่างๆ เช่น Android 12 หรือ Android 13 แพลตฟอร์มเวอร์ชันต่อๆ มามักจะเพิ่ม API ที่ไม่มีในเวอร์ชันก่อนหน้า แพลตฟอร์มเวอร์ชันแต่ละเวอร์ชันจะระบุ ระดับ API เพื่อบ่งบอกว่ามี API ชุดใดบ้างที่พร้อมใช้งาน ตัวอย่างเช่น Android 12 คือ ระดับ API 31 และ Android 13 คือ ระดับ API 33

คุณต้องระบุค่า minSdkVersion และ targetSdkVersion ในไฟล์ build.gradle ดังนี้

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(30)

        // Specifies the API level used to test the app.
        targetSdkVersion(36)
        ...
    }
}

ดึงดูด

android {
    defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 30

        // Specifies the API level used to test the app.
        targetSdkVersion 36
        ...
    }
}

ดูข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ build.gradle ได้ที่ กำหนดค่าบิลด์

Android เวอร์ชันต่อๆ มาแต่ละเวอร์ชันจะมีความเข้ากันได้กับแอปที่สร้างขึ้นโดยใช้ API จากแพลตฟอร์มเวอร์ชันก่อนหน้า ดังนั้นแอปของคุณจึงเข้ากันได้กับ Android เวอร์ชันต่อๆ ไปขณะที่ใช้ Android API ที่มีเอกสารประกอบ

อย่างไรก็ตาม หากแอปใช้ API ที่เพิ่มเข้ามาในแพลตฟอร์มเวอร์ชันล่าสุด แต่ไม่จำเป็นต้องใช้ API เหล่านั้นสำหรับฟังก์ชันหลัก ให้ตรวจสอบระดับ API ขณะรันไทม์และลดระดับฟีเจอร์ที่เกี่ยวข้องอย่างค่อยเป็นค่อยไปเมื่อระดับ API ต่ำเกินไป ในกรณีนี้ ให้ตั้งค่า minSdkVersion เป็นค่าต่ำที่สุดเท่าที่จะเป็นไปได้สำหรับฟังก์ชันหลักของแอป จากนั้นเปรียบเทียบเวอร์ชันของระบบปัจจุบัน SDK_INT กับค่าคงที่ของชื่อเวอร์ชันใน Build.VERSION_CODES ที่สอดคล้องกับระดับ API ที่คุณต้องการตรวจสอบ ดังที่แสดงในตัวอย่างต่อไปนี้

Kotlin

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop()
}

Java

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop();
}

การกำหนดค่าหน้าจอ

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

  • ขนาดทั่วไป 4 ขนาด ได้แก่ เล็ก ปกติ ใหญ่ และใหญ่พิเศษ
  • ความหนาแน่นทั่วไปหลายระดับ ได้แก่ mdpi (ปานกลาง), hdpi (สูง), xhdpi (สูง พิเศษ), xxhdpi (สูงพิเศษขึ้นไป) และอื่นๆ

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

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

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

ควบคุมความพร้อมใช้งานของแอปด้วยเหตุผลทางธุรกิจ

นอกเหนือจากการจำกัดความพร้อมใช้งานของแอปตามลักษณะของอุปกรณ์แล้ว คุณอาจต้องจำกัดความพร้อมใช้งานของแอปด้วยเหตุผลทางธุรกิจหรือทางกฎหมาย สำหรับสถานการณ์ประเภทนี้ Google Play Store มีตัวเลือกการกรองใน Play Console ที่ช่วยให้คุณควบคุมความพร้อมใช้งานของแอปด้วยเหตุผลที่ไม่ใช่ทางเทคนิค เช่น ภาษาของผู้ใช้หรือผู้ให้บริการเครือข่ายไร้สาย

การกรองเพื่อความเข้ากันได้ทางเทคนิค เช่น ส่วนประกอบฮาร์ดแวร์ที่จำเป็น จะอิงตามข้อมูลที่อยู่ในไฟล์ APK หรือ AAB เสมอ แต่การกรองด้วยเหตุผลที่ไม่ใช่ทางเทคนิค เช่น ภาษาทางภูมิศาสตร์ จะจัดการใน Google Play Console เสมอ

แหล่งข้อมูลเพิ่มเติม:

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