การสำรวจคุณภาพของหลายอุปกรณ์และการเผยแพร่ที่นอกเหนือจากอุปกรณ์เคลื่อนที่ใน Google Play

ขอต้อนรับทุกคน

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

ฉันชื่อ Jan Kleinert เป็นวิศวกรนักพัฒนาซอฟต์แวร์สัมพันธ์ในทีม Android สำหรับรถยนต์

และฉัน Faustine Liao หัวหน้าทีมปฏิบัติการในทีมความน่าเชื่อถือและความปลอดภัยของ Play

เรายินดีเป็นอย่างยิ่งที่ได้พบกับทุกคนในวันนี้

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

ดังนั้นในปัจจุบัน ผู้ใช้จึงโต้ตอบกับแอปใน Living Room บน Android TV, อาจจะในขณะที่รอรับลูกที่โรงเรียนหรือขณะชาร์จรถยนต์บน Android Auto หรือ Automotive OS, บนข้อมือด้วย Wear OS และในพื้นที่ 3 มิติที่สมจริงมากขึ้นด้วย Android XR

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

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

สร้างและเตรียมแอป จากนั้นสร้างข้อมูลใน Play Console, ทดสอบแอป, อัปโหลดและส่งรุ่นที่ใช้งานจริง แล้วรอรับการตรวจสอบและการอนุมัติ

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

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

มาเริ่มกันที่รากฐาน ซึ่งก็คือวิธีออกแบบสถาปัตยกรรมและแพ็กเกจแอป

ดังนั้นก่อนที่จะเริ่มใช้ Google Play Console คุณต้องตัดสินใจเรื่องสถาปัตยกรรมที่สำคัญ

คุณสร้าง App Bundle แบบรวมรายการเดียวที่มีทุกอย่างสำหรับรูปแบบของอุปกรณ์ทั้งหมดที่รองรับ หรือแบ่งแอปออกเป็นโมดูลเฉพาะรูปแบบของอุปกรณ์และสร้าง Android App Bundle หรือ AAB สำหรับแต่ละรายการ

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

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

ดังนั้น แม้ว่าแนวทาง Android App Bundle แบบรวมอาจดูจัดการได้ง่ายกว่า แต่เราขอแนะนำแนวทางแบบโมดูลาร์

ตัวอย่างต่อไปนี้แสดงให้เห็นว่าเหตุใดเราจึงแนะนำแนวทางแบบโมดูลาร์นี้

ลองจินตนาการว่าคุณมีแอปที่รองรับทั้งอุปกรณ์เคลื่อนที่และ Android TV

หากคุณส่ง Android App Bundle รายการเดียวในแทร็กการเผยแพร่บนอุปกรณ์เคลื่อนที่มาตรฐานและแอป Android TV ไม่ผ่านการตรวจสอบ การเผยแพร่ทั้งหมดจะหยุดลง

ซึ่งจะส่งผลต่อทั้งการเผยแพร่แอป Android TV และแอปบนอุปกรณ์เคลื่อนที่

ดังนั้นแม้ว่าแอปบนอุปกรณ์เคลื่อนที่จะไม่มีปัญหา แต่คุณจะต้องแก้ไขปัญหาที่ทำให้การตรวจสอบ Android TV ไม่ผ่าน และส่งแอปเข้ารับการตรวจสอบอีกครั้งก่อนที่ผู้ใช้จะใช้รุ่นดังกล่าวได้

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

ดังนั้น หากคุณมีโมดูลแอปแยกกันสำหรับแอปบนอุปกรณ์เคลื่อนที่และแอป TV คุณสามารถสร้าง Android App Bundle แยกกันสำหรับแต่ละแอปได้

และหากมีปัญหาเกี่ยวกับการตรวจสอบแอป TV ระบบจะบล็อกเฉพาะการเผยแพร่แอปนั้นจนกว่าคุณจะแก้ไขปัญหาได้

ระบบจะเผยแพร่รุ่นของแอปบนอุปกรณ์เคลื่อนที่ตามที่ต้องการ

อย่างที่กล่าวไปก่อนหน้านี้ว่ามีหลายวิธีในการแยกโมดูล

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

ดังนั้นที่ด้านบนสุดในสีเขียว เรามีโมดูลแอปสำหรับแต่ละรูปแบบของอุปกรณ์ ซึ่งจะช่วยแยกทรัพยากร Dependency เฉพาะแพลตฟอร์มออก

จากนั้นในสีเหลือง เรามีโมดูลฟีเจอร์ ซึ่งสอดคล้องกับส่วนที่แยกต่างหากของฟังก์ชันการทำงานของแอป

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

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

...

rootProject.name = "MultiFormFactorApp"

// Define modules for each form factor
include(":app:automotive")
include(":app:mobile")
include(":core:network")
include(":data:books")
include(":data:reviews")
include(":feature:home")
include(":feature:player")
include(":feature:reviews")

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

แนวทางแบบโมดูลาร์ดังกล่าวเชื่อมโยงกับกลยุทธ์แทร็กใน Play Console โดยตรง

เมื่อเผยแพร่ คุณจะมีแทร็กอุปกรณ์เคลื่อนที่มาตรฐาน แต่เรายังมีแทร็กรูปแบบของอุปกรณ์ที่เฉพาะเจาะจงด้วย

สำหรับ Android TV, Android XR และ Android Automotive OS คุณมีตัวเลือก

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

แต่มีข้อยกเว้น 2 ประการ

สำหรับ Wear OS คุณต้องใช้แทร็ก Wear OS โดยเฉพาะ

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

หากคุณจัดการแทร็กหลายแทร็ก การกำหนดเวอร์ชันเป็นสิ่งสำคัญ

วิธีหนึ่งคือการกำหนดตัวเลข 2-3 หลักแรกของรหัสเวอร์ชันให้กับรูปแบบของอุปกรณ์

เช่น 01 สำหรับอุปกรณ์เคลื่อนที่, 02 สำหรับ Wear OS, 03 สำหรับ Android Automotive OS เป็นต้น

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

ซึ่งจะช่วยป้องกันไม่ให้รหัสเวอร์ชันขัดแย้งกันใน Play Console

เมื่อจัดแพ็กเกจแอปแล้ว ก็ถึงเวลาทดสอบ

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

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

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

ดังนั้น การทดสอบภายในจึงเป็นจุดเริ่มต้นที่ดี

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

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

และสำหรับการทดสอบภายใน คุณจะได้รับ URL ที่ไม่ซ้ำกันซึ่งคุณสามารถแชร์กับผู้ทดสอบเหล่านั้นได้

เมื่อพอใจกับผลการทดสอบภายในแล้ว คุณสามารถเปลี่ยนไปใช้การทดสอบแบบปิดและการทดสอบแบบเปิดได้

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

คุณสามารถจัดการกลุ่มการทดสอบแบบปิดเป็นรายการอีเมลหรือผ่าน Google Groups ก็ได้

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

คุณจะปรากฏใน Google Play และทุกคนจะเข้าร่วมโปรแกรมทดสอบแบบเปิดได้

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

แทร็กทดสอบแบบเปิดและแบบปิดเหล่านี้จะทริกเกอร์การตรวจสอบ

ซึ่งถือเป็นข้อได้เปรียบอย่างมาก

ซึ่งจะช่วยให้คุณทดสอบกระบวนการตรวจสอบและแก้ไขอุปสรรคต่างๆ ได้ก่อนวันเปิดตัวที่ทุกคนตั้งตารอ

เมื่อพูดถึงกระบวนการตรวจสอบแล้ว เรามาพูดถึงสิ่งที่เกี่ยวข้องกับกระบวนการนี้และเหตุผลที่กระบวนการนี้มีความสำคัญกันสักหน่อย

หัวใจสำคัญของนโยบายและหลักเกณฑ์เหล่านี้คือคุณภาพของแอป

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

มาดูวิธีเตรียมแอปให้ผ่านการตรวจสอบได้ง่ายที่สุดกัน

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

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

หลักเกณฑ์ทั้ง 2 ชุดนี้เป็นจุดเริ่มต้นที่ดีมาก

แต่เรายังมีหลักเกณฑ์ด้านคุณภาพของแอปที่เฉพาะเจาะจงสำหรับอุปกรณ์แต่ละรูปแบบด้วย

ผู้ตรวจสอบของเราจะทดสอบแอปของคุณในอุปกรณ์จริงและโปรแกรมจำลองตามหลักเกณฑ์เหล่านี้

ดังนั้นคุณจึงต้องตรวจสอบว่าแอปเป็นไปตามนโยบายดังกล่าว

เราจะมาดูสาเหตุที่พบบ่อยที่สุดที่ทำให้แอปถูกปฏิเสธสำหรับอุปกรณ์แต่ละรูปแบบกัน

แต่โปรดทราบว่าหลักเกณฑ์เหล่านี้ไม่ได้ครอบคลุมหลักเกณฑ์ด้านคุณภาพของแอปทั้งหมด

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

มาเริ่มกันที่ Android TV ก่อน

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

สาเหตุที่พบบ่อยประการหนึ่งที่ทำให้แอป Android TV ถูกปฏิเสธคือแอปไม่มีรูปภาพแบนเนอร์หน้าจอหลักสำหรับแต่ละภาษาที่แอปรองรับ

ดังนั้น สิ่งที่คุณควรทำคือส่งรูปภาพขนาด 320 x 180 พิกเซลที่มีข้อความที่แปลแล้วซึ่งระบุแอปของคุณ

รูปภาพในสไลด์นี้แสดงตัวอย่างแบนเนอร์ในหน้าจอหลักที่เป็นไปตามเกณฑ์ดังกล่าว

ประการที่ 2 ในทีวีส่วนใหญ่ ผู้ใช้จะโต้ตอบกับอุปกรณ์โดยใช้รีโมต D-pad

ดังนั้น คุณจึงต้องรองรับการไปยังส่วนต่างๆ และการโฟกัสด้วย D-pad อย่างเหมาะสม

ตรวจสอบว่าคุณรองรับการควบคุมด้วย D-pad ขั้นต่ำเป็นอย่างน้อยเพื่อหลีกเลี่ยงการถูกปฏิเสธตามเกณฑ์ดังกล่าว

และสาเหตุที่พบบ่อยอันดับ 3 ที่ทำให้แอป Android TV ถูกปฏิเสธคือคุณไม่มีตัวกรอง Intent CATEGORY_LEANBACK_LAUNCHER ในไฟล์ Manifest ของ Android

<application ...>
...
<activity
    android:name="com.example.TvActivity"
    android:label="@string/app_name"
    android:theme="@style/Theme.Leanback">
    <intent-filter>
      <action android:name=
           "android.intent.action.MAIN" />
      <category android:name=
           "Android.intent.category.
            LEANBACK_LAUNCHER" />
    </intent-filter>
  </activity>
</application>

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

ดังนั้นเมื่อผู้ใช้เลือกแอปของคุณบนหน้าจอหลักของทีวี Intent นี้จะเป็นตัวระบุกิจกรรมที่จะเปิดขึ้น

ดังนั้นโปรดตรวจสอบว่าคุณได้ใส่ข้อมูลนั้นในไฟล์ Manifest แล้ว

Android XR คือก้าวต่อไป

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

คุณสามารถใช้ Perfetto เพื่อวิเคราะห์ประสิทธิภาพของแอปที่สร้างด้วย Jetpack XR SDK เพื่อช่วยให้มั่นใจว่าคุณปฏิบัติตามข้อกำหนดอัตราเฟรมขั้นต่ำ

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

ถัดไปคือรถยนต์ ซึ่งประกอบด้วยทั้ง Android Auto และ Android Automotive OS

สำหรับ Android Auto และ Android Automotive OS จะมีแนวคิดเรื่องหมวดหมู่ ซึ่งค่อนข้างเป็นเอกลักษณ์เฉพาะสำหรับรูปแบบของอุปกรณ์นี้

และอนุญาตให้เผยแพร่แอปบางหมวดหมู่เท่านั้นไปยังรถยนต์

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

เรามาดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้กัน

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

ไม่ว่าจะเป็นเวอร์ชันเบต้า เวอร์ชันเปิด ซึ่งหมายถึงเวอร์ชันสำหรับผู้ใช้ทั่วไป หรือยังไม่รองรับ ซึ่งระบุไว้ที่นี่ว่า "เร็วๆ นี้"

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

แต่หมวดหมู่อื่นๆ เช่น แอปการโทรเพื่อการสื่อสารสำหรับ Android Auto ยังอยู่ในเวอร์ชันเบต้า

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

ดูรายละเอียดเพิ่มเติมเกี่ยวกับเรื่องนี้และอื่นๆ ได้ในคู่มือนักพัฒนาซอฟต์แวร์ Android สำหรับรถยนต์

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

ข้อกำหนดของภาพหน้าจอ Android Automotive OS ที่ขาดหายไปหรือไม่ถูกต้องเป็นอีกสาเหตุหนึ่งที่พบบ่อยซึ่งทำให้แอปถูกปฏิเสธ

ดังนั้นเมื่อระบุภาพหน้าจอ Android Automotive OS คุณต้องตรวจสอบว่าได้รวมภาพหน้าจอแนวตั้งอย่างน้อย 2 ภาพและภาพหน้าจอแนวนอนอย่างน้อย 2 ภาพที่มีขนาดตามที่ระบุไว้ที่นี่

และคุณสามารถใช้โปรแกรมจำลอง Android Automotive OS เพื่อช่วยบันทึกภาพหน้าจอเหล่านี้ได้

ซึ่งตั้งค่าไว้ให้จับภาพหน้าจอในขนาดที่เหมาะสมตามที่คุณต้องการ

และสุดท้าย ความปลอดภัยเป็นสิ่งสำคัญที่สุดสำหรับแอปสำหรับรถยนต์

ดังนั้น หากแอปของคุณไม่เป็นไปตามหลักเกณฑ์การเสียสมาธิของผู้ขับ แอปจะถูกปฏิเสธ

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

สุดท้ายแต่ไม่ท้ายสุด เรามี Wear OS

ดังนั้น แอป Wear OS อาจถูกปฏิเสธหากไม่ได้เพิ่มประสิทธิภาพและจัดรูปแบบให้เหมาะกับจอแสดงผลทรงกลมขนาดเล็ก

ดังนั้นเราขอแนะนำให้ใช้ Compose สำหรับ Wear OS เวอร์ชันเสถียรล่าสุด เพื่อให้แน่ใจว่าเนื้อหาจะไม่ถูกตัดออกที่ขอบบนอุปกรณ์ขนาดต่างๆ หรือเพื่อให้แน่ใจว่าแถบเลื่อนจะปรากฏขึ้นเมื่อมีเนื้อหาที่เลื่อนได้ เป็นต้น

@Composable
fun MyText() {
  Text(
    text = stringResource(R.string.compose_for_wear_os),
    modifier = Modifier.fillMaxWidth(),
    textAlign = TextAlign.Center,
    style = MaterialTheme.typography.titleLarge
  )
}

และเช่นเดียวกับที่เรากล่าวถึงสำหรับ Android Automotive OS แอป Wear OS อาจถูกปฏิเสธเนื่องจากไม่มีภาพหน้าจอ Wear OS หรือภาพหน้าจอไม่ถูกต้อง

ตัวอย่างที่ดีของภาพหน้าจอจากข้อมูลผลิตภัณฑ์ใน Google Play Store สำหรับแอปตัวอย่าง Androidify ซึ่งเป็นไปตามข้อกำหนด

ดังนั้นโปรดส่งภาพหน้าจออย่างน้อย 1 ภาพที่แสดงแอปของคุณทำงานบนอุปกรณ์ Wear OS

สิ่งที่ได้เรียนรู้

อ่านหลักเกณฑ์ด้านคุณภาพของแอปสำหรับรูปแบบของอุปกรณ์ที่เฉพาะเจาะจงและทดสอบตามหลักเกณฑ์ดังกล่าวก่อนส่ง

และเคล็ดลับสำคัญบางประการ

หากแอปของคุณกำหนดให้ต้องเข้าสู่ระบบ คุณต้องระบุบัญชีเดโมที่ใช้งานอยู่และข้อมูลเข้าสู่ระบบที่ถูกต้องในส่วนการเข้าถึงแอปของ Play Console

หากผู้ตรวจสอบของเราเข้าสู่ระบบไม่ได้ เราจะทดสอบแอปของคุณไม่ได้ และคุณจะถูกปฏิเสธโดยอัตโนมัติ

นอกจากนี้ อย่าลืมทำตามที่สัญญาไว้ด้วย

อย่าใช้แค่ภาพหน้าจอจากอุปกรณ์เคลื่อนที่

หากแอปพร้อมให้บริการสำหรับ Wear OS และ Android TV โปรดอัปโหลดภาพหน้าจอคุณภาพสูงสำหรับอุปกรณ์รูปแบบดังกล่าวใน Play Console

สุดท้ายแต่ไม่ท้ายสุดคือการอธิบายให้เห็นภาพ

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

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

ขอขอบคุณทุกคนที่สละเวลามาในวันนี้

เราหวังว่าจะได้เห็นประสบการณ์การใช้งานหลายอุปกรณ์ที่น่าทึ่งซึ่งคุณจะนำมาสู่ Google Play