Mua trong ứng dụng Android, phần 4: Mã lỗi billing library và cách để không làm hỏng thử nghiệm

Hôm nay chúng tôi sẽ nói về mã lỗi mà chúng ta có thể nhận được từ Billing Library trong phương thức getResponseCode().

Ví dụ về cách chuyển lỗi sang callback có tại bài viết này. Chúng ta đã xem xét một lỗi trong bài viết trước — đó là USER_CANCELED khi một người dùng đóng hộp thoại mua mà không mua hàng. Hãy cùng tìm hiểu các lỗi khác.

ERROR và DEVELOPER_ERROR

Hãy bắt đầu với lỗi có tên ERROR (responseCode 6) và DEVELOPER_ERROR (responseCode 5). Google đã viết trường hợp đầu tiên trong tài liệu “Lỗi nghiêm trọng trong hành động API”, trường hợp thứ hai trong – “Đối số không hợp lệ được cung cấp cho API”. Ví dụ: tôi có thể nhận một lỗi DEVELOPER_ERROR khi tôi chuyển một chuỗi trống đến trình tạo trong setType() cho yêu cầu querySkuDetailsAsync().

Nhưng vấn đề không đơn giản như vậy. Tôi tiếp tục tiến hành và trong phương thức launchBillingFlow(), tôi sử dụng SkuDetails đã sửa đổi (lấy json từ SkuDetails của sản phẩm thật, đổi productID trong json rồi chuyển productID sang hàm khởi tạo SkuDetails mới). Thực chất, đây là một đối số không hợp lệ và tôi dự kiến là mình sẽ nhận được DEVELOPER_ERROR, nhưng… tôi lại nhận được ERROR.

Đây rõ ràng là một ví dụ không thực tế. Trường hợp Google từ chối thanh toán giống với thực tế hơn nhiều. Nếu bạn chọn “test card, always declined” trong hộp thoại mua khi thử nghiệm giao dịch mua bằng thẻ thử nghiệm (chúng tôi sẽ chia sẻ về hoạt động này ở cuối bài viết) thì ERROR sẽ xuất hiện lại nhưng với văn bản thích hợp.

Trong bài viết thứ ba mô tả về thay đổi gói đăng ký, chúng tôi đã tăng giá gói đăng ký hàng năm lên gần gấp 3 lần đối với một trong các chế độ chia theo tỉ lệ, nhưng chưa chia sẻ về lỗi sẽ xuất hiện nếu không thực hiện như vậy. Bây giờ chúng tôi sẽ bổ sung thông tin này.

Vì nguyên do là chỉ định sai chế độ chia theo tỉ lệ nên theo logic, chúng tôi sẽ nhận được cùng một lỗi DEVELOPER_ERROR. Nhưng thay vào đó, chúng tôi nhận được SERVICE_UNAVAILABLE (responseCode 2). Chúng tôi cũng nhận được lỗi này khi nhập một con số không thích hợp bất kỳ làm chế độ chia theo tỉ lệ (đây là kiểu int, không phải kiểu enum, không ai có thể cản bước chúng tôi) và khi chỉ định purchaseToken sai. Chúng tôi xem tài liệu về SERVICE_UNAVAILABLE và… chờ đã, gì thể này?! Chúng tôi thấy “Mất kết nối mạng.”.

Đồng thời, chúng tôi cũng thấy một hộp thoại kỳ lạ:

Một điều thú vị khác trong trường hợp ERROR là khi KHÔNG dùng nút “OK” đóng hộp thoại (tức là bằng các cách thức được hiểu là “điều hướng quay lại”), ERROR xuất hiện trong onPurchasesUpdated() và trong trường hợp SERVICE_UNAVAILABLE trong một tình huống tương tự sẽ xuất hiện USER_CANCELED (nhưng nếu bạn nhấp “OK” trong hộp thoại, ta sẽ nhận được SERVICE_UNAVAILABLE như dự kiến).

Và trong trường hợp mất kết nối internet, thật vậy, sẽ xuất hiện SERVICE_UNAVAILABLE.

Mã lỗi

Sau đây là một số mã lỗi kèm ghi chú ngắn gọn và đề cập đáng chú ý.

• BILLING_UNAVAILABLE (responseCode 3). Google giải thích rằng “Phiên bản Billing API không được hỗ trợ cho loại đã yêu cầu”. Tôi có thể tái lập lỗi này khi đăng xuất khỏi tài khoản Google cũng như khi sử dụng thiết bị Huawei không có Google Play Services. Lỗi này cũng có thể được tái lập trên các dòng điện thoại cũ không được cập nhật Google Play.
• SERVICE_DISCONNECTED (responseCode -1). Ứng dụng đôi lúc bị mất kết nối với Google Play service. Lỗi này có thể xảy ra khi Play Store cập nhật bất ngờ. Do vậy, tôi khuyên bạn nên cẩn trọng và kết nối trước mỗi lần gọi phương thức Billing Library như trong bài viết trước. Đồng thời, chúng tôi và Google khuyên bạn nên thêm một số chính sách thử lại nếu lỗi này vẫn tiếp tục xảy ra trong phản hồi.
• SERVICE_TIMEOUT (responseCode -3). Cái tên nói lên tất cả — chúng tôi đã mất quá nhiều thời gian chờ phản hồi từ Google Play.
• TÍNH NĂNG KHÔNG ĐƯỢC HỖ TRỢ. Có năm hằng số FeatureType trong lớp BillingClient class. Có thể kiểm tra tính khả dụng của các hằng số trên thiết bị này bằng phương thức  BillingClient.isFeatureSupported(BillingClient.FeatureType.A_NECESSARY_FEATURE). Trên điện thoại của tôi (Xiaomi Mi A2 Lite), FEATURE_NOT_SUPPORTED chỉ xuất hiện lại đối với SUBSCRIPTIONS_ON_VR. Đồng thời, OK xuất hiện lại đối với IN_APP_ITEMS_ON_VR cũng như tất cả các tính năng khác.
• ITEM_NOT_OWNED (responseCode 8). Lỗi xảy ra khi cố tiêu hao giao dịch mua mà chúng ta không có. Có khả năng, thậm chí là lặp lại sau khi đã tiêu hao thành công.
• ITEM_ALREADY_OWNED (responseCode 7). Ngược lại, ở đây, lỗi xảy ra khi cố mua một sản phẩm chúng ta đã có. Trong trường hợp này, bạn chỉ cần cập nhật UI và chuyển nút mua sang trạng thái không thể nhấp.

ITEM_UNAVAILABLE

Lỗi cuối cùng và có lẽ phổ biến nhất khi bắt đầu lộ trình triển khai mua trong ứng dụng là ITEM_UNAVAILABLE (responseCode 4). Lỗi này có nghĩa là không có sẵn sản phẩm để mua nhưng không giải thích lý do. Có thể có nhiều lý do khác nhau: từ dùng sai tài khoản hoặc thiết bị để thử nghiệm đến mua phải sản phẩm không hoạt động.

Sau đây là danh sách kiểm tra gồm những việc bạn cần làm để tránh gặp lỗi này khi thử nghiệm:

1.   Gửi ứng dụng với Billing Library đến đường thử nghiệm của bạn. Đây là điều kiện bắt buộc; đồng thời, bạn cũng có thể thử nghiệm trên bản dựng gỡ lỗi có cùng một applicationId nhưng quan trọng là phải tải ứng dụng có Billing Library lên Play Console ít nhất một lần.

2.   Thêm tài khoản Google của người thử nghiệm vào đường thử nghiệm này. Đây là yếu tố cực kỳ quan trọng đối với thử nghiệm nội bộ hoặc thử nghiệm alpha/beta kín. Trong phần Cách người thử nghiệm tham gia thử nghiệm của bạn cũng có liên kết để người thử nghiệm nhận lời mời tham gia.

3.   Bạn chỉ có thể mua sản phẩm đã kích hoạt. Nút activate sẽ xuất hiện trong Play Console sau khi tạo ra một sản phẩm. Chúng tôi mô tả tiến trình tạo sản phẩm chi tiết hơn trong bài viết đầu tiên.

4.   Đảm bảo rằng thử nghiệm trên thiết bị diễn ra từ tài khoản Google của người thử nghiệm (có nghĩa là tài khoản phải được đăng ký là người thử nghiệm và phải có đầy đủ các quyền truy cập kỹ thuật cần thiết). Dù lời khuyên này có vẻ không cần thiết nhưng chuyện gì cũng có thể xảy ra và bạn cũng cần kiểm tra điểm này nếu nhận được lỗi tương tự.

5.   ApplicationId của bản dựng dùng trong thử nghiệm mua phải hoàn toàn khớp với applicationId trên Play Console. Điểm này đặc biệt quan trọng đối với những người thêm tiếp tố vào bản dựng gỡ lỗi.

6.   Thêm địa chỉ email của người thử nghiệm vào phần Setup → License Testing  trong menu bên trái của tài khoản (không phải ứng dụng) để người thử nghiệm mua sản phẩm miễn phí bằng thẻ thử nghiệm, không phải bằng thẻ thật. Một lợi thế khác là gói đăng ký trong trường hợp này sẽ có thời gian thử nghiệm. Thời gian thử nghiệm không liên quan đến lỗi này nhưng cũng là một kiến thức hữu ích.

Tổng kết

Lỗi có thể làm công việc trở nên vô cùng phức tạp. Do vậy, hiểu nguyên nhân gây ra lỗi luôn là điều quan trọng. Xem xét đến số bước bạn cần thực hiện để truy cập sản phẩm, cách dễ nhất là bắt ITEM_UNAVAILABLE. Do vậy, tôi hi vọng danh sách kiểm của tôi sẽ giúp ích cho bạn.

Adapty SDK sẽ tạo điều kiện thuận lợi cho việc xử lý lỗi và cung cấp nhiều lợi thế khác: phân tích gói đăng ký cơ bản, phân tích nhóm (cohort analysis), thử nghiệm tường phí (paywall) cơ bản, tích hợp với dịch vụ phân tích, xác thực lỗi máy chủ. Hãy thử ngay!