App TWA bị từ chối trên Google Play? Hãy chuyển sang WebView

Đây là một trong những lần bị từ chối gây khó chịu nhất với nhà phát triển độc lập. Tester của bạn thực sự đã hoạt động. Bạn có đủ 12 người. 14 ngày đã trôi qua. Nhưng Google vẫn phản hồi rằng "your testers were not engaged enough." Nếu app được xây dưới dạng Trusted Web Activity (TWA) hoặc app bọc PWA, bạn không hề tưởng tượng ra quy luật này. Trong 7.400+ app chúng tôi đã tiếp nhận, bản dựng dạng wrapper gặp lỗi từ chối cụ thể này thường xuyên hơn nhiều so với bản dựng native tiêu chuẩn hoặc WebView. Hướng dẫn này giải thích nguyên nhân, cho thấy khác biệt kiến trúc quan trọng và chỉ cách chuyển sang WebView mà không mất những ngày thử nghiệm đã tích lũy.

Vì sao app TWA gặp lỗi bị từ chối trong thử nghiệm khép kín?

Trusted Web Activity hiển thị trang web qua bề mặt Chrome Custom Tabs thay vì vẽ màn hình trong chính app của bạn. Đây là cách nhanh để biến trang web hoặc PWA thành thứ có thể cài đặt, và nhiều app trên kênh phát hành công khai vẫn hoạt động tốt. Rắc rối xuất hiện khi tài khoản nhà phát triển cá nhân phải hoàn thành yêu cầu thử nghiệm khép kín bắt buộc trong 14 ngày trước khi đăng ký quyền truy cập vào kênh phát hành công khai.

Qua kinh nghiệm hỗ trợ 7.400+ app trong quy trình này, chúng tôi thấy bản dựng TWA và app bọc PWA gặp thông báo từ chối "testers were not engaged" thường xuyên hơn nhiều so với app native tiêu chuẩn, ngay cả khi tester thực sự hoạt động mỗi ngày. Quy luật đủ nhất quán để chúng tôi khuyên nhà phát triển tránh TWA khi app vẫn phải hoàn thành thử nghiệm khép kín 14 ngày.

TWA thực sự là gì và được xây như thế nào?

Trước khi sửa lỗi bị từ chối, bạn cần hiểu chính xác mình đã phát hành gì. Trusted Web Activity là app Android mà về bản chất là trang web của bạn chạy toàn màn hình trong một công cụ trình duyệt thực. Không có thanh địa chỉ, không có giao diện trình duyệt và không có dấu hiệu cho người dùng biết họ đang xem trang web. Với người dùng, nó trông và hoạt động như app native. Bên dưới, đó vẫn là trang web đang hoạt động của bạn.

TWA thường được tạo bằng CLI Bubblewrap của Google hoặc PWABuilder, cả hai đều nằm trên thư viện androidbrowserhelper của Google. Bạn trỏ công cụ tới một URL, nó tạo dự án Android, sau đó bạn ký và tải AAB lên Google Play.

Vì sao nhà phát triển chọn TWA?

Sự đánh đổi dẫn đến bị từ chối

Chính yếu tố giúp TWA rẻ và nhanh lại khiến nó mong manh trong thử nghiệm khép kín:

• TWA cần Internet. Nó là cửa sổ nhìn vào trang web, nên kết nối yếu tạo ra trải nghiệm app yếu nếu PWA không có hỗ trợ ngoại tuyến vững chắc.
• Nguy cơ bị Play Store từ chối. Chính sách Chức năng tối thiểu và nội dung được đóng gói lại nhắm vào app chỉ là trang web nằm trong một lớp bọc. TWA không có năng lực native thực có thể bị từ chối hoặc gỡ bỏ, nhất là với lần gửi mới. Thêm thông báo đẩy, chế độ ngoại tuyến, camera hoặc mục tiêu chia sẻ giúp app có giá trị native thật.
• Vấn đề tín hiệu tương tác đã nêu ở trên giải thích vì sao tài khoản cá nhân phải chạy thử nghiệm khép kín 14 ngày thường gặp thông báo "testers not engaged".

Hiểu lầm phổ biến: TWA không phải WebView

Đây là phần nhiều bài viết giải thích sai. Cần nói chính xác vì sự khác biệt này quyết định cách bạn sửa vấn đề. TWA hoàn toàn không dùng thành phần WebView của Android.

Vì TWA dùng công cụ phía sau Custom Tabs, bạn có cùng công cụ kết xuất, công cụ JavaScript và vùng cách ly bảo mật như trình duyệt Chrome thực, cộng thêm cookie và bộ nhớ dùng chung với Chrome. Người đã đăng nhập trên web vẫn giữ trạng thái đăng nhập. Bạn cũng nhận cập nhật trình duyệt tự động và hỗ trợ đầy đủ nền tảng web. Điều đó rất mạnh với app đã phát hành bình thường, nhưng cũng có nghĩa là màn hình chạy ngoài tiến trình, bên trong Chrome, không nằm trong app của bạn. Đây là gốc của cả sự suy giảm tín hiệu tương tác lẫn số người dùng hoạt động thấp.

Luồng khởi chạy theo từng bước

Kiểm tra độ tin cậy bằng Digital Asset Links

Chrome chỉ bỏ thanh địa chỉ khi app chứng minh được quyền sở hữu trang web bằng Digital Asset Links. App khai báo trang web đại diện, còn trang web phải cung cấp tệp tại /.well-known/assetlinks.json có tên package của app và vân tay SHA-256 của chứng chỉ ký.

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.yourapp.name",
    "sha256_cert_fingerprints": [
      "AB:CD:EF:...:99"  // your signing cert SHA-256
    ]
  }
}]

Đường đi của tín hiệu tương tác: TWA vs WebView

Cách đơn giản nhất để hiểu lỗi bị từ chối là theo dõi hoạt động của tester thực sự đi đâu. Trong TWA, màn hình nằm cách app một lớp, bên trong bề mặt Chrome Custom Tabs. Trong app WebView, cùng các màn hình đó chạy trong tiến trình của chính app và được quy trực tiếp cho package. Khác biệt duy nhất này làm thay đổi độ mạnh của tín hiệu được ghi nhận.

Cách nhận biết TWA từ bên ngoài và bên trong

Không chắc app bạn hoặc nhà thầu đã phát hành có thực sự là TWA hay không? Đây là cách xác nhận, trước tiên bằng mắt thường, sau đó kiểm tra dứt điểm từ APK hoặc thiết bị đã kết nối.

Dấu hiệu trực quan nhanh với người dùng

• App hoạt động giống hệt trang web vì bản chất nó chính là trang web.
• Nếu nhà phát triển cấu hình sai, bạn sẽ thấy thanh địa chỉ trình duyệt ở phía trên. Đây là dấu hiệu rất rõ, liên quan đến lỗi assetlinks đã nêu.
• Nội dung cập nhật mà không có bản cập nhật app trên Play Store.

Dấu hiệu kỹ thuật xác định khi kiểm tra APK hoặc thiết bị

Xác nhận bằng adb

Trên thiết bị hoặc trình giả lập đã kết nối, hai lệnh sau sẽ cho câu trả lời:

# Is it a TWA? Look for the delegation service:
adb shell dumpsys package <package.name> | grep -i DelegationService

# Which site does it wrap, and is the trust check passing?
adb shell pm get-app-links <package.name>
#   -> "verified"  = Digital Asset Links pass (fullscreen)
#   -> "1024"      = verification failed (address bar shows)

TWA vs WebView trong thử nghiệm khép kín: so sánh trực tiếp

Cả hai kiến trúc đều bọc nội dung web. Khác biệt quan trọng với thử nghiệm khép kín 14 ngày nằm ở nơi nội dung chạy và cách hoạt động được quy về app. Dưới đây là so sánh theo những tiêu chí quyết định liệu bạn có thể tiến tới kênh phát hành công khai trong một chu kỳ hay không.

Cách sửa: xây app WebView tiêu chuẩn

Thay vì vá TWA hoặc cố ép nó tạo tín hiệu tốt hơn, con đường gọn nhất là dựng lại app quanh một thành phần WebView và phát hành bản dựng đó. Có ba cách phổ biến, tất cả đều tải trang web trong chính app của bạn:

Thiết lập WebView tối thiểu, sẵn sàng sao chép

Phần cốt lõi rất nhỏ: một WebView tải URL khi JavaScript và bộ nhớ đã bật, giữ điều hướng bên trong app thay vì bật sang Chrome, đồng thời nối trình xử lý nút Quay lại mà quá trình xem xét của Google mong đợi. Chọn ngôn ngữ của bạn và sao chép cấu hình cơ sở:

val webView = findViewById<WebView>(R.id.webview)
webView.settings.apply {
    javaScriptEnabled = true          // most sites need this
    domStorageEnabled = true          // localStorage / sessionStorage
    cacheMode = WebSettings.LOAD_DEFAULT
}

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.webViewClient = WebViewClient()
webView.loadUrl("https://yourwebsite.com")

// The exact back-button handler Google looks for
onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
    override fun handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack()
        } else {
            finish()
        }
    }
})

WebView webView = findViewById(R.id.webview);
WebSettings settings = webView.getSettings();
settings.setJavaScriptEnabled(true);      // most sites need this
settings.setDomStorageEnabled(true);      // localStorage / sessionStorage
settings.setCacheMode(WebSettings.LOAD_DEFAULT);

// Keep links INSIDE the app (this is the key difference vs a TWA)
webView.setWebViewClient(new WebViewClient());
webView.loadUrl("https://yourwebsite.com");

// The exact back-button handler Google looks for
getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) {
    @Override
    public void handleOnBackPressed() {
        if (webView.canGoBack()) {
            webView.goBack();
        } else {
            finish();
        }
    }
});

# Wrap an existing web/PWA project in a native WebView shell
npm install @capacitor/core @capacitor/cli
npx cap init "YourApp" "com.yourapp.name"

# Point Capacitor at your live site (capacitor.config.ts)
#   server: { url: "https://yourwebsite.com", cleartext: false }

npm install @capacitor/android
npx cap add android
npx cap sync

# Capacitor handles back-button + DOM storage natively.
# Open in Android Studio to build a signed AAB:
npx cap open android

Ba yếu tố phải thêm để vượt qua bước xem xét

WebView trần chỉ gọi loadUrl() vẫn là app bọc sơ sài. Ba phần bổ sung sau biến nó thành app thực và giúp tester không gặp màn hình trống:

Cách chuyển đổi mà không đặt lại đồng hồ 14 ngày

Nếu đã đi được một phần chu kỳ thử nghiệm, bạn không phải bắt đầu lại. Bộ đếm 14 ngày vẫn tiếp tục qua bản cập nhật app, miễn là bạn dùng cùng kênh thử nghiệm và giữ nguyên tên package. Đây là cách di chuyển an toàn:

App WebView có vẫn bị xem là "lớp bọc sơ sài" không?

Đây là cái bẫy với nhà phát triển cho rằng WebView là giải pháp thần kỳ. Chuyển từ TWA sang WebView xử lý vấn đề tín hiệu tương tác, nhưng không miễn cho bạn khỏi chính sách Nội dung rác và Chức năng tối thiểu của Google. WebView chỉ đặt trang chủ trong một khung vẫn có thể bị từ chối vì là app bọc sơ sài, giống như TWA trần.

Hãy coi đây là hai cánh cửa riêng biệt. Dịch vụ thử nghiệm hoặc bản dựng WebView có thể giúp bạn qua một cửa, nhưng không thể tự động xử lý cửa còn lại.

Vì vậy, mục tiêu không chỉ là "WebView thay cho TWA" mà là một app WebView có đủ giá trị và hành vi native để đứng độc lập. Trên thực tế, điều đó có nghĩa là:

Muốn có checklist sâu hơn về các yếu tố gây từ chối vì chất lượng? Hướng dẫn vì sao thử nghiệm khép kín bị từ chối phân tích những lỗi chính sách và xem xét phổ biến ngoài vấn đề tương tác.

Không chắc app có phải TWA? Chúng tôi kiểm tra ngay khi bạn đặt hàng

Bạn không cần tự chạy lệnh adb hoặc đào sâu vào APK. PrimeTestLab có thể xác nhận app của bạn có phải TWA hay không. Ngay khi bạn đặt dịch vụ thử nghiệm, đội ngũ của chúng tôi kiểm tra bản dựng, xác định đó có phải TWA hoặc app bọc PWA hay không và, nếu đúng, cho bạn biết chính xác điều cần sửa trước khi đồng hồ 14 ngày bị lãng phí cho kiến trúc dễ bị gắn cờ vì tương tác.

Điều gì xảy ra ngay khi bạn đặt hàng?

PrimeTestLab hỗ trợ thế nào với nửa còn lại của vấn đề?

Kiến trúc là một nửa vấn đề. Nửa còn lại, cũng là phần cản trở nhiều nhà phát triển độc lập nhất, là tìm 12 tester thực sự chọn tham gia và duy trì tham gia trong 14 ngày liên tục. Đó là phần PrimeTestLab xử lý.

Chúng tôi cung cấp tester đã xác minh và chọn tham gia trên thiết bị Android thật. Họ giữ thử nghiệm khép kín hoạt động trong toàn bộ thời gian yêu cầu để một tester rời đi không làm đứt chuỗi 14 ngày. Bạn chia sẻ đường liên kết chọn tham gia; chúng tôi xử lý lời mời, xác minh chọn tham gia, theo dõi tương tác hằng ngày và duy trì đủ 14 ngày. Đã hỗ trợ 7.400+ app, với tỷ lệ thành công lần đầu 99,9%.

Các gói hiện tại

Cộng 5% phí dịch vụ · Thử nghiệm lại miễn phí hoặc hoàn tiền toàn bộ

Câu hỏi thường gặp

Kết luận