สร้าง APK หลายรายการสำหรับ API ระดับต่างๆ

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

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

ยืนยันว่าคุณต้องการ APK หลายรายการ

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

หากจัดการได้ การจำกัดแอปพลิเคชันของคุณไว้ใน APK เดียวมีข้อดีหลายประการ ดังนี้

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

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

จัดทำแผนภูมิข้อกำหนด

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

หากต้องการสร้างแผนภูมิ APK หลายรายการ ให้เริ่มต้นด้วยแถวของเซลล์ที่แสดงระดับ API ต่างๆ ของแพลตฟอร์ม Android เพิ่มเซลล์อีก 1 เซลล์ไว้ที่ท้ายสุดเพื่อแสดง Android เวอร์ชันในอนาคต

3 4 5 6 7 8 9 10 11 12 13 +

จากนั้นให้ระบายสีในแผนภูมิโดยให้แต่ละสีแสดง APK ต่อไปนี้คือตัวอย่างวิธีใช้ APK แต่ละรายการกับ API ระดับหนึ่งๆ

3 4 5 6 7 8 9 10 11 12 13 +

เมื่อสร้างแผนภูมินี้แล้ว ให้แชร์กับทีม การสื่อสารกับทีมในโปรเจ็กต์ของคุณจะง่ายขึ้นทันที เนื่องจากคุณไม่ต้องถามว่า "APK สำหรับ API ระดับ 3 ถึง 6 เป็นอย่างไร ก็คือ Android 1.x ใช่ไหม เป็นอย่างไรบ้าง" คุณก็แค่พูดว่า "Blue APK เป็นอย่างไรบ้าง"

ใส่โค้ดและทรัพยากรทั่วไปทั้งหมดในโปรเจ็กต์ไลบรารี

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

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

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

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

สร้างโปรเจ็กต์ APK ใหม่

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

alexlucas:~/code/multi-apks-root$ ls
foo-blue
foo-green
foo-lib
foo-red

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

ปรับไฟล์ Manifest

เมื่อผู้ใช้ดาวน์โหลดแอปพลิเคชันที่ใช้ APK หลายรายการผ่าน Google Play ระบบจะเลือก APK ที่ถูกต้องให้ใช้โดยทำตามกฎง่ายๆ 2 ข้อต่อไปนี้

  • ไฟล์ Manifest ต้องแสดงให้เห็นว่า APK นั้นๆ มีสิทธิ์
  • APK ที่มีหมายเลขเวอร์ชันสูงสุดจะเป็นผู้ชนะ

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

3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +
3 4 5 6 7 8 9 10 11 12 13 +

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

3 4 5 6 7 8 9 10 11 12 13 +

สมมติเพิ่มเติมว่า APK สีแดงมีข้อกำหนดบางอย่างที่อีก 2 รายการไม่มี หน้าตัวกรองใน Google Play ของคู่มือนักพัฒนาแอป Android มีรายการสาเหตุที่เป็นไปได้ทั้งหมด สมมติว่าสีแดงต้องใช้กล้องหน้า อันที่จริง จุดประสงค์ทั้งหมดของ APK สีแดงคือการรวมกล้องหน้าเข้ากับฟังก์ชันการทำงานใหม่ที่ยอดเยี่ยมซึ่งเพิ่มเข้ามาใน API 11 แต่ปรากฏว่าอุปกรณ์ที่รองรับ API 11 บางรุ่นไม่มีกล้องหน้าด้วยซ้ำ น่ากลัวจัง

แต่โชคดีที่หากผู้ใช้เรียกดู Google Play จากอุปกรณ์ดังกล่าว Google Play จะดูไฟล์ Manifest และเห็นว่า Red ระบุกล้องหน้าเป็นข้อกำหนด แล้วจึงละเว้นแอปดังกล่าวโดยปริยาย เนื่องจากพิจารณาแล้วว่า Red กับอุปกรณ์ดังกล่าวไม่เข้ากัน จากนั้นระบบจะเห็นว่า ตัวแปร Green ไม่เพียงเข้ากันได้กับอุปกรณ์ที่มี API 11 ในอนาคต (เนื่องจากไม่ได้กำหนด maxSdkVersion) แต่ยังไม่สนใจว่ามีกล้องหน้าหรือไม่ด้วย ผู้ใช้ยังคงดาวน์โหลดแอปจาก Google Play ได้ เนื่องจากแม้จะเกิดเหตุการณ์ไม่คาดคิดเกี่ยวกับกล้องหน้า แต่ยังมี APK ที่รองรับระดับ API ดังกล่าว

คุณต้องมีรูปแบบรหัสเวอร์ชันที่ดีเพื่อให้ APK ทั้งหมดอยู่ใน "แทร็ก" แยกกัน รหัสที่แนะนําจะอยู่ในส่วนรหัสเวอร์ชันของคู่มือนักพัฒนาแอป เนื่องจากชุดตัวอย่าง APK จัดการกับมิติข้อมูลได้เพียง 1 ใน 3 รายการเท่านั้น การแยก APK แต่ละรายการด้วย 1,000, ตั้งค่าตัวเลข 2 ตัวแรกเป็น minSdkVersion สำหรับ APK นั้นๆ และเพิ่มจากตัวเลขนั้นจึงเพียงพอแล้ว ซึ่งอาจมีลักษณะดังนี้

สีน้ำเงิน: 03001, 03002, 03003, 03004...
เขียว: 07001, 07002, 07003, 07004...
สีแดง:11001, 11002, 11003, 11004...

เมื่อรวมข้อมูลทั้งหมดเข้าด้วยกัน ไฟล์ Manifest ของ Android อาจมีลักษณะดังต่อไปนี้

สีน้ำเงิน:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="3" />
    ...

สีเขียว:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="7" />
    ...

สีแดง:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
    <uses-sdk android:minSdkVersion="11" />
    ...

ตรวจสอบรายการตรวจสอบก่อนการเปิดตัว

โปรดตรวจสอบรายการต่อไปนี้อีกครั้งก่อนอัปโหลดไปยัง Google Play โปรดทราบว่ารายการเหล่านี้เกี่ยวข้องกับ APK หลายรายการโดยเฉพาะ และไม่ได้แสดงรายการตรวจสอบที่สมบูรณ์สำหรับแอปพลิเคชันทั้งหมดที่อัปโหลดไปยัง Google Play

  • APK ทั้งหมดต้องมีชื่อแพ็กเกจเดียวกัน
  • APK ทั้งหมดต้องลงชื่อด้วยใบรับรองเดียวกัน
  • หาก APK ทับซ้อนกันในด้านเวอร์ชันแพลตฟอร์ม APK ที่มี minSdkVersion สูงกว่าต้องมีรหัสเวอร์ชันที่สูงกว่า
  • ตรวจสอบตัวกรองไฟล์ Manifest อีกครั้งเพื่อหาข้อมูลที่ขัดแย้งกัน (ไม่มีใครจะเห็น APK ที่รองรับเฉพาะ Cupcake ในหน้าจอขนาดใหญ่พิเศษ)
  • ไฟล์ Manifest ของ APK แต่ละไฟล์ต้องไม่ซ้ำกันสำหรับหน้าจอ พื้นผิว OpenGL หรือเวอร์ชันแพลตฟอร์มที่รองรับอย่างน้อย 1 รายการ
  • ลองทดสอบ APK แต่ละรายการในอุปกรณ์อย่างน้อย 1 เครื่อง แต่คุณมีโปรแกรมจำลองอุปกรณ์ที่ปรับแต่งได้มากที่สุดแห่งหนึ่งในอุตสาหกรรมอยู่ในเครื่องสำหรับพัฒนาซอฟต์แวร์ สนุกได้เลย

นอกจากนี้ คุณควรตรวจสอบ APK ที่คอมไพล์แล้วก่อนเผยแพร่เพื่อให้มั่นใจว่าจะไม่มีเหตุการณ์ที่ไม่คาดคิดซึ่งอาจทำให้แอปพลิเคชันของคุณใน Google Play แสดงไม่ถูกต้อง ซึ่งจริงๆ แล้วไม่ซับซ้อนเลยเมื่อใช้เครื่องมือ "aapt" Aapt (Android Asset Packaging Tool) เป็นส่วนหนึ่งของกระบวนการสร้างสำหรับการสร้างและแพ็กเกจแอปพลิเคชัน 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: 'small' 'normal' 'large' 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

เมื่อตรวจสอบเอาต์พุต aapt ให้ตรวจสอบว่าคุณไม่มีค่าที่ขัดแย้งกันสำหรับ supports-screens และ compatible-screens และไม่มีค่า "uses-feature" ที่ไม่ได้ตั้งใจซึ่งเพิ่มเข้ามาเนื่องจากสิทธิ์ที่คุณกำหนดไว้ในไฟล์ Manifest ในตัวอย่างข้างต้น APK จะไม่แสดงในอุปกรณ์จํานวนมาก

เหตุผล การเพิ่มสิทธิ์ที่จำเป็น SEND_SMS จะเพิ่มข้อกำหนดฟีเจอร์ของ android.hardware.telephony โดยปริยาย เนื่องจาก API 11 คือ Honeycomb (Android เวอร์ชันที่เพิ่มประสิทธิภาพมาเพื่อแท็บเล็ตโดยเฉพาะ) และไม่มีอุปกรณ์ Honeycomb ที่มีฮาร์ดแวร์โทรศัพท์ Google Play จะกรอง APK นี้ออกในทุกกรณีจนกว่าจะมีอุปกรณ์ในอนาคตที่มี API ระดับสูงกว่าและมีฮาร์ดแวร์โทรศัพท์

แต่โชคดีที่ปัญหานี้แก้ไขได้ง่ายๆ โดยการเพิ่มข้อมูลต่อไปนี้ลงในไฟล์ 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 กำหนดเป้าหมายไปยังอุปกรณ์ที่ต้องการ ยินดีด้วย คุณทำเสร็จแล้ว

ก่อนหน้า
เกี่ยวกับ APK หลายรายการ
ถัดไป
สร้าง APK หลายรายการสำหรับหน้าจอขนาดต่างๆ