Tìm hiểu về chất lượng trên nhiều thiết bị và phát hành ứng dụng không chỉ cho thiết bị di động trên Google Play

Chào các bạn.

Cảm ơn bạn rất nhiều vì đã tham gia buổi chia sẻ này về cách cải thiện chất lượng ứng dụng trên nhiều thiết bị và phát hành ứng dụng trên Google Play cho các kiểu dáng khác ngoài thiết bị di động.

Tôi là Jan Kleinert, Kỹ sư quan hệ nhà phát triển trong nhóm Android cho Ô tô.

Tôi là Faustine Liao, Trưởng nhóm vận hành trong nhóm Niềm tin và An toàn của Play.

Chúng tôi rất vui khi được gặp mọi người trong buổi học hôm nay.

Vì vậy, trong nhiều năm, khi nói đến việc phát triển Android, hầu hết chúng ta đều chỉ hình dung ra một thiết bị di động, nhưng hệ sinh thái Android đã mở rộng ra ngoài phạm vi điện thoại thông minh.

Vì vậy, hiện nay, người dùng của bạn đang tương tác với các ứng dụng trong phòng khách trên Android TV, có thể là khi đi chung xe hoặc khi sạc xe trên Android Auto hoặc Automotive OS, trên cổ tay bằng Wear OS và ngày càng nhiều trong không gian 3D sống động bằng Android XR.

Đây là cơ hội phát triển rất lớn, nhưng việc mở rộng sang các kiểu dáng này đồng nghĩa với việc bạn chỉ cần cân nhắc một số yếu tố nhỏ trong chiến lược xuất bản của mình.

Nhìn chung, toàn bộ quy trình từ việc xây dựng ứng dụng đến việc phát hành và đưa ứng dụng lên Google Play vẫn giống như quy trình bạn thường làm cho các bản phát hành trên thiết bị di động.

Tạo và chuẩn bị ứng dụng, sau đó tạo trang thông tin trong Play Console, thử nghiệm ứng dụng, tải lên và gửi bản phát hành công khai, rồi chờ xem xét và phê duyệt.

Tuy nhiên, bạn cần lưu ý một số điểm riêng biệt khi phát hành ứng dụng cho các kiểu dáng thiết bị khác ngoài thiết bị di động.

Hôm nay, chúng tôi sẽ cung cấp cho bạn một khung rõ ràng để giúp bạn chuẩn bị cho quy trình phát hành mượt mà và dễ dự đoán hơn trên nhiều thiết bị.

Hãy bắt đầu từ nền tảng: cách thiết kế cấu trúc và đóng gói ứng dụng.

Vì vậy, trước khi sử dụng Google Play Console, bạn cần đưa ra một quyết định quan trọng về cấu trúc.

Bạn có tạo một gói ứng dụng hợp nhất duy nhất chứa mọi thứ cho tất cả các kiểu dáng mà bạn hỗ trợ không, hay bạn chia ứng dụng của mình thành các mô-đun dành riêng cho kiểu dáng và tạo Android App Bundle (AAB) cho từng mô-đun?

Vì vậy, khi nói đến mô-đun hoặc mô-đun hoá, tôi đang đề cập đến một phương pháp để cơ cấu toàn bộ mã nguồn theo cách cải thiện khả năng bảo trì.

Có nhiều phương pháp mô-đun hoá, nhưng nhìn chung, việc bạn đang làm là sắp xếp toàn bộ mã nguồn thành các phần độc lập, được liên kết lỏng lẻo, trong đó mỗi phần là một mô-đun.

Vì vậy, mặc dù phương pháp gói ứng dụng Android hợp nhất có vẻ dễ quản lý hơn, nhưng bạn nên sử dụng phương pháp mô-đun.

Sau đây là một ví dụ minh hoạ lý do chúng tôi đề xuất phương pháp mô-đun này.

Hãy tưởng tượng bạn có một ứng dụng hỗ trợ cả thiết bị di động và Android TV.

Nếu bạn gửi một gói ứng dụng Android duy nhất trên kênh phát hành tiêu chuẩn cho thiết bị di động và ứng dụng cho Android TV của bạn không vượt qua được quy trình xem xét, thì toàn bộ bản phát hành sẽ bị tạm dừng.

Vì vậy, điều này sẽ ảnh hưởng đến cả việc phát hành ứng dụng cho Android TV và ứng dụng di động của bạn.

Vì vậy, ngay cả khi ứng dụng di động của bạn không có vấn đề gì, bạn vẫn cần phải giải quyết các vấn đề khiến ứng dụng Android TV không vượt qua được quy trình xem xét, sau đó gửi lại ứng dụng để chúng tôi xem xét trước khi có thể cung cấp bản phát hành cho người dùng.

Mặt khác, Android App Bundle theo mô-đun cho từng hệ số hình dạng sẽ giúp bạn kiểm soát chi tiết hơn và tách biệt các bản phát hành cho hệ số hình dạng đó khỏi bản phát hành cho thiết bị di động.

Thay vào đó, nếu có các mô-đun ứng dụng riêng biệt cho ứng dụng di động và ứng dụng truyền hình, bạn có thể tạo các gói ứng dụng Android riêng biệt cho từng mô-đun.

Sau đó, nếu có vấn đề trong quá trình xem xét ứng dụng truyền hình, thì chỉ bản phát hành của ứng dụng đó mới bị chặn cho đến khi bạn có thể giải quyết vấn đề.

Bản phát hành của ứng dụng di động sẽ được xuất bản như dự kiến.

Như tôi đã đề cập trước đó, có nhiều phương pháp mô-đun hoá.

Sau đây là một ví dụ về phương pháp mô-đun hoá ứng dụng sách nói có trải nghiệm trên thiết bị di động và trải nghiệm trên Android Automotive OS.

Vì vậy, ở trên cùng, màu xanh lục, chúng ta có một mô-đun ứng dụng cho mỗi kiểu dáng và điều này giúp tách biệt các phần phụ thuộc dành riêng cho nền tảng.

Sau đó, chúng ta có các mô-đun tính năng màu vàng, tương ứng với các phần riêng biệt trong chức năng của ứng dụng.

Các mô-đun dữ liệu có màu xanh dương, còn ở dưới cùng là các mô-đun cốt lõi hoặc phổ biến, thường được dùng để chứa mã mà các mô-đun khác thường xuyên sử dụng.

Sau đó, trong tệp cài đặt Gradle của dự án, bạn có thể thêm và thiết lập cấu hình Gradle nhiều mô-đun này để hỗ trợ loại mô-đun hoá này.

...

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")

Vì vậy, bạn sẽ tiếp tục sử dụng cùng một tên gói hoặc mã ứng dụng cho mỗi mô-đun và gói ứng dụng.

Phương pháp mô-đun này liên kết trực tiếp với chiến lược kênh của bạn trong Play Console.

Khi phát hành, bạn có kênh phát hành tiêu chuẩn cho thiết bị di động, nhưng chúng tôi cũng cung cấp các kênh phát hành dành riêng cho từng hệ số hình dạng.

Đối với Android TV, Android XR và Android Automotive OS, bạn có thể lựa chọn.

Bạn có thể phát hành cùng với ứng dụng di động hoặc sử dụng kênh chuyên biệt cho hệ số hình dạng của các thiết bị đó.

Tuy nhiên, có hai trường hợp ngoại lệ.

Đối với Wear OS, bạn phải sử dụng kênh Wear OS chuyên biệt.

Còn đối với Android Auto, vì về cơ bản, đây là một tiện ích của ứng dụng di động được chiếu lên màn hình ô tô, nên lựa chọn duy nhất là kênh di động tiêu chuẩn.

Nếu bạn đang quản lý nhiều kênh, thì việc tạo phiên bản là rất quan trọng.

Một phương pháp là gán một vài chữ số đầu tiên của mã phiên bản cho hệ số hình dạng.

Ví dụ: 01 cho thiết bị di động, 02 cho Wear OS, 03 cho Android Automotive OS, v.v.

Nhìn chung, bạn nên đặt mã phiên bản có độ dài ít nhất là 7 chữ số để có thể sử dụng các chữ số còn lại cho phiên bản ứng dụng.

Điều này giúp ngăn chặn xung đột mã phiên bản trong Play Console.

Sau khi đóng gói ứng dụng, bạn có thể tiến hành kiểm thử.

Quá trình phát triển hệ số hình dạng đòi hỏi phải kiểm thử kỹ lưỡng và Google Play cung cấp cho bạn 3 kênh riêng biệt để thực hiện việc này trước khi phát hành công khai: kiểm thử nội bộ, kiểm thử khép kín và kiểm thử công khai.

Nếu đang sử dụng các kênh chuyên biệt cho hệ số hình dạng, bạn cũng có thể kết hợp các kênh thử nghiệm này với hệ số hình dạng của mình, giúp bạn kiểm soát quy trình một cách chi tiết hơn.

Ví dụ: bạn có thể có một bản phát hành thử nghiệm khép kín cho ứng dụng di động trên kênh tiêu chuẩn và một bản phát hành thử nghiệm khép kín riêng cho ứng dụng cho Android TV trên kênh chuyên biệt cho hệ số hình dạng Android TV, với các nhóm người thử nghiệm khác nhau nếu bạn muốn thiết lập theo cách đó.

Do đó, thử nghiệm nội bộ là một điểm khởi đầu tuyệt vời.

Kênh này giúp bạn nhanh chóng phân phối ứng dụng cho tối đa 100 người thử nghiệm và quan trọng là không kích hoạt quy trình xem xét của Play.

Điều này có nghĩa là bạn và người kiểm thử có thể nhanh chóng cài đặt ứng dụng trên thiết bị và xác thực trải nghiệm trên trình mô phỏng hoặc TV, đồng hồ hay thiết bị khác.

Và với thử nghiệm nội bộ, bạn sẽ nhận được một URL riêng biệt mà bạn có thể chia sẻ với những người kiểm thử đó.

Sau khi hài lòng với kết quả thử nghiệm nội bộ, bạn có thể chuyển sang thử nghiệm khép kín và thử nghiệm công khai.

Bạn có thể mở rộng phạm vi thử nghiệm ra ngoài thử nghiệm nội bộ bằng bản phát hành thử nghiệm khép kín. Bản phát hành này cho phép bạn thử nghiệm các phiên bản phát hành trước của ứng dụng trên một nhóm nhiều người thử nghiệm hơn để thu thập ý kiến phản hồi có chủ đích.

Bạn có thể quản lý các nhóm thử nghiệm khép kín dưới dạng danh sách địa chỉ email hoặc thông qua Google Groups.

Mặt khác, thử nghiệm công khai giúp bạn chạy thử nghiệm với một nhóm lớn hơn trên Google Play.

Bạn sẽ xuất hiện trên Google Play và bất kỳ ai cũng có thể tham gia chương trình thử nghiệm công khai.

Họ không cần lời mời và có thể chia sẻ ý kiến phản hồi, ý kiến phản hồi riêng tư với bạn về ứng dụng.

Các kênh thử nghiệm công khai và khép kín này sẽ kích hoạt quy trình xem xét.

Đây thực ra là một lợi thế rất lớn.

Nhờ đó, bạn có thể thử nghiệm quy trình xem xét và giải quyết mọi trở ngại trước ngày ra mắt mà bạn rất mong đợi.

Nói về quy trình xem xét, hãy cùng tìm hiểu một chút về những việc cần làm trong quy trình này và lý do quy trình này quan trọng.

Về cơ bản, các chính sách và nguyên tắc này đều xoay quanh chất lượng ứng dụng.

Do đó, ứng dụng và trò chơi chất lượng cao mang lại giá trị cho người dùng, khiến họ cảm thấy vui thích khi sử dụng, khai thác được tối đa các thiết bị cao cấp, cũng như được thiết kế để đảm bảo an toàn.

Vì vậy, hãy cùng tìm hiểu cách bạn có thể chuẩn bị ứng dụng để vượt qua quy trình xem xét một cách dễ dàng nhất có thể.

Tôi nghĩ rằng điểm khởi đầu tốt nhất là xem xét Nguyên tắc về chất lượng ứng dụng, trong đó tập trung vào trải nghiệm người dùng tuyệt vời.

Chúng tôi phát hành Nguyên tắc về chất lượng ứng dụng cốt lõi áp dụng cho tất cả ứng dụng và xác định chất lượng tối thiểu mà tất cả ứng dụng phải đáp ứng, cũng như Nguyên tắc về chất lượng ứng dụng thích ứng. Những nguyên tắc này sẽ giúp bạn đảm bảo rằng ứng dụng của mình mang lại trải nghiệm tuyệt vời bất kể kiểu dáng thiết bị, kích thước màn hình hay chế độ hiển thị.

Hai bộ nguyên tắc này là điểm khởi đầu rất tốt.

Tuy nhiên, chúng tôi cũng có Nguyên tắc về chất lượng ứng dụng dành riêng cho từng hệ số hình dạng.

Nhân viên đánh giá của chúng tôi sẽ kiểm thử ứng dụng của bạn trên thiết bị thực và trình mô phỏng theo các nguyên tắc này.

Vì vậy, bạn cần đảm bảo ứng dụng của mình tuân thủ các chính sách này.

Sau đây là thông tin tổng quan nhanh về những lý do phổ biến nhất khiến ứng dụng bị từ chối cho từng hệ số hình dạng.

Tuy nhiên, xin lưu ý rằng đây chưa phải là danh sách đầy đủ tất cả các nguyên tắc về Chất lượng ứng dụng.

Vì vậy, hãy nhớ xem kỹ các nguyên tắc về chất lượng cho từng hệ số hình dạng mà bạn làm việc để có được bộ tiêu chí mạnh mẽ hơn.

Hãy bắt đầu với Android TV.

Vì vậy, ở cuối các trang trình bày này, bạn sẽ thấy một đường liên kết ngắn đưa bạn đến danh sách đầy đủ các Nguyên tắc về chất lượng ứng dụng cho hệ số hình dạng đó.

Một lý do phổ biến khiến ứng dụng cho Android TV bị từ chối là thiếu hình ảnh biểu ngữ trên màn hình chính cho mỗi ngôn ngữ mà ứng dụng hỗ trợ.

Vì vậy, bạn nên cung cấp một hình ảnh có kích thước 320 x 180 pixel, trong đó có văn bản được bản địa hoá để nhận dạng ứng dụng của bạn.

Hình ảnh trên trang trình bày này cho thấy một ví dụ về biểu ngữ trên màn hình chính tuân thủ các tiêu chí đó.

Thứ hai, trên hầu hết TV, người dùng sẽ tương tác với thiết bị bằng điều khiển từ xa D-pad.

Vì vậy, điều quan trọng là bạn phải hỗ trợ đúng cách cho tính năng điều hướng và lấy tiêu điểm bằng D-pad.

Hãy đảm bảo rằng bạn hỗ trợ ít nhất các chế độ điều khiển tối thiểu của D-pad để tránh bị từ chối dựa trên các tiêu chí đó.

Lý do phổ biến thứ ba khiến ứng dụng cho Android TV bị từ chối là do thiếu bộ lọc ý định CATEGORY_LEANBACK_LAUNCHER trong tệp kê khai 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>

Bộ lọc này sẽ xác định ứng dụng của bạn là ứng dụng được bật cho TV và cho phép Google Play cũng xác định ứng dụng đó là ứng dụng truyền hình cho người dùng.

Vì vậy, khi người dùng chọn ứng dụng của bạn trên màn hình chính của TV, ý định này sẽ xác định hoạt động cần khởi chạy.

Vì vậy, hãy nhớ thêm quyền này vào tệp kê khai.

Tiếp theo là Android XR.

Khi xây dựng ứng dụng cho kính XR hoặc kính thông minh XR chạy Android XR, hãy đặc biệt chú ý đến hiệu suất, khả năng kết xuất và độ ổn định của ứng dụng.

Bạn có thể sử dụng Perfetto để phân tích hiệu suất của các ứng dụng được xây dựng bằng Jetpack XR SDK nhằm đảm bảo bạn tuân thủ các yêu cầu về tốc độ khung hình tối thiểu.

Nếu đang xây dựng bằng một công cụ theo thời gian thực như Unity, bạn có thể sử dụng các công cụ phân tích tích hợp sẵn của công cụ đó để đảm bảo rằng bạn tuân thủ các yêu cầu về kết xuất.

Tiếp theo là ô tô, bao gồm cả Android Auto và Android Automotive OS.

Đối với Android Auto và Android Automotive OS, có một khái niệm về danh mục, đây là một khái niệm khá đặc biệt đối với kiểu dáng cụ thể này.

Và chỉ một số danh mục ứng dụng nhất định mới được phép phát hành cho ô tô.

Vì vậy, nếu bạn gửi một ứng dụng vào danh mục không phù hợp với một trong những danh mục mà chúng tôi hỗ trợ, hoặc nếu bạn gửi một ứng dụng vào kênh thử nghiệm công khai hoặc phát hành công khai cho một danh mục chỉ đang trong giai đoạn thử nghiệm beta, thì ứng dụng đó sẽ bị từ chối.

Hãy để tôi giải thích rõ hơn về điều này.

Ở đây, bạn có thể xem thông tin tổng quan về các danh mục ứng dụng được hỗ trợ trên ô tô cho từng nền tảng, cùng với phạm vi cung cấp.

Cho dù tính năng đó đang ở giai đoạn thử nghiệm, phát hành công khai (tức là giai đoạn phát hành rộng rãi) hay chưa được hỗ trợ (được biểu thị bằng trạng thái "sắp ra mắt").

Vì vậy, một số danh mục như ứng dụng điều hướng hoặc ứng dụng địa điểm yêu thích được cung cấp rộng rãi, tức là bất kỳ ai cũng có thể phát hành ứng dụng trong một trong các danh mục đó lên giai đoạn phát hành rộng rãi cho ô tô.

Tuy nhiên, các danh mục khác như ứng dụng gọi điện liên lạc cho Android Auto đang ở giai đoạn thử nghiệm.

Vì vậy, đối với những danh mục đó, bạn có thể phát hành lên kênh thử nghiệm nội bộ hoặc kênh thử nghiệm khép kín, nhưng không thể phát hành công khai trừ phi bạn đã được chấp nhận tham gia một trong các chương trình tiếp cận sớm của chúng tôi cho danh mục đó.

Bạn có thể tìm hiểu thêm thông tin chi tiết về vấn đề đó và nhiều nội dung khác trong hướng dẫn dành cho nhà phát triển Android cho Ô tô.

Đó là nơi bạn có thể tìm thấy các đường liên kết để đề cử bản thân tham gia các chương trình tiếp cận sớm đó.

Thông số kỹ thuật bị thiếu hoặc không chính xác cho ảnh chụp màn hình Android Automotive OS là một lý do phổ biến khác khiến ứng dụng bị từ chối.

Vì vậy, khi cung cấp ảnh chụp màn hình Android Automotive OS, bạn cần đảm bảo rằng bạn có ít nhất 2 ảnh chụp màn hình theo hướng dọc và ít nhất 2 ảnh chụp màn hình theo hướng ngang với kích thước được liệt kê tại đây.

Bạn có thể dùng trình mô phỏng Android Automotive OS để chụp ảnh màn hình.

Công cụ này được thiết lập để chụp ảnh màn hình có kích thước phù hợp với nhu cầu của bạn.

Và cuối cùng, an toàn là yếu tố tối quan trọng đối với các ứng dụng dành cho ô tô.

Vì vậy, nếu ứng dụng của bạn không tuân thủ các nguyên tắc về sự phân tâm của người lái xe, thì ứng dụng đó sẽ bị từ chối.

Ví dụ: ứng dụng video phải tạm dừng phát và không được hiển thị khi xe đang di chuyển.

Cuối cùng nhưng không kém phần quan trọng, chúng ta có Wear OS.

Vì vậy, ứng dụng Wear OS có thể bị từ chối nếu không được tối ưu hoá và định dạng cho màn hình tròn, nhỏ.

Vì vậy, bạn nên sử dụng phiên bản ổn định mới nhất của Compose cho Wear OS để đảm bảo rằng nội dung sẽ không bị cắt ở các cạnh trên các thiết bị có kích thước khác nhau hoặc để đảm bảo rằng thanh cuộn xuất hiện khi có nội dung có thể cuộn.

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

Tương tự như những gì chúng tôi đã đề cập về Android Automotive OS, ứng dụng Wear OS cũng có thể bị từ chối nếu thiếu ảnh chụp màn hình Wear OS hoặc ảnh chụp màn hình không chính xác.

Sau đây là một ví dụ hay về ảnh chụp màn hình trong trang thông tin trên Cửa hàng Google Play cho ứng dụng mẫu Androidify. Ảnh chụp màn hình này đáp ứng các yêu cầu.

Vì vậy, hãy nhớ gửi ít nhất một ảnh chụp màn hình cho thấy ứng dụng của bạn đang chạy trên thiết bị Wear OS.

Bài học rút ra là gì?

Hãy đọc nguyên tắc về chất lượng ứng dụng cho hệ số hình dạng cụ thể của bạn và kiểm thử theo các nguyên tắc đó trước khi gửi.

Ngoài ra, còn có một số mẹo quan trọng.

Nếu ứng dụng của bạn yêu cầu đăng nhập, thì bạn phải cung cấp một tài khoản minh hoạ đang hoạt động và thông tin đăng nhập hợp lệ trong phần quyền truy cập vào ứng dụng trên Play Console.

Nếu nhân viên đánh giá của chúng tôi không thể đăng nhập, thì chúng tôi không thể thử nghiệm ứng dụng của bạn và ứng dụng đó sẽ tự động bị từ chối.

Ngoài ra, hãy nhớ thực hiện đúng những gì bạn hứa hẹn.

Đừng chỉ sử dụng ảnh chụp màn hình trên thiết bị di động.

Nếu ứng dụng của bạn hoạt động trên Wear OS và Android TV, hãy nhớ tải ảnh chụp màn hình chất lượng cao cho các hệ số hình dạng cụ thể đó lên Play Console.

Cuối cùng nhưng không kém phần quan trọng, hãy mô tả chi tiết.

Cho người dùng biết chính xác chức năng của ứng dụng, lý do khiến ứng dụng mang lại giá trị và những điều mà người dùng có thể mong đợi khi cài đặt ứng dụng trên từng loại thiết bị.

Tóm lại, việc tiếp cận người dùng ở hầu hết mọi nơi họ đến là một cơ hội tuyệt vời. Bằng cách thiết kế theo mô-đun, tận dụng thử nghiệm nội bộ để lặp lại nhanh chóng, thiết kế theo nguyên tắc về chất lượng của hệ số hình dạng và tối ưu hoá trang thông tin trên Cửa hàng Play, bạn sẽ giúp ứng dụng của mình sẵn sàng cho quá trình ra mắt và xem xét suôn sẻ hơn.

Cảm ơn các bạn đã dành thời gian tham gia buổi hôm nay.

Chúng tôi rất mong chờ được thấy những trải nghiệm tuyệt vời trên nhiều thiết bị mà các bạn sẽ mang đến Google Play.