หากคุณเผยแพร่แอปใน Google Play คุณควรสร้างและอัปโหลด Android App Bundle เมื่อดำเนินการนี้ Google Play จะดำเนินการดังกล่าวโดยอัตโนมัติ สร้างและแสดง APK ที่เพิ่มประสิทธิภาพสำหรับการกำหนดค่าอุปกรณ์ของผู้ใช้แต่ละราย เพื่อให้ดาวน์โหลดได้เฉพาะ โค้ดและทรัพยากรที่จำเป็นต่อการเรียกใช้แอป การเผยแพร่ APK หลายรายการมีประโยชน์ในกรณีที่คุณ ไม่เผยแพร่ไปยัง Google Play แต่คุณต้องสร้าง รับรอง และจัดการ APK แต่ละรายการด้วยตนเอง
เมื่อพัฒนาแอปพลิเคชัน Android เพื่อใช้ประโยชน์จาก APK หลายรายการบน Google Play ก็เป็นสิ่งสำคัญที่จะใช้แนวทางปฏิบัติที่ดีตั้งแต่เริ่มต้น และป้องกันอาการปวดศีรษะโดยไม่จำเป็น ต่อไปในกระบวนการพัฒนา บทเรียนนี้แสดงวิธีสร้าง APK หลายรายการ โดยแต่ละแอปก็ครอบคลุมขนาดหน้าจอที่ต่างกัน และคุณยังจะได้รับเครื่องมือบางอย่างที่จำเป็นในการ ทำให้การดูแลโค้ดเบส APK หลายๆ ตัวเป็นเรื่องง่ายที่สุด
ยืนยันว่าคุณต้องมี APK หลายรายการ
เมื่อพยายามสร้างแอปพลิเคชันที่ทำงานได้บนอุปกรณ์ Android มากมายที่มีให้บริการ โดยทั่วไปแล้วคุณต้องการให้แอปพลิเคชันของคุณดูดีที่สุดบนอุปกรณ์แต่ละเครื่อง คุณต้องการ ใช้ประโยชน์จากพื้นที่ของหน้าจอขนาดใหญ่แต่ยังคงใช้งานกับหน้าจอขนาดเล็กได้ เพื่อใช้ Android API ใหม่ คุณลักษณะหรือพื้นผิวที่เป็นภาพซึ่งพร้อมใช้งานบนอุปกรณ์ที่ล้ำสมัย แต่ไม่ละทิ้งอุปกรณ์รุ่นเก่าๆ อาจ ดูเหมือนจะเป็นโซลูชันที่ดีที่สุดตั้งแต่เริ่มรองรับ APK หลายตัว แต่นี่ไม่ใช่ ส่วนการใช้ APK เดียวแทนของคู่มือ APK หลายรายการมีข้อมูลที่เป็นประโยชน์เกี่ยวกับวิธีดำเนินการทั้งหมดนี้ด้วย APK เดียว ซึ่งรวมถึงการใช้ไลบรารีสนับสนุนของเรา และลิงก์ไปยังแหล่งข้อมูลต่างๆ ในคู่มือนักพัฒนาแอป Android
หากคุณจัดการได้ การจำกัดแอปพลิเคชันของคุณให้อยู่ใน APK เดียวมีข้อดีหลายประการ ซึ่งรวมถึง
- การเผยแพร่และการทดสอบทำได้ง่ายขึ้น
- มีฐานโค้ดเพียงชุดเดียวที่ต้องดูแลรักษา
- แอปพลิเคชันของคุณสามารถปรับให้เข้ากับการเปลี่ยนแปลงการกำหนดค่าอุปกรณ์
- การคืนค่าแอปในอุปกรณ์ต่างๆ ใช้งานได้ปกติ
- คุณไม่ต้องกังวลเกี่ยวกับความต้องการของตลาด ลักษณะการทํางานจากการ "อัปเกรด" จาก APK หนึ่งไปยังอีก APK หนึ่ง หรือ APK ใดเหมาะกับอุปกรณ์ระดับใด
ส่วนที่เหลือของบทเรียนนี้จะถือว่าคุณได้ศึกษาหัวข้อดังกล่าวและซึมซับแนวคิด ในแหล่งข้อมูลที่เชื่อมโยง และระบุว่า APK หลายรายการเป็นวิธีที่เหมาะสมสำหรับ แอปพลิเคชัน
ทำแผนภูมิข้อกำหนดของคุณ
เริ่มด้วยการสร้างแผนภูมิง่ายๆ เพื่อตรวจสอบจำนวน APK ที่ต้องการ และหน้าจอที่ต้องการ ขนาดที่แต่ละ APK ครอบคลุม โชคดีที่คุณสามารถร่างข้อมูลความต้องการของคุณได้อย่างรวดเร็ว ง่ายดาย และ มีข้อมูลอ้างอิงได้ง่ายๆ สำหรับใช้ภายหลัง สมมติว่าคุณต้องการแบ่ง APK ออกเป็น 2 มิติ API และขนาดหน้าจอ สร้างตารางที่มีแถวและคอลัมน์สำหรับค่าและสีที่เป็นไปได้แต่ละคู่ ใน "BLOB" บางรายการ แต่ละสีจะแทน APK 1 รายการ
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
เล็ก | |||||||||||
ปกติ | |||||||||||
ใหญ่ | |||||||||||
xlarge |
ด้านบนคือตัวอย่างที่มี APK 4 รายการ สีน้ำเงินหมายถึงอุปกรณ์ที่มีหน้าจอขนาดเล็ก/ปกติทั่วไป ส่วนสีเขียวหมายถึงอุปกรณ์ขนาดใหญ่ สำหรับอุปกรณ์หน้าจอ และสีแดงมีไว้สำหรับอุปกรณ์ที่มีหน้าจอขนาดใหญ่ ทั้งหมดจะมี API ตั้งแต่ 3-10 อุปกรณ์ สีม่วงคือ เป็นกรณีพิเศษ เพราะมีไว้สำหรับหน้าจอทุกขนาด แต่มีไว้สำหรับ API 11 ขึ้นไปเท่านั้น ที่สำคัญกว่านั้นคือ เมื่อดูที่แผนภูมินี้ คุณจะทราบได้ทันทีว่า APK ใดครอบคลุม API/ขนาดหน้าจอ ถึง Boot ของคุณก็มีชื่อรหัส! สำหรับแต่ละชื่อเพราะ "เราได้ทดสอบสีแดงบน ?" แล้ว มาก การถามลูกของคุณง่ายกว่า "เราได้ทดสอบ APK ขนาดใหญ่ 3 ถึง 10 กับ Xoom แล้วหรือยัง" พิมพ์เอกสารนี้ และมอบให้กับคนที่ทำงานกับโค้ดเบสของคุณ ชีวิตง่ายขึ้นมาก
ใส่โค้ดและทรัพยากรทั่วไปทั้งหมดไว้ในโปรเจ็กต์ไลบรารี
ไม่ว่าคุณจะปรับเปลี่ยนแอปพลิเคชัน Android ที่มีอยู่ หรือเริ่มต้นแอปพลิเคชันใหม่ตั้งแต่ต้น สิ่งแรกที่คุณควรทำกับฐานของโค้ด และสิ่งสำคัญที่สุดคือ ทุกอย่างที่รวมอยู่ในโปรเจ็กต์ไลบรารีต้องอัปเดตเพียงครั้งเดียว (เช่น สตริงที่แปลเป็นภาษาท้องถิ่น ธีมสี ข้อบกพร่องที่แก้ไขแล้วในโค้ดที่แชร์) ซึ่งจะช่วยประหยัดเวลาในการพัฒนาและลดโอกาสที่จะเกิดข้อผิดพลาดที่หลีกเลี่ยงได้ง่ายๆ
หมายเหตุ: แม้ว่ารายละเอียดการใช้งานเกี่ยวกับวิธีสร้างและรวมโปรเจ็กต์ไลบรารีจะอยู่นอกขอบเขตของบทเรียนนี้ แต่คุณสามารถทบทวนข้อมูลได้โดยอ่านหัวข้อสร้างไลบรารี Android
หากคุณจะแปลงแอปพลิเคชันที่มีอยู่ ไปใช้การรองรับ APK หลายไฟล์ เสาะหาโค้ดเบสสำหรับทุกไฟล์สตริงที่แปลแล้ว รายการค่า และธีม สี ไอคอนเมนู และเลย์เอาต์ที่จะไม่เปลี่ยนไปใน APK ต่างๆ และ ทั้งหมดไว้ในโครงการห้องสมุด โค้ดที่จะไม่เปลี่ยนแปลงมากนัก ไปในโครงการห้องสมุดด้วย คุณอาจพบว่าตัวเองขยายระยะเวลาเหล่านี้ เพื่อเพิ่มเมธอดจาก APK ไปยัง APK หนึ่งหรือสองเมธอด
ในทางกลับกัน หากคุณกำลังสร้างแอปพลิเคชันใหม่ตั้งแต่ต้น ให้ลองใช้ ให้เขียนโค้ดที่สุดในโครงการไลบรารีก่อน จากนั้นเลื่อนลงไปด้านล่าง APK แต่ละรายการหากจำเป็น วิธีนี้ง่ายมากในระยะยาว แทนที่จะเพิ่มไว้แค่บัญชีเดียว แล้วก็อีก แล้วก็ลองอีกที จากนั้นก็หลายเดือนต่อมาเพื่อดูว่าจะเลื่อน BLOB นี้ขึ้นได้ไหม ส่วนห้องสมุดได้โดยไม่ต้องทำอะไรให้ยุ่งยาก
สร้างโปรเจ็กต์ APK ใหม่
คุณควรมีโปรเจ็กต์ Android แยกต่างหากสำหรับ APK แต่ละรายการที่จะเผยแพร่ จัดระเบียบโปรเจ็กต์ไลบรารีและโปรเจ็กต์ APK ที่เกี่ยวข้องทั้งหมดไว้ในโฟลเดอร์หลักเดียวกันเพื่อให้จัดระเบียบได้ง่าย นอกจากนี้ โปรดทราบว่า APK แต่ละรายการต้องมีชื่อแพ็กเกจเดียวกัน แม้ว่าจะไม่ได้บังคับก็ตาม จำเป็นต้องแชร์ชื่อแพ็กเกจกับไลบรารี หากคุณจะมี APK 3 รายการตามรูปแบบดังกล่าว ที่อธิบายไว้ก่อนหน้านี้ ไดเรกทอรีรากอาจมีลักษณะดังนี้
alexlucas:~/code/multi-apks-root$ ls foo-blue foo-green foo-lib foo-purple foo-red
เมื่อสร้างโปรเจ็กต์แล้ว ให้เพิ่มโปรเจ็กต์ไลบรารีเป็นการอ้างอิงไปยังโปรเจ็กต์ APK แต่ละโปรเจ็กต์ ถ้า ให้กำหนดกิจกรรมเริ่มต้นในโปรเจ็กต์ไลบรารี และขยายกิจกรรมนั้นใน APK ของคุณ การมีการกำหนดกิจกรรมเริ่มต้นในโครงการไลบรารีทำให้คุณสามารถใส่ การเริ่มต้นแอปพลิเคชันของคุณในที่เดียว เพื่อให้ APK แต่ละรายการไม่ต้อง นำ "สากล" มาใช้ใหม่ เช่น การเริ่มต้น Analytics การตรวจสอบการอนุญาตให้ใช้สิทธิ ขั้นตอนการเริ่มต้นใช้งานที่ไม่ค่อยมีการเปลี่ยนแปลงจาก APK ไปเป็น APK
ปรับไฟล์ Manifest
เมื่อผู้ใช้ดาวน์โหลดแอปพลิเคชันที่ใช้ APK หลายรายการผ่าน Google Play APK ที่จะใช้นั้นได้รับเลือกโดยใช้กฎง่ายๆ 2 ข้อดังนี้
- ไฟล์ Manifest ต้องแสดงให้เห็นว่า APK นั้นๆ มีสิทธิ์
- จาก APK ที่มีสิทธิ์ จำนวนเวอร์ชันสูงสุดจะชนะ
ตัวอย่างเช่น มาดูชุด APK หลายรายการที่อธิบายไว้ก่อนหน้านี้และสมมติว่า APK แต่ละรายการได้รับการตั้งค่าให้รองรับหน้าจอทุกขนาดที่ใหญ่กว่าขนาดหน้าจอ "เป้าหมาย" ของแอป มาดูตัวอย่างแผนภูมิจากก่อนหน้านี้กัน
3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
เล็ก | |||||||||||
ปกติ | |||||||||||
ใหญ่ | |||||||||||
xlarge |
เนื่องจากความครอบคลุมทับซ้อนกันได้ เราจึงอธิบายพื้นที่ที่ครอบคลุมโดย APK แต่ละรายการได้ดังนี้
- สีน้ำเงินครอบคลุมทุกหน้าจอ, minSDK 3.
- สีเขียวครอบคลุมหน้าจอขนาดใหญ่และสูงกว่า minSDK 3
- สีแดงครอบคลุมหน้าจอขนาดใหญ่พิเศษ (โดยทั่วไปคือแท็บเล็ต), minSDK ขนาด 9
- สีม่วงครอบคลุมทุกหน้าจอ, minSDK เท่ากับ 11
โปรดทราบว่ามีกฎเหล่านั้นซ้อนทับกันจำนวนมาก ตัวอย่างเช่น อุปกรณ์ขนาด XLarge ที่มี API 11 สามารถเรียกใช้ APK ใดก็ได้ 1 ใน 4 รายการที่ระบุ แต่หากใช้ "จำนวนเวอร์ชันสูงสุดจะชนะ" เราสามารถตั้งค่าลำดับของ ดังนี้
ม่วง ≥ แดง ≥ เขียว ≥ น้ำเงิน
ทำไมอนุญาตให้มีการซ้อนทับทั้งหมด สมมติว่า APK สีม่วงมีข้อกำหนดบางอย่างที่อีก 2 รายการไม่มี หน้าตัวกรองใน Google Play ในคู่มือนักพัฒนาซอฟต์แวร์ Android ก็มีรายการสิ่งที่อาจเป็นปัญหาทั้งหมด ตัวอย่างเช่น สมมติว่าสีม่วงต้องใช้กล้องด้านหน้า อันที่จริงแล้ว จุดประสงค์หลักของ Purple คือการใช้กล้องหน้าเพื่อถ่ายทำสิ่งต่างๆ ที่น่าสนใจ แต่ปรากฏว่าไม่ใช่อุปกรณ์ API 11 ขึ้นไปทั้งหมด หรือแม้กระทั่งกล้องหน้า สยองขวัญ
หากผู้ใช้เรียกดู Google Play จากอุปกรณ์เครื่องใดเครื่องหนึ่ง Google Play จะดูที่ ให้ดูว่า Purple ระบุกล้องหน้าเป็นข้อกำหนด และไม่ต้องสนใจ ได้พิจารณาแล้วว่า Purple กับอุปกรณ์ดังกล่าว ไม่ตรงกับสวรรค์ของโลกดิจิทัล จากนั้นจะ ดูว่า Red ไม่เพียงแค่ใช้ได้กับอุปกรณ์ขนาดใหญ่เท่านั้น แต่ยังไม่สนใจว่า เพราะมีกล้องหน้า ผู้ใช้ยังดาวน์โหลดแอปได้จาก Google Play เพราะถึงแม้กล้องหน้าจะเกิดข้อผิดพลาดทั้งหมด แต่ก็ยังมี APK ที่สนับสนุน ระดับ API
คุณต้องมีรูปแบบรหัสเวอร์ชันที่ดีเพื่อให้ APK ทั้งหมดอยู่ใน "แทร็ก" แยกกัน เวอร์ชันที่แนะนำนั้นอยู่ที่บริเวณรหัสเวอร์ชันของ คู่มือนักพัฒนาซอฟต์แวร์ของเรา คุ้มค่าที่จะอ่านทั้งส่วน แต่ประเด็นสำคัญคือ APK เราจะใช้ตัวเลข 2 หลักแทน minSDK จำนวน 2 หลักเพื่อแสดงขนาดหน้าจอขั้นต่ำ/สูงสุด และ 3 เพื่อแสดงหมายเลขบิลด์ วิธีนี้จะช่วยให้อุปกรณ์เห็นว่า APK ใดก็ตามที่มีสิทธิ์และควรติดตั้งมากกว่า APK ที่ติดตั้งอยู่ในตอนนี้เป็น "การอัปเกรด" เมื่ออุปกรณ์อัปเกรดเป็น Android เวอร์ชันใหม่ (เช่น จาก 10 เป็น 11) รูปแบบหมายเลขเวอร์ชัน เมื่อใช้กับตัวอย่าง APK ชุดหนึ่งอาจมีลักษณะดังนี้
น้ำเงิน: 0304001, 0304002, 0304003...
สีเขียว: 0334001, 0334002, 0334003
สีแดง: 0344001, 0344002, 0344003...
สีม่วง: 1104001, 1104002, 1104003...
เมื่อนำทั้งหมดนี้มารวมกัน ไฟล์ Manifest ของ Android ก็น่าจะมีลักษณะคล้าย ดังต่อไปนี้:
สีน้ำเงิน:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="0304001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> <supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" /> ...
สีเขียว:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="0334001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="true" android:xlargeScreens="true" /> ...
สีแดง:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="0344001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="3" /> <supports-screens android:smallScreens="false" android:normalScreens="false" android:largeScreens="false" android:xlargeScreens="true" /> ...
ม่วง:
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1104001" android:versionName="1.0" package="com.example.foo"> <uses-sdk android:minSdkVersion="11" /> <supports-screens android:smallScreens="true" android:normalScreens="true" android:largeScreens="true" android:xlargeScreens="true" /> ...
โปรดทราบว่าในทางเทคนิคแล้ว APK หลายรายการจะทำงานร่วมกับแท็ก supports-screens หรือแท็ก compatible-screens โดยทั่วไปแล้ว เราขอแนะนำให้ใช้ Supports-screens เพียงอย่างเดียว และโดยทั่วไปแล้วการใช้ทั้ง 2 อย่างพร้อมกันเป็นความคิดที่ไม่ดีอย่างยิ่ง เนื่องจากจะทำให้เกิดความซับซ้อนโดยไม่จำเป็นและเพิ่มโอกาสที่จะเกิดข้อผิดพลาด นอกจากนี้ โปรดทราบว่าไฟล์ Manifest จะตั้งค่าสำหรับหน้าจอแต่ละขนาดอย่างชัดเจนแทนที่จะใช้ประโยชน์จากค่าเริ่มต้น (small และ normal จะถือเป็นจริงเสมอโดยค่าเริ่มต้น) วิธีนี้ช่วยให้คุณประหยัดได้ ปวดหัวไปทีละน้อย - ตัวอย่างเช่น ไฟล์ Manifest ที่มี SDK เป้าหมายเป็น < 9 จะมีขนาดใหญ่มาก ตั้งค่าเป็น "เท็จ" โดยอัตโนมัติ เนื่องจากไม่มีขนาดดังกล่าวอยู่ ดังนั้นจงกล่าวให้ชัดเจน
ตรวจสอบรายการตรวจสอบก่อนการเปิดตัว
ก่อนอัปโหลดไปยัง Google Play โปรดตรวจสอบรายการต่อไปนี้อีกครั้ง โปรดทราบว่า เกี่ยวข้องกับ APK หลายรายการโดยเฉพาะ และมิได้เป็นรายการตรวจสอบที่สมบูรณ์ ที่มีการอัปโหลดไปยัง Google Play
- APK ทั้งหมดต้องมีชื่อแพ็กเกจเดียวกัน
- APK ทั้งหมดต้องรับรองด้วยใบรับรองเดียวกัน
- หาก APK ทับซ้อนกันในเวอร์ชันแพลตฟอร์ม รายการที่มี minSdkVersion สูงกว่าต้องมี รหัสเวอร์ชันที่สูงกว่า
- ตั้งค่าขนาดหน้าจอทุกขนาดที่คุณต้องการให้ APK รองรับเป็น "จริง" ในไฟล์ Manifest หน้าจอทุกขนาด หากไม่ต้องการให้เป็นเช่นนั้น ให้ตั้งค่าเป็น "เท็จ"
- ตรวจสอบตัวกรองไฟล์ Manifest อีกครั้งเพื่อหาข้อมูลที่ขัดแย้งกัน (APK ที่รองรับเฉพาะ ไม่มีใครเห็นคัพเค้กบนหน้าจอ XLARGE เลย)
- ไฟล์ Manifest ของ APK แต่ละรายการต้องไม่ซ้ำกันในหน้าจอที่รองรับ พื้นผิว OpenGL หรือ เวอร์ชันแพลตฟอร์ม
- ลองทดสอบ APK แต่ละรายการบนอุปกรณ์อย่างน้อย 1 เครื่อง นอกจากที่กล่าวมา คุณมีรางวัลที่ใช้จ่ายมากที่สุด โปรแกรมจำลองอุปกรณ์ที่ปรับแต่งได้ในธุรกิจที่อยู่ในเครื่องการพัฒนาของคุณ สุดๆ ไปเลย
นอกจากนี้ควรตรวจสอบ APK ที่คอมไพล์แล้วก่อนนำเข้าสู่ตลาด เพื่อให้แน่ใจว่าไม่ได้มี ที่อาจซ่อนแอปพลิเคชันของคุณบน Google Play ได้ ซึ่งจริงๆ แล้วไม่ซับซ้อนเลยเมื่อใช้เครื่องมือ "aapt" Aapt (เครื่องมือแพ็กเกจเนื้อหา Android) เป็นส่วนหนึ่งของกระบวนการสร้างสำหรับการสร้างและ ทำแพ็กเกจแอปพลิเคชัน Android ของคุณ และยังเป็นเครื่องมือที่ใช้งานสะดวกในการตรวจสอบแอปพลิเคชันเหล่านั้น
>aapt dump badging package: name='com.example.hello' versionCode='1' versionName='1.0' sdkVersion:'11' uses-permission:'android.permission.SEND_SMS' application-label:'Hello' application-icon-120:'res/drawable-ldpi/icon.png' application-icon-160:'res/drawable-mdpi/icon.png' application-icon-240:'res/drawable-hdpi/icon.png' application: label='Hello' icon='res/drawable-mdpi/icon.png' launchable-activity: name='com.example.hello.HelloActivity' label='Hello' icon='' uses-feature:'android.hardware.telephony' uses-feature:'android.hardware.touchscreen' main supports-screens: 'xlarge' supports-any-density: 'true' locales: '--_--' densities: '120' '160' '240'
เมื่อคุณตรวจสอบเอาต์พุต aapt อย่าลืมตรวจสอบว่าไม่มีค่าที่ขัดแย้งกัน รองรับหน้าจอและหน้าจอที่เข้ากันได้ และคุณไม่มี "used-feature" โดยไม่ตั้งใจ ค่า ที่เพิ่มเข้ามาอันเป็นผลมาจากสิทธิ์ที่คุณตั้งค่าไว้ในไฟล์ Manifest ในตัวอย่างข้างต้น APK ไม่แสดงให้คนส่วนใหญ่เห็น หรือบางอุปกรณ์ก็มองไม่เห็น
เหตุผล การเพิ่มสิทธิ์ที่จำเป็น SEND_SMS ทำให้ได้เพิ่มข้อกำหนดด้านฟีเจอร์ของ android.hardware.telephony โดยปริยาย เนื่องจากอุปกรณ์ขนาดใหญ่ (หรือทั้งหมด) ส่วนใหญ่เป็นแท็บเล็ตที่ไม่มีฮาร์ดแวร์สำหรับโทรศัพท์ Google Play จะกรอง APK นี้ในกรณีนี้ จนกว่าอุปกรณ์ในอนาคตจะมีขนาดใหญ่พอที่จะรายงานว่าหน้าจอเป็นขนาดที่ใหญ่และมีฮาร์ดแวร์โทรศัพท์
แต่โชคดีที่ปัญหานี้แก้ไขได้ง่ายๆ โดยการเพิ่มข้อมูลต่อไปนี้ลงในไฟล์ Manifest
<uses-feature android:name="android.hardware.telephony" android:required="false" />
เพิ่มข้อกําหนด android.hardware.touchscreen
โดยปริยายเช่นกัน หากต้องการให้แสดง APK ในทีวีซึ่งเป็นอุปกรณ์ที่ไม่ใช่หน้าจอสัมผัส คุณควรเพิ่มสิ่งต่อไปนี้ลงในไฟล์ Manifest
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
เมื่อทำตามรายการตรวจสอบก่อนการเปิดตัวเรียบร้อยแล้ว ให้อัปโหลด APK ไปยัง Google Play อาจใช้เวลาเล็กน้อยก่อนที่แอปพลิเคชันจะปรากฏเมื่อเรียกดู Google Play แต่ให้ดำเนินการตรวจสอบเป็นครั้งสุดท้ายเมื่อปรากฏขึ้นอีกครั้ง ดาวน์โหลดแอปพลิเคชันลงในอุปกรณ์ทดสอบที่คุณมีเพื่อตรวจสอบว่า APK กำหนดเป้าหมายไปยังอุปกรณ์ที่ต้องการ ยินดีด้วย คุณดำเนินการเสร็จแล้ว