การรองรับ APK ต่างๆ

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

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

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

Google Play อนุญาตให้คุณเผยแพร่ APK หลายรายการภายใต้ข้อมูลแอปพลิเคชันเดียวกันเพื่อช่วยให้คุณเผยแพร่แอปพลิเคชันสำหรับอุปกรณ์ได้มากที่สุด จากนั้น Google Play จะจัดหา APK แต่ละรายการไปยังอุปกรณ์ที่เหมาะสมตามการรองรับการกำหนดค่าที่คุณประกาศไว้ในไฟล์ Manifest ของ APK แต่ละรายการ

การเผยแพร่แอปพลิเคชันด้วย APK หลายรายการช่วยให้คุณทำสิ่งต่อไปนี้ได้

  • รองรับรูปแบบการบีบอัดพื้นผิว OpenGL ที่ต่างกันในแต่ละ APK
  • รองรับขนาดและความหนาแน่นของหน้าจอที่แตกต่างกันด้วย APK แต่ละรายการ
  • รองรับชุดฟีเจอร์ของอุปกรณ์ที่แตกต่างกันด้วย APK แต่ละรายการ
  • รองรับแพลตฟอร์มเวอร์ชันต่างๆ ด้วย APK แต่ละรายการ
  • รองรับสถาปัตยกรรม CPU ที่ต่างกันด้วย APK แต่ละรายการ (เช่น สำหรับ ARM หรือ x86 เมื่อแอปใช้ Android NDK)
  • เพิ่มประสิทธิภาพสำหรับอุปกรณ์ระดับเริ่มต้น เช่น อุปกรณ์ที่ใช้ Android (รุ่น Go)

ปัจจุบัน Google Play รองรับเฉพาะลักษณะของอุปกรณ์เหล่านี้สำหรับการเผยแพร่ APK หลายรายการเป็นแอปพลิเคชันเดียวกัน

หมายเหตุ: หากต้องการดูข้อมูลเกี่ยวกับการเตรียมและเผยแพร่ APK ใน Google Play โปรดดูบทความ การเตรียมพร้อมและเปิดตัวรุ่นในศูนย์ช่วยเหลือ

วิธีการทํางานของ APK หลายรายการ

แนวคิดในการใช้ APK หลายรายการใน Google Play คือคุณมีรายการเดียวใน Google Play สําหรับแอปพลิเคชัน แต่อุปกรณ์ต่างๆ อาจดาวน์โหลด APK ที่แตกต่างกัน ซึ่งหมายความว่า

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

ตัวกรองที่รองรับ

อุปกรณ์ที่จะรับ APK แต่ละรายการจะกำหนดโดยตัวกรอง Google Play ที่ระบุโดยองค์ประกอบในไฟล์ Manifest ของ APK แต่ละรายการ อย่างไรก็ตาม Google Play อนุญาตให้คุณเผยแพร่ APK หลายรายการได้ก็ต่อเมื่อแต่ละ APK ใช้ตัวกรองเพื่อรองรับลักษณะของอุปกรณ์ต่อไปนี้ในลักษณะต่างๆ

  • รูปแบบการบีบอัดพื้นผิว OpenGL

    ซึ่งอิงตามองค์ประกอบ <supports-gl-texture> ของไฟล์ Manifest

    ตัวอย่างเช่น เมื่อพัฒนาเกมที่ใช้ OpenGL ES คุณสามารถจัดเตรียม APK 1 รายการสำหรับอุปกรณ์ที่รองรับการบีบอัดพื้นผิว ATI และ APK อีกรายการสำหรับอุปกรณ์ที่รองรับการบีบอัด PowerVR (และอื่นๆ อีกมากมาย)

  • ขนาดหน้าจอ (และความหนาแน่นของหน้าจอ หากต้องการ)

    ซึ่งอิงตามองค์ประกอบ <supports-screens> หรือ <compatible-screens> ของไฟล์ Manifest คุณไม่ควรใช้ทั้ง 2 องค์ประกอบ และควรใช้เฉพาะ <supports-screens> เมื่อเป็นไปได้

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

    ลองทำตามแนวทางปฏิบัติแนะนำต่อไปนี้เพื่อรองรับหน้าจอทุกขนาด

    • ระบบ Android รองรับแอปพลิเคชันต่างๆ อย่างเต็มที่เพื่อให้รองรับการกำหนดค่าหน้าจอทั้งหมดด้วย APK เดียว คุณควรหลีกเลี่ยงการสร้าง APK หลายรายการเพื่อรองรับหน้าจอที่แตกต่างกัน เว้นแต่จำเป็นจริงๆ และทําตามคู่มือการรองรับหน้าจอหลายประเภทแทน เพื่อให้แอปพลิเคชันมีความยืดหยุ่นและปรับให้เข้ากับการกำหนดค่าหน้าจอทั้งหมดได้ด้วย APK เดียว
    • โดยค่าเริ่มต้น แอตทริบิวต์ขนาดหน้าจอทั้งหมดในองค์ประกอบ <supports-screens> จะเป็น "true" หากคุณไม่ได้ประกาศเป็นอย่างอื่น อย่างไรก็ตาม เนื่องจากมีการเพิ่มแอตทริบิวต์ android:xlargeScreens ใน Android 2.3 (API ระดับ 9) Google Play จะถือว่าแอตทริบิวต์เป็น "เท็จ" หากแอปพลิเคชันไม่ได้ตั้งค่า android:minSdkVersion หรือ android:targetSdkVersion เป็น "9" ขึ้นไป
    • คุณไม่ควรรวมองค์ประกอบ <supports-screens> และ <compatible-screens> ไว้ในไฟล์ Manifest การใช้ทั้ง 2 รายการจะเพิ่มโอกาสที่จะเกิดข้อผิดพลาดเนื่องจากมีความขัดแย้งกัน หากต้องการความช่วยเหลือในการตัดสินใจว่าจะเผยแพร่ไปยังหน้าจอใด ให้อ่านหัวข้อการเผยแพร่ไปยังหน้าจอที่เจาะจง หากหลีกเลี่ยงการใช้ทั้ง 2 รายการไม่ได้ โปรดทราบว่าหากมีข้อขัดแย้งในข้อตกลงระหว่างขนาดหนึ่งๆ "เท็จ" จะมีผล

  • ชุดฟีเจอร์ของอุปกรณ์

    ซึ่งอิงตามองค์ประกอบ <uses-feature> ของไฟล์ Manifest

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

  • Android (รุ่น Go)

    หากต้องการกำหนดเป้าหมายเป็นอุปกรณ์ที่ใช้ Android (รุ่น Go) APK ของคุณจะต้องประกาศ <uses-feature android:name="android.hardware.ram.low" android:required="true">, กำหนดเป้าหมายเป็น API ระดับ 26 เป็นอย่างน้อย และมีรหัสเวอร์ชันสูงกว่า APK เวอร์ชันที่ไม่ใช่ Go

  • ระดับ API

    ซึ่งอิงตามองค์ประกอบ <uses-sdk> ของไฟล์ Manifest คุณสามารถใช้ทั้งแอตทริบิวต์ android:minSdkVersion และ android:maxSdkVersion เพื่อระบุการรองรับ API ระดับต่างๆ ได้

    เช่น คุณสามารถเผยแพร่แอปพลิเคชันด้วย APK 1 รายการที่รองรับ API ระดับ 16-19 (Android 4.1.x - 4.4.4) โดยใช้ API ที่มีให้ตั้งแต่ API ระดับ 16 หรือต่ำกว่า และ APK อีกรายการที่รองรับ API ระดับ 21 ขึ้นไป (Android 5.0 ขึ้นไป) โดยใช้ API ที่มีให้ตั้งแต่ API ระดับ 21 หรือต่ำกว่า หากต้องการดูวิธีสร้าง APK แยกต่างหากที่แต่ละรายการกำหนดเป้าหมาย API ในช่วงต่างๆ กัน ให้ไปที่ กำหนดค่าตัวแปรผลิตภัณฑ์

    หากคุณใช้ลักษณะนี้เป็นตัวแปรในการแยก APK หลายรายการ APK ที่มีค่า android:minSdkVersion สูงกว่าจะต้องมีค่า android:versionCode สูงกว่า กรณีนี้ยังเกิดขึ้นได้หาก APK 2 รายการรองรับอุปกรณ์ที่ทับซ้อนกันตามตัวกรองที่รองรับที่แตกต่างกัน วิธีนี้ช่วยให้มั่นใจได้ว่าเมื่ออุปกรณ์ได้รับการอัปเดตระบบ Google Play จะเสนอการอัปเดตแอปพลิเคชันของคุณให้ผู้ใช้ได้ (เนื่องจากการอัปเดตจะอิงตามรหัสเวอร์ชันแอปที่เพิ่มขึ้น) ข้อกำหนดนี้อธิบายไว้เพิ่มเติมในส่วนด้านล่างเกี่ยวกับกฎสำหรับ APK หลายรายการ

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


  • สถาปัตยกรรม CPU (ABI)

    ไลบรารีแบบเนทีฟบางรายการมีแพ็กเกจแยกต่างหากสำหรับสถาปัตยกรรม CPU หรือ Application Binary Interface (ABI) บางรายการ แทนที่จะแพ็กเกจไลบรารีทั้งหมดที่มีให้ไว้ใน APK เดียว คุณสามารถสร้าง APK แยกต่างหากสำหรับ ABI แต่ละรายการและรวมเฉพาะไลบรารีที่จําเป็นสําหรับ ABI นั้น ดูข้อมูลเพิ่มเติมเกี่ยวกับการสร้าง APK แยกต่างหากตาม ABI เป้าหมายได้ที่สร้าง APK หลายรายการ

องค์ประกอบอื่นๆ ของไฟล์ Manifest ที่เปิดใช้ตัวกรองของ Google Play แต่ไม่ได้ระบุไว้ข้างต้นจะยังคงมีผลกับแต่ละ APK ตามปกติ อย่างไรก็ตาม Google Play ไม่อนุญาตให้คุณเผยแพร่ APK แยกต่างหากตามลักษณะของอุปกรณ์ที่แตกต่างกัน ดังนั้น คุณจะเผยแพร่ APK หลายรายการไม่ได้หากตัวกรองที่ระบุไว้ข้างต้นเหมือนกันสำหรับ APK แต่ละรายการ (แต่ APK แตกต่างกันไปตามลักษณะอื่นๆ ในไฟล์ Manifest หรือ APK) เช่น คุณไม่สามารถระบุ APK ที่แตกต่างกันโดยมีลักษณะเฉพาะของ <uses-configuration> เท่านั้น

กฎสำหรับ APK หลายรายการ

คุณต้องเข้าใจกฎต่อไปนี้ก่อนเผยแพร่ APK หลายรายการสําหรับแอปพลิเคชัน

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

    กล่าวคือ APK แต่ละรายการต้องประกาศการรองรับตัวกรอง Google Play ที่รองรับอย่างน้อย 1 รายการ (ตามที่ระบุไว้ข้างต้น) ในลักษณะที่แตกต่างกันเล็กน้อย

    โดยปกติแล้ว คุณจะต้องแยก APK ตามลักษณะเฉพาะ (เช่น รูปแบบการบีบอัดพื้นผิวที่รองรับ) ดังนั้น APK แต่ละรายการจะประกาศการรองรับอุปกรณ์ที่แตกต่างกัน อย่างไรก็ตาม คุณเผยแพร่ APK หลายรายการที่รองรับอุปกรณ์ทับซ้อนกันเล็กน้อยได้ เมื่อ APK 2 รายการทับซ้อนกัน (รองรับการกำหนดค่าอุปกรณ์เดียวกันบางส่วน) อุปกรณ์ที่อยู่ในช่วงทับซ้อนดังกล่าวจะได้รับ APK ที่มีรหัสเวอร์ชันสูงกว่า (กำหนดโดย android:versionCode)

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

    กรณีนี้จะเกิดขึ้นก็ต่อเมื่อ APK แตกต่างกันเฉพาะตามระดับ API ที่รองรับ (ไม่มีตัวกรองที่รองรับอื่นๆ แยก APK ออกจากกัน) หรือเมื่อ APK ใช้ตัวกรองที่รองรับอื่น แต่ APK ซ้อนทับกันภายในตัวกรองนั้น

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

    หมายเหตุ: ขนาดของรหัสเวอร์ชันที่เพิ่มขึ้นนั้นไม่เกี่ยวข้อง เพียงแค่ต้องใหญ่ขึ้นในเวอร์ชันที่รองรับระดับ API ที่สูงขึ้น

    ตัวอย่างเช่น

    • หาก APK ที่คุณอัปโหลดสำหรับ API ระดับ 16 ขึ้นไป (Android 4.1.x ขึ้นไป) มีรหัสเวอร์ชันเป็น 0400 แสดงว่า APK สำหรับ API ระดับ 21 ขึ้นไป (Android 5.0 ขึ้นไป) ต้องเป็น 0401 ขึ้นไป ในกรณีนี้ ระดับ API เป็นตัวกรองเดียวที่ใช้ได้ ดังนั้นรหัสเวอร์ชันต้องเพิ่มขึ้นตามการรองรับระดับ API สำหรับแต่ละ APK เพื่อให้ผู้ใช้ได้รับการอัปเดตเมื่อได้รับการอัปเดตระบบ
    • หากคุณมี APK 1 รายการสำหรับ API ระดับ 16 (ขึ้นไป) และหน้าจอขนาดเล็ก - ขนาดใหญ่ และอีก 1 รายการสำหรับ API ระดับ 21 (ขึ้นไป) และหน้าจอขนาดใหญ่ - ขนาดใหญ่พิเศษ รหัสเวอร์ชันต้องเพิ่มขึ้นตามระดับ API ในกรณีนี้ ระบบจะใช้ตัวกรองระดับ API เพื่อแยก APK แต่ละรายการออกจากกัน แต่จะใช้ขนาดหน้าจอด้วย เนื่องจากขนาดหน้าจอทับซ้อนกัน (ทั้ง 2 APK รองรับหน้าจอขนาดใหญ่) รหัสเวอร์ชันจึงต้องยังคงเรียงตามลำดับ วิธีนี้ช่วยให้มั่นใจได้ว่าอุปกรณ์หน้าจอขนาดใหญ่ที่รับการอัปเดตระบบเป็น API ระดับ 21 จะได้รับอัปเดตสำหรับ APK รายการที่ 2
    • หากคุณมี APK 1 รายการสำหรับ API ระดับ 16 (ขึ้นไป) และหน้าจอขนาดเล็ก - ปกติ และอีก APK 1 รายการสำหรับ API ระดับ 21 (ขึ้นไป) และหน้าจอขนาดใหญ่ - ขนาดใหญ่พิเศษ รหัสเวอร์ชันไม่จําเป็นต้องเพิ่มขึ้นตามระดับ API เนื่องจากตัวกรองขนาดหน้าจอไม่ทับซ้อนกัน จึงไม่มีอุปกรณ์ที่อาจย้ายไปมาระหว่าง APK 2 รายการนี้ จึงไม่จำเป็นต้องเพิ่มรหัสเวอร์ชันจากระดับ API ที่ต่ำกว่าเป็นระดับ API ที่สูงกว่า
    • หากคุณมี APK 1 รายการสำหรับ API ระดับ 16 (ขึ้นไป) และ CPU ARMv7 และอีก 1 รายการสำหรับ API ระดับ 21 (ขึ้นไป) และ CPU ARMv5TE รหัสเวอร์ชันต้องเพิ่มขึ้นตามระดับ API ในกรณีนี้ ระบบจะใช้ตัวกรองระดับ API เพื่อแยก APK แต่ละรายการออกจากกัน แต่จะใช้สถาปัตยกรรม CPU ด้วย เนื่องจาก APK ที่มีไลบรารี ARMv5TE เข้ากันได้กับอุปกรณ์ที่มี CPU ARMv7 ดังนั้น APK จึงทับซ้อนกันในแง่ลักษณะนี้ ดังนั้น รหัสเวอร์ชันของ APK ที่รองรับ API ระดับ 21 ขึ้นไปจึงต้องสูงกว่า วิธีนี้ช่วยให้มั่นใจได้ว่าอุปกรณ์ที่มี CPU ARMv7 ซึ่งได้รับการอัปเดตระบบเป็น API ระดับ 21 จะได้รับการอัปเดตสำหรับ APK รายการที่ 2 ซึ่งออกแบบมาสำหรับ API ระดับ 21 อย่างไรก็ตาม เนื่องจากการอัปเดตประเภทนี้ส่งผลให้อุปกรณ์ ARMv7 ใช้ APK ที่ไม่ได้รับการเพิ่มประสิทธิภาพอย่างเต็มรูปแบบสำหรับ CPU ของอุปกรณ์นั้น คุณจึงควรจัดเตรียม APK สำหรับทั้งสถาปัตยกรรม ARMv5TE และ ARMv7 ในแต่ละระดับ API เพื่อเพิ่มประสิทธิภาพของแอปใน CPU แต่ละรุ่น หมายเหตุ: การดำเนินการนี้จะมีผลเฉพาะเมื่อเปรียบเทียบ APK กับไลบรารี ARMv5TE และ ARMv7 เท่านั้น และไม่มีผลเมื่อเปรียบเทียบไลบรารีเนทีฟอื่นๆ

การไม่ปฏิบัติตามกฎข้างต้นจะทำให้คุณพบข้อผิดพลาดใน Google Play Console เมื่อเปิดใช้งาน APK และคุณจะเผยแพร่แอปพลิเคชันไม่ได้จนกว่าจะแก้ไขข้อผิดพลาด

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

  • เมื่อคุณแก้ไข APK เพื่อ "ลด" การรองรับลักษณะของอุปกรณ์ และไม่มี APK อื่นที่รองรับอุปกรณ์ที่อยู่นอกช่วงที่ได้รับการรองรับ ตัวอย่างเช่น หากปัจจุบัน APK รองรับหน้าจอขนาดเล็กและขนาดปกติ และคุณเปลี่ยนให้รองรับเฉพาะหน้าจอขนาดเล็ก แสดงว่าคุณได้ลดกลุ่มอุปกรณ์ที่รองรับและอุปกรณ์บางรุ่นจะไม่เห็นแอปพลิเคชันของคุณใน Google Play อีกต่อไป คุณสามารถแก้ไขปัญหานี้ได้โดยการเพิ่ม APK อื่นที่รองรับหน้าจอขนาดปกติเพื่อให้อุปกรณ์ทั้งหมดที่รองรับก่อนหน้านี้ยังคงรองรับ
  • เมื่อ APK 2 รายการขึ้นไป "ทับซ้อนกัน" ตัวอย่างเช่น หาก APK หนึ่งรองรับหน้าจอขนาดเล็ก ปกติ และใหญ่ ส่วนอีก APK รองรับขนาดใหญ่และขนาดใหญ่พิเศษ แสดงว่ามีความทับซ้อนกัน เนื่องจากทั้ง 2 APK รองรับหน้าจอขนาดใหญ่ หากคุณไม่แก้ไขปัญหานี้ อุปกรณ์ที่มีสิทธิ์สำหรับทั้ง 2 APK (อุปกรณ์หน้าจอขนาดใหญ่ในตัวอย่าง) จะได้รับ APK ที่มีรหัสเวอร์ชันสูงสุด

    หมายเหตุ: หากคุณสร้าง APK แยกกันสำหรับสถาปัตยกรรม CPU ที่แตกต่างกัน โปรดทราบว่า APK สำหรับ ARMv5TE จะทับซ้อนกับ APK สำหรับ ARMv7 กล่าวคือ APK ที่ออกแบบมาสำหรับ ARMv5TE จะใช้ได้กับอุปกรณ์ ARMv7 แต่ในทางกลับกันจะใช้ไม่ได้ (APK ที่มีเฉพาะไลบรารี ARMv7 ใช้ไม่ได้กับอุปกรณ์ ARMv5TE)

เมื่อเกิดความขัดแย้งดังกล่าว คุณจะเห็นข้อความเตือน แต่ยังคงเผยแพร่แอปพลิเคชันได้

การสร้าง APK หลายรายการ

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

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

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

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

การกำหนดรหัสเวอร์ชัน

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

การจัดเรียงรหัสเวอร์ชัน

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

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

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

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

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

การใช้รูปแบบรหัสเวอร์ชัน

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

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

เราขอแนะนำให้ใช้รหัสเวอร์ชันที่มีตัวเลขอย่างน้อย 7 หลัก โดยจำนวนเต็มที่ใช้แสดงการกําหนดค่าที่รองรับจะอยู่ในช่วงบิตที่มีลําดับสูงขึ้น และชื่อเวอร์ชัน (จาก android:versionName) จะอยู่ในช่วงบิตที่มีลําดับต่ำกว่า ตัวอย่างเช่น เมื่อชื่อเวอร์ชันแอปพลิเคชันคือ 3.1.0 รหัสเวอร์ชันของ APK ระดับ API 4 และ APK ระดับ API 11 จะเป็น 0400310 และ 1100310 ตามลำดับ ตัวเลข 2 หลักแรกสงวนไว้สำหรับระดับ API (4 และ 11 ตามลำดับ) ตัวเลข 2 หลักกลางสำหรับขนาดหน้าจอหรือรูปแบบพื้นผิว GL (ไม่ได้ใช้ในตัวอย่างเหล่านี้) และตัวเลข 3 หลักสุดท้ายสำหรับชื่อเวอร์ชันของแอปพลิเคชัน (3.1.0) รูปที่ 1 แสดงตัวอย่าง 2 รายการที่แยกตามทั้งเวอร์ชันแพลตฟอร์ม (ระดับ API) และขนาดหน้าจอ

รูปที่ 1 รูปแบบที่แนะนำสำหรับรหัสเวอร์ชันคือใช้ตัวเลข 2 ตัวแรกสำหรับระดับ API, ตัวเลขที่ 2 และ 3 สำหรับขนาดหน้าจอขั้นต่ำและสูงสุด (1 - 4 หมายถึงขนาดทั้ง 4 ขนาด) หรือเพื่อระบุรูปแบบพื้นผิว และตัวเลข 3 ตัวสุดท้ายสำหรับเวอร์ชันแอป

รูปแบบรหัสเวอร์ชันนี้เป็นเพียงคำแนะนำเกี่ยวกับวิธีสร้างรูปแบบที่ปรับขนาดได้เมื่อแอปพลิเคชันพัฒนาขึ้น โดยเฉพาะอย่างยิ่ง รูปแบบนี้ไม่ได้แสดงวิธีระบุรูปแบบการบีบอัดพื้นผิวที่แตกต่างกัน ตัวเลือกหนึ่งอาจเป็นการกำหนดตารางของคุณเองซึ่งระบุจำนวนเต็มที่แตกต่างกันสำหรับรูปแบบการบีบอัดแต่ละรูปแบบที่แอปพลิเคชันรองรับ (เช่น 1 อาจสอดคล้องกับ ETC1 และ 2 คือ ATITC เป็นต้น)

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

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