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

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

Android มีเฟรมเวิร์กแอปแบบไดนามิกเพื่อช่วยในการเข้ากันได้ของอุปกรณ์ ซึ่งคุณสามารถระบุทรัพยากรแอปเฉพาะสำหรับการกำหนดค่าในไฟล์แบบคงที่ เช่น เลย์เอาต์ XML แบบต่างๆ สำหรับหน้าจอขนาดต่างๆ จากนั้น Android จะโหลดทรัพยากรที่เหมาะสมตามการกำหนดค่าอุปกรณ์ปัจจุบัน ด้วย การออกแบบแอปและทรัพยากรเพิ่มเติมสำหรับแอปโดยเฉพาะ คุณก็สามารถเผยแพร่ Single Application Package (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() ดังนี้

KotlinJava

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

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

หมายเหตุ: สิทธิ์ของระบบบางอย่างจะกำหนดให้ฟีเจอร์ของอุปกรณ์พร้อมใช้งานโดยปริยาย ตัวอย่างเช่น หากแอปของคุณ ขอสิทธิ์ในการเข้าถึง BLUETOOTH ซึ่งโดยนัยจำเป็นต้องมี FEATURE_BLUETOOTH ฟีเจอร์ของอุปกรณ์ คุณสามารถปิดการใช้งานการกรองโดยอ้างอิงคุณลักษณะนี้ และ แอปของคุณพร้อมใช้งานสำหรับอุปกรณ์ที่ไม่มีบลูทูธโดยการตั้งค่า แอตทริบิวต์ required เป็น "false" ใน <uses-feature> ดูข้อมูลเพิ่มเติมเกี่ยวกับฟีเจอร์ของอุปกรณ์ที่จําเป็นโดยนัยได้ที่สิทธิ์ที่บอกเป็นนัยถึงข้อกําหนดของฟีเจอร์

รุ่นของแพลตฟอร์ม

อุปกรณ์ต่างๆ อาจใช้แพลตฟอร์ม 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)
        ...
    }
}

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 ที่ระบุไว้

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

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

KotlinJava

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

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 (พิเศษ) High), xxhdpi (สูงเป็นพิเศษ) และอื่นๆ

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

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

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

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

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

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

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

ภาพรวมแหล่งข้อมูลของแอป

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

ตัวกรองใน Google Play

ข้อมูลเกี่ยวกับวิธีต่างๆ ที่ Google Play Store สามารถป้องกันไม่ให้ ติดตั้งแอปบนอุปกรณ์อื่นๆ ไม่ได้

สิทธิ์ใน Android

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