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) ... } }
ดึงดูด
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 เหล่านั้นได้