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

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(33)
        ...
    }
}

Groovy

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 33
        ...
    }
}

ดูข้อมูลเพิ่มเติมเกี่ยวกับไฟล์ 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 เหล่านั้นได้