Giải mã chính sách của Play – AMA

Được rồi.

Cảm ơn mọi người đã tham gia buổi thảo luận này về việc giải mã chính sách của Google Play.

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

Tôi sẽ là người điều phối cho buổi thảo luận hôm nay.

Tôi xin nhường lời cho hai diễn giả Bohdan và Paul để họ tự giới thiệu.

Bohdan, hãy bắt đầu với bạn nhé.

Chào các bạn.

Tôi là Bohdan, làm việc tại bộ phận Tin cậy và An toàn của Google Play.

Tôi đã làm việc tại đây hơn 4 năm và có hơn 10 năm kinh nghiệm trong ngành an toàn và tin cậy về công nghệ.

Tôi thích quan sát cách công nghệ, ngành và văn hoá tương tác với nhau, cũng như cách các sự kiện khuyến khích việc phát triển ứng dụng mới. Tôi cũng thích những sự kiện như thế này, nơi chúng tôi có thể nỗ lực hết mình để giúp các nhà phát triển như bạn gặt hái thành công.

Chào các bạn!

Tôi là Paul.

Tôi làm việc cùng nhóm với Bohdan và tôi đã làm việc trong lĩnh vực tin cậy và an toàn trong khoảng thời gian tương đương với Bohdan, tức là khoảng một thập kỷ, và phần lớn thời gian đó là làm việc trong nhóm Tin cậy và an toàn của Google Play.

Vì vậy, tôi rất vui khi được đứng trên sân khấu hôm nay. Hãy cùng bắt đầu nào.

Được rồi, cảm ơn bạn.

Vì vậy, để chuẩn bị trước khi chúng ta bắt đầu buổi thảo luận, tôi sẽ nhường lại sân khấu cho Paul.

Anh ấy sẽ bắt đầu bằng thông tin tổng quan ngắn gọn về các tài nguyên chính sách, thông tin về các phương pháp hay nhất và những nội dung tương tự để giúp bạn chuẩn bị ứng dụng cho quy trình đánh giá việc tuân thủ chính sách suôn sẻ và hiệu quả hơn.

Vâng.

Vậy, chính sách của Play là gì?

Đây là những quy tắc cơ bản mà nhà phát triển phải tuân thủ khi phát hành và duy trì ứng dụng di động trên Cửa hàng Google Play.

Chúng tôi đã cung cấp một số đường liên kết ngắn trên màn hình để bạn truy cập vào các tài nguyên về chính sách của Play.

Đường liên kết đầu tiên sẽ đưa bạn đến trung tâm chính sách dành cho nhà phát triển.

Nếu nhấp vào mục Thông tin cập nhật gần đây ở đầu trang, bạn có thể đọc thông tin chi tiết về các chính sách mới, cũng như thông tin cập nhật hoặc nội dung làm rõ về các chính sách hiện có.

Nếu bạn thích học qua hình ảnh hoặc âm thanh, thì đường liên kết ngắn thứ hai sẽ đưa bạn đến danh sách phát Thông tin nhanh về chính sách.

Đây là những video chúng tôi nói về các nội dung cập nhật chính sách.

Cuối cùng, đường liên kết thứ ba sẽ đưa bạn đến một trang nơi bạn có thể tìm hiểu thêm về thông tin chi tiết về chính sách của Play trong Android Studio. Đây là một tính năng nhằm cung cấp hướng dẫn hữu ích trước khi xem xét, được cung cấp dưới dạng quy trình kiểm tra tìm lỗi mã nguồn trong Android Studio.

Được rồi.

Ngoài ra, còn có một kỹ năng Android giúp kiểm tra ứng dụng Android theo các chính sách này của Google Play, nhằm giúp bạn xác minh việc tuân thủ các quy định về quyền, xoá tài khoản và an toàn dữ liệu.

Bạn có thể cài đặt kỹ năng này bằng Android CLI giống như bất kỳ kỹ năng nào khác.

android skills list
android skills add play-policy-insights

Cuối cùng, trước khi bắt đầu trả lời một số câu hỏi của Jan, chúng tôi muốn chia sẻ một số phương pháp hay nhất để làm việc với chính sách của Play và quy trình xem xét ứng dụng.

Cách thứ nhất là cung cấp thông tin đăng nhập cho người đánh giá.

Có vẻ như đây là một lý do đơn giản, nhưng nội dung không truy cập được là một lý do rất phổ biến khiến việc phê duyệt bị chậm trễ hoặc bị từ chối.

Nếu ứng dụng của bạn yêu cầu đăng nhập, có nội dung bị khoá, có tín dụng hoặc gói thuê bao, thì bạn cần cung cấp thông tin đăng nhập thử nghiệm.

Đối với một số ứng dụng, điều này có nghĩa là cung cấp thông tin đăng nhập ngay khi bắt đầu ứng dụng, còn đối với những ứng dụng khác, bạn có thể có các phần khác nhau, chẳng hạn như nội dung có tính phí mà tôi đã đề cập.

Bạn có thể thực hiện việc này trong Play Console, sau đó cung cấp thông tin đăng nhập này cho nhân viên đánh giá của chúng tôi.

Trước đây, phần này có tên là Quyền truy cập vào ứng dụng, nhưng nay được gọi là Thông tin đăng nhập và nằm trong mục Nội dung ứng dụng.

Sau đó, bạn cần đảm bảo rằng thông tin đăng nhập bỏ qua mọi loại xác thực hai yếu tố, mã xác thực, tường phí, v.v.

Đúng vậy, hãy huỷ kích hoạt mã phiên bản cũ.

Vì vậy, nhà phát triển thường gặp phải tình trạng mà chúng tôi gọi là vòng lặp từ chối, vì họ tải một bản dựng công khai sạch và tuân thủ lên, nhưng họ thường quên rằng một phiên bản cũ hơn, không tuân thủ vẫn đang hoạt động trên Play Console ở một kênh khác, cho dù đó là thử nghiệm công khai, thử nghiệm khép kín, v.v. Vì vậy, ngay cả khi gói ứng dụng nằm trong một kênh thử nghiệm cũ, gói đó vẫn phải tuân thủ chính sách của Play và được xem xét theo chính sách của Play.

Vì vậy, nếu yêu cầu quyền bị hạn chế hoặc sử dụng SDK lỗi thời có lỗ hổng bảo mật, thì ứng dụng vẫn phải được xem xét.

Vì vậy, hãy nhớ thay thế hoặc huỷ kích hoạt tất cả mã phiên bản lỗi thời trên mọi kênh trước khi nhấn nút gửi.

Thứ ba, hãy dành nhiều thời gian cho quá trình xem xét và sử dụng tính năng xuất bản có quản lý.

Do đó, quá trình xem xét và phát hành ứng dụng có thể mất 7 ngày hoặc đôi khi lâu hơn, đặc biệt là đối với ứng dụng mới hoặc ứng dụng yêu cầu quyền truy cập thông tin nhạy cảm.

Vì vậy, bạn nên dành đủ thời gian thực hiện.

Nếu bạn có một đợt ra mắt lớn, hãy nhớ gửi ứng dụng mới đó ít nhất vài tuần trước ngày ra mắt thực tế.

Sau đó, bạn có thể liên kết bản phát hành đó với tính năng xuất bản có quản lý.

Xuất bản có quản lý là một tính năng cho phép giữ lại các bản cập nhật đã được phê duyệt cho đến khi bạn sẵn sàng phát hành, giúp ngăn chặn sự chậm trễ ngoài dự kiến trong các chiến dịch tiếp thị hoặc các đợt ra mắt quan trọng khác.

Và trong quá trình đó, bạn cần đảm bảo rằng mình không gửi lại ứng dụng sau khi đã gửi ứng dụng đi xem xét.

Vì nếu bạn làm vậy, thời gian sẽ bắt đầu tính lại từ đầu.

Tôi nghĩ đôi khi nhà phát triển quên mất điều đó và họ có một ứng dụng đang phát triển dở dang, rồi họ quên mất rằng "Ồ, mình phải thực hiện thay đổi nhỏ này".

Họ gửi lại và sau đó, quy trình xem xét sẽ bắt đầu lại từ đầu.

Đúng vậy, hãy kiểm tra nội dung khai báo của bạn.

Do đó, nội dung khai báo của ứng dụng (chẳng hạn như mục an toàn dữ liệu, chính sách quyền riêng tư hoặc quyền truy cập vào ảnh/video) phải khớp với tệp kê khai ứng dụng của các gói hoặc mã phiên bản đang hoạt động trên tất cả các kênh.

Ví dụ: nếu tệp kê khai ứng dụng của bạn yêu cầu quyền truy cập thông tin vị trí chính xác, nhưng biểu mẫu khai báo quyền của bạn không tiết lộ mục đích của quyền này, thì ứng dụng có thể hoặc rất có thể sẽ bị áp dụng biện pháp thực thi.

Vì vậy, hãy đảm bảo rằng SDK của bên thứ ba không lấy dữ liệu mà bạn chưa khai báo.

Ngay cả khi ứng dụng của bạn không sử dụng một phần dữ liệu cụ thể, nhưng nếu bạn chọn tích hợp một SDK có sử dụng phần dữ liệu đó, thì việc này có thể dẫn đến biện pháp thực thi.

Vì vậy, hãy xem Chỉ mục SDK của Google Play để biết thông tin chi tiết về hơn 100 SDK thương mại được sử dụng rộng rãi nhất.

Tôi xin phép ngắt lời để hỏi nhanh một câu trước khi chúng ta tiếp tục.

Vậy khi nói đến biện pháp thực thi, cụ thể là bạn muốn nói đến điều gì?

Thuật ngữ đó có nghĩa là gì?

Biện pháp thực thi có thể là bất kỳ hành động bất lợi nào, từ cảnh báo đến từ chối, cho đến các biện pháp thực thi nghiêm khắc hơn như xoá, tạm ngưng hoặc thậm chí là cấm tài khoản.

Vì vậy, khi tôi nói đến biện pháp thực thi, thì đó chính là những biện pháp xử lý mà tôi đang đề cập.

Chúng ta tìm hiểu tiếp nhé.

Cảm ơn bạn.

Vâng.

Và cuối cùng là sử dụng đơn kháng nghị.

Đừng chỉ gửi lại cùng một phiên bản sau khi bị từ chối.

Ngoài ra, việc bị từ chối nhiều lần do cùng một vấn đề trong một khoảng thời gian ngắn có thể kích hoạt một cảnh báo thuật toán, dẫn đến các biện pháp thực thi nghiêm ngặt hơn mà Paul đã đề cập, chẳng hạn như xoá hoặc tạm ngưng.

Vì vậy, nếu ứng dụng bị từ chối, đừng chỉ gửi lại ngay lập tức mà không thực hiện thay đổi, phỏng đoán hoặc giải quyết vấn đề nêu trong phản hồi.

Bạn sẽ nhận được thông báo trong cả hộp thư đến của Play Console và email liên kết mà bạn đã cung cấp, trong đó nêu rõ lỗi vi phạm và hướng dẫn.

Sau đó, nếu bạn không đồng ý hoặc có thể là không hiểu, nhưng giả sử bạn không đồng ý với quyết định từ chối, thì bạn sẽ kháng nghị, đúng không?

Nếu cho rằng đây là trường hợp dương tính giả, bạn có thể sử dụng đường liên kết trong thông báo để khiếu nại.

Và đó là bước đầu tiên tốt hơn so với việc vội vàng gửi lại mà không thực hiện bất kỳ thay đổi nào.

Tương tự, nếu bạn nhận được thông báo nhưng không hiểu rõ, có thể là do thông báo quá dài dòng hoặc có quá nhiều đoạn văn, thì bạn hoàn toàn có thể gửi đơn kháng nghị.

Khi đó, bạn sẽ trao đổi qua email với một người thật.

Mặc dù có thể có một số giới hạn về những thông tin mà họ có thể cung cấp, nhưng bạn thường có thể nhận được thêm thông tin chi tiết về nguyên nhân từ chối.

Đôi khi, nhóm kháng nghị hiểu rằng thông báo có thể khá dài.

Vì vậy, họ có thể đánh dấu hoặc in đậm những phần áp dụng riêng cho bạn và ứng dụng của bạn.

Vậy nên, đúng vậy.

Đến đây, tôi xin nhường lời lại cho Jan.

Được rồi.

Cảm ơn bạn.

Vì vậy, chúng tôi đã thu thập câu hỏi của các nhà phát triển từ nhiều kênh và nguồn khác nhau.

Vì vậy, những câu hỏi mà chúng ta có hôm nay đại diện cho một số vấn đề mà chúng tôi thường nghe từ các nhà phát triển khi nói đến chính sách.

Vậy hãy bắt đầu với điều này.

Một số lý do phổ biến khiến ứng dụng có thể bị từ chối liên quan đến quyền là gì?

Và làm thế nào để nhà phát triển tránh bị từ chối do vi phạm chính sách về quyền?

Được rồi.

Quyền, tôi sẽ trả lời câu hỏi đó.

Vì vậy, các quyền, cụ thể là quyền truy cập thông tin nhạy cảm, phải là yếu tố cốt lõi cho mục đích quan trọng của ứng dụng, tức là mục đích được quảng cáo của ứng dụng.

Vì vậy, nếu bạn có một tính năng bổ trợ hoặc một tính năng nào đó thậm chí không có trong ứng dụng và không được quảng cáo, thì rất có thể ứng dụng sẽ bị từ chối.

Vì vậy, hãy đảm bảo rằng nội dung khai báo khớp với trường hợp sử dụng của ứng dụng.

Ngoài ra, nhiều trường hợp ứng dụng bị từ chối là do đường liên kết đến video mà bạn cung cấp trong phần khai báo không truy cập được.

Nhóm xem xét của chúng tôi cần có quyền truy cập vào ứng dụng, các đường liên kết đến video mà bạn cung cấp, mọi nội dung trong ứng dụng để xem xét toàn bộ ứng dụng.

Vì vậy, bạn chỉ cần đảm bảo mọi thứ đều có thể truy cập được trong ứng dụng, tệp kê khai và trong phần khai báo.

Vì vậy, hãy đảm bảo rằng bạn đã hoàn thành ba mục đó và rất có thể, tôi không muốn nói là rất có thể, nhưng quá trình này sẽ diễn ra suôn sẻ hơn.

Chúng ta tìm hiểu tiếp nhé.

Được rồi.

Vậy nên, ngày càng có nhiều nhà phát triển ứng dụng bắt đầu sử dụng các nền tảng bên thứ ba để tạo nội dung do AI tạo trong ứng dụng của họ, đúng không?

Nếu những nền tảng đó tạo ra nội dung không phù hợp, không chính xác hoặc tương tự, thì điều đó có thể khiến ứng dụng của nhà phát triển bị từ chối không? Và ai thực sự chịu trách nhiệm trong những trường hợp như vậy?

Vâng.

Đúng vậy, điều này có thể khiến ứng dụng bị từ chối.

Kể từ khi Cửa hàng Play ra mắt, quan điểm của chúng tôi luôn là: bất cứ nội dung nào nhà phát triển đưa vào ứng dụng hoặc bất cứ nội dung nào người dùng có thể truy cập trong ứng dụng đều thuộc trách nhiệm của nhà phát triển.

Và mặc dù AI tạo sinh là một lĩnh vực mới, nhưng điều đó vẫn đúng.

Tôi nghĩ có một điểm tương đồng giữa AI tạo sinh và nội dung do người dùng tạo, đó là cả hai chính sách này đều yêu cầu bạn phải có nhiều biện pháp tương tự, chẳng hạn như gắn cờ nếu có nội dung không phù hợp xuất hiện.

Phải có cơ chế lọc.

Tôi nghĩ rằng tất nhiên là có những chính sách khác sẽ áp dụng, nhưng theo tôi, nếu bạn có nội dung do AI tạo sinh, thì Google sẽ xem xét ứng dụng, người dùng sẽ nhấp vào biểu tượng gắn cờ nếu họ thấy nội dung không phù hợp và bạn có cơ chế lọc của mình.

Vì vậy, Google, nhà phát triển và người dùng đều phải chung tay để giữ cho ứng dụng an toàn nhất có thể cho mọi người.

Được rồi.

Tuyệt vời.

Nhưng nhìn chung, ngoài việc cung cấp cơ chế để người dùng gắn cờ nội dung, chúng tôi có khuyến nghị nhà phát triển nên áp dụng một số biện pháp không? Đó có phải là ý của bạn về cơ chế lọc không?

Để ngăn một số loại nội dung nhất định xuất hiện cho người dùng ngay từ đầu?

Chính xác.

Vâng.

Vì vậy, trong quá trình xem xét, nhóm của chúng tôi sẽ không đi sâu vào và cố gắng tìm hiểu mã của bạn hoặc kỹ thuật đảo ngược cơ chế lọc chính xác của bạn.

Họ chỉ muốn xem liệu có thể truy cập vào nội dung không phù hợp hay không.

Và nếu họ có thể, thì chúng tôi sẽ gửi lại một số thông tin liên lạc, sau đó nhóm của bạn sẽ tìm cách cải thiện cơ chế lọc đó.

OK.

Tuyệt vời, cảm ơn bạn.

Ví dụ: một chính sách hiện có là chính sách về hành vi mạo danh hoặc bắt chước, đúng không?

Vậy nếu một ứng dụng bị từ chối theo chính sách mạo danh đó, nhưng nhà phát triển cho rằng đó là nhầm lẫn, vì bất kỳ lý do gì, thì họ nên làm gì?

Và làm cách nào để họ chủ động tránh bị từ chối theo kiểu đó?

Kháng nghị.

Đúng vậy, tôi nghĩ đó là phương pháp hay nhất thứ năm mà chúng tôi có trên bảng. Nếu bị từ chối vì lý do đó, bạn nên kháng nghị.

Sau đó, bạn nên làm gì? Trong trường hợp phổ biến nhất, thương hiệu mà bạn đang mạo danh có thể là thương hiệu của chính bạn, đúng không?

Hoặc bạn đang tạo một ứng dụng thay mặt cho người khác, và tôi cho rằng đây có lẽ là trường hợp phổ biến nhất, trong đó bạn có các nhà phát triển nhãn trắng đang tạo ứng dụng cho có thể là cơ sở thể dục, SaaS, bạn biết đấy, một loại giải pháp SaaS nào đó.

Và như vậy, nhưng việc xuất bản những ứng dụng đó trong tài khoản nhà phát triển của riêng bạn sẽ dễ dàng hơn, phải không?

Vì vậy, bạn có thể gửi đơn kháng nghị và nhóm của chúng tôi sẽ tìm kiếm bằng chứng về quyền sử dụng.

Giả sử bạn có một khách hàng tên là Joe's Chicken, và họ có món gà ngon nhất, bạn biết đấy, ở phía tây sông Mississippi.

Họ sẽ cung cấp cho bạn một thư chứng minh quyền, tức là trên giấy tiêu đề của công ty, giấy tiêu đề chính thức của công ty có biểu trưng của họ, trong đó ghi rằng: Chúng tôi, Joe's Chicken, cho phép ABC Developer sử dụng hình ảnh và chân dung của chúng tôi trong ứng dụng của họ. Tốt nhất là họ nên ghi tên ứng dụng và tên gói ứng dụng.

Bạn biết đấy, có thể là com.joeschicken.app hoặc gì đó, và sau đó, bạn có thể phản hồi nhà phát triển và cung cấp tài liệu đó.

Được rồi.

Và tôi nghĩ phần thứ hai là...

Họ có thể chủ động làm gì để tránh tình trạng đó không?

Ví dụ: bạn có thể tải lên giấy tờ chứng minh gì đó (tôi quên tên rồi) vào thời điểm gửi đơn kháng nghị lần đầu không?

Có.

Phải.

Trên Play Console, có một biểu mẫu mà chúng tôi gọi là biểu mẫu thông báo trước. Bạn có thể gửi biểu mẫu này và tải lên các loại giấy tờ liên kết tài khoản của bạn với pháp nhân kia.

Vì vậy, bằng cách này, bạn có thể chủ động bảo vệ ứng dụng mà bạn gửi khỏi các biện pháp thực thi bất lợi như vậy.

Đúng vậy.

Chúng ta tìm hiểu tiếp nhé.

Được rồi.

Bạn đã đề cập một chút về việc sử dụng SDK của bên thứ ba trong phần các phương pháp hay nhất, nhưng tôi muốn tìm hiểu thêm về vấn đề đó.

Vậy khi ứng dụng sử dụng SDK của bên thứ ba, có vẻ như nhà phát triển ứng dụng phải chịu trách nhiệm về cách các SDK của bên thứ ba đó sử dụng những thông tin như dữ liệu người dùng.

Vậy làm thế nào để nhà phát triển biết rằng SDK tuân thủ chính sách về an toàn dữ liệu và chính sách dữ liệu người dùng?

Ví dụ: làm thế nào để họ định hướng trong bối cảnh đó?

Đúng vậy, đó là một câu hỏi hay.

Trong 2 năm đầu làm việc tại Google, tôi đã làm việc rất nhiều với SDK. Điều này có liên quan đến câu hỏi trước đó về AI tạo sinh và nội dung do người dùng tạo, theo nghĩa là bất cứ nội dung nào trong ứng dụng của bạn, bạn biết đấy, cuối cùng đều là trách nhiệm của nhà phát triển.

Tôi nghĩ Paul đã đề cập nhanh, ngắn gọn trong phần giới thiệu rằng chúng tôi có một công cụ tên là Chỉ mục SDK của Google Play. Bạn có thể truy cập vào Google và nhập tên công cụ này.

Đó sẽ là kết quả đầu tiên hoặc thứ hai, Chỉ mục SDK của Google Play, và bạn sẽ thấy một trang web có hơn một trăm, có thể là vài trăm SDK được chia theo mục đích sử dụng, chẳng hạn như SDK để kiếm tiền, SDK cho quảng cáo, SDK cho sức khoẻ hoặc một mục đích khác.

Và trang đó chỉ lấy dữ liệu công khai.

Đây là sự kiện do Google tổ chức.

Nhưng bạn sẽ nhận thấy rằng khi xem các SDK này, bên cạnh một số SDK sẽ có huy hiệu cho biết SDK đó đã được đăng ký trong SDK Console.

Vì vậy, cũng giống như các nhà phát triển có Play Console cho ứng dụng của mình, nhà phát triển SDK có thể chọn sử dụng SDK Console.

Và họ phải trải qua một quy trình xem xét tương tự.

Họ gửi SDK cho chúng tôi.

Google sẽ thực hiện một số bước kiểm tra. Nếu doanh nghiệp vượt qua các bước kiểm tra này và tuân thủ chính sách, họ sẽ nhận được huy hiệu đó.

Giờ đây, với tư cách là nhà phát triển, bạn có thể truy cập vào chỉ mục đó và xem SDK nào đã vượt qua quy trình này.

Giờ đây, không có gì đảm bảo rằng ứng dụng sẽ được phê duyệt hoặc SDK sẽ không bao giờ không tuân thủ, nhưng tôi cho rằng điều này có thể mang lại hai điểm tin cậy.

Thứ nhất, khả năng ứng dụng không bị từ chối sẽ cao hơn nhiều nếu bạn sử dụng SDK đó.

Chỉ là xác suất thôi.

Điều thứ hai, và đây là điều tôi thực sự thích trong toàn bộ quy trình này, đó là nếu phát hiện SDK có nội dung không tuân thủ, chúng tôi sẽ áp dụng phương pháp tiếp cận hai hướng.

Đầu tiên, chúng tôi sẽ liên hệ với nhà phát triển SDK và nói rằng: "Chúng tôi nhận thấy SDK của bạn đang gửi dữ liệu người dùng theo cách không tuân thủ chính sách".

Sau đó, họ sẽ nỗ lực để đảm bảo ứng dụng hoặc SDK của mình tuân thủ chính sách.

Sau đó, vào khoảng cùng thời điểm hoặc có thể muộn hơn một chút, nhóm của chúng tôi sẽ gửi thông báo hoặc cảnh báo cho nhà phát triển.

Thông báo sẽ có nội dung như sau: "Xin chào, chúng tôi nhận thấy ứng dụng của bạn đang gửi dữ liệu đó theo cách không tuân thủ và chúng tôi nhận thấy điều đó đang xảy ra trong SDK ABC".

Vì vậy, các bước bạn có thể thực hiện với tư cách là nhà phát triển là chỉ cần cập nhật SDK lên bất kỳ phiên bản tuân thủ nào mà họ đã cung cấp.

Nếu muốn áp dụng biện pháp mạnh hơn, bạn có thể xoá hoặc thay thế SDK, nhưng tôi biết rằng việc đó tốn rất nhiều công sức và thời gian.

Nhưng đó chính là điều tôi thích ở Chỉ mục SDK của Google Play.

Vâng.

Chỉ mục không cho biết chính xác chính sách nào mà ứng dụng tuân thủ hoặc không tuân thủ, nhưng bạn sẽ nhận được huy hiệu đó và tôi gọi đó là một phiếu tín nhiệm.

Được rồi.

Vâng.

Được rồi, nghe hay đấy.

Và theo như tôi suy luận từ những gì bạn nói, nếu chúng tôi gửi thông báo cho nhà phát triển rằng "Bạn đang sử dụng SDK này và SDK này có vấn đề".

Chúng ta có cho họ biết nếu họ sắp cập nhật không? Chúng ta có cho họ biết phiên bản nào không? Nếu nhà phát triển khắc phục vấn đề, chúng ta có cho họ biết kiểu như "Này, phiên bản tốt hơn là phiên bản này" không?

Hay họ phải tự tìm hiểu một chút?

Tôi nghĩ rằng mã phiên bản thực sự có trên đó.

Đúng vậy, tôi không chắc chắn nhưng tôi tin rằng mã phiên bản được liệt kê trên đó là mã phiên bản mà họ có thể cập nhật.

Đúng vậy, và để hoàn toàn minh bạch, tôi không phải là nhà phát triển hay kỹ sư, nhưng khi trò chuyện với các nhà phát triển, tôi hiểu rằng đôi khi việc này rất đơn giản, chỉ cần nhấp vào một hoặc vài nút là bạn có thể bắt đầu quá trình cập nhật SDK trong ứng dụng của mình.

Thật tuyệt vời.

Chúng ta tìm hiểu tiếp nhé.

Cảm ơn bạn.

Được rồi.

Bạn đã đề cập sơ qua về thông tin đăng nhập, đây là một chủ đề mà tôi ít nhiều đã biết và tầm quan trọng của việc có thông tin này trong đó.

Bạn đã đề cập đến những nội dung như vượt qua quy trình xác thực hai yếu tố và đảm bảo có cách vượt qua tường phí hoặc truy cập vào nội dung dựa trên gói thuê bao.

Nhưng nhà phát triển nên cân nhắc những tình huống phổ biến nào khác?

Ví dụ: một trường hợp tôi từng gặp là đôi khi ứng dụng có nội dung chỉ truy cập được ở một số quốc gia hoặc vị trí địa lý nhất định, hoặc có thể là một ứng dụng nhắn tin thực sự yêu cầu hai thông tin đăng nhập để có thể thử nghiệm.

Có trường hợp nào khác mà ngoài việc cung cấp thông tin đăng nhập, nhà phát triển có thể cần phải làm thêm một số việc không?

Vâng.

Ý tôi là, tôi nghĩ tôi sẽ luôn bắt đầu và kết thúc bằng bất kỳ thông tin đăng nhập nào bạn cung cấp cho nhóm đánh giá, chỉ cần đảm bảo rằng thông tin đó cho phép họ truy cập vào tất cả các tính năng trong ứng dụng.

Phần đó trong Play Console trước đây có tên là quyền truy cập vào ứng dụng, và tôi nghĩ có lẽ khoảng một tháng trước, phần đó đã được đổi tên thành thông tin đăng nhập.

Đúng vậy, có một nơi để bạn có thể nhập tên người dùng, mật khẩu và tôi tin rằng bên dưới đó có một trường văn bản dạng tự do.

Vì vậy, bạn có thể hướng dẫn các bước đăng nhập nếu quy trình này không quá đơn giản.

Bạn cũng có thể cung cấp thông tin đăng nhập thứ hai, thứ ba và thứ tư nếu muốn.

Và để giúp bạn hiểu rõ hơn về quy trình xem xét ứng dụng của chúng tôi, thì không phải là có người ngồi trong phòng, xem xét qua loa rồi nhấp vào phê duyệt hoặc từ chối.

Có rất nhiều nhóm xem xét các chính sách và quy trình công việc khác nhau, nên rất có thể ứng dụng của bạn sẽ được nhiều người đăng nhập trên nhiều thiết bị, đôi khi ở nhiều khu vực.

Và tôi hiểu được khó khăn này vì nhiều cơ chế an toàn sẽ cho rằng: "Ồ, nếu chúng ta thấy nhiều lượt đăng nhập" thì vì sự an toàn của người dùng, cơ chế này sẽ dừng lại và đặt lại.

Nhưng dù bạn chọn làm gì, hãy biết rằng chúng tôi đang xem xét ứng dụng trên nhiều quy trình công việc khác nhau, và bạn có thể thấy điều đó.

Vì vậy, việc cung cấp nhiều thông tin đăng nhập có thể giúp ích.

Vâng.

Chúng ta tìm hiểu tiếp nhé.

Đúng vậy, tôi phải nhấn mạnh tầm quan trọng của việc sử dụng văn bản dạng tự do trong bản khai báo.

Vì vậy, nếu tài khoản minh hoạ của bạn không chỉ đơn giản là tên người dùng và mật khẩu, mà còn có nhiều bước khác, thì bạn chắc chắn phải đảm bảo rằng nhóm xem xét của chúng tôi hiểu cách truy cập vào ứng dụng của bạn.

Bạn có thể cung cấp một video hướng dẫn cách thực hiện để đảm bảo nhóm của chúng tôi hiểu cách làm nếu quy trình này phức tạp hơn việc chỉ nhập tên người dùng và mật khẩu.

Vâng.

Ý tôi là, đôi khi chúng tôi tự xem xét các ứng dụng và có một số ứng dụng có quy trình đăng nhập khá phức tạp.

Tôi từng thấy những trường hợp, và tôi không bịa ra đâu, như là nhấn vào nút này 17 lần, rồi vẽ một chữ X trên màn hình, sau đó chế độ nhà phát triển sẽ bật lên, rồi bạn phải làm theo 11 bước khác nữa. Xin đừng làm như vậy.

Vì như vậy thì khó lắm.

Một trường hợp mà tôi từng nghe nói đến là một số ứng dụng chỉ cho phép bạn đăng nhập liên tiếp X lần hoặc đăng nhập cùng lúc vào một ứng dụng trước khi thông báo rằng "Bạn phải xoá một phiên đăng nhập".

Vì vậy, nếu ứng dụng của bạn hỗ trợ tính năng đó, tôi nghĩ việc cung cấp thông tin về cách tìm trang mà bạn có thể xoá quyền truy cập vào các thông tin đăng nhập trước đó cũng rất hữu ích.

Vâng.

Chúng ta tìm hiểu tiếp nhé.

Vì vậy, khi chúng tôi cập nhật chính sách hoặc đưa ra chính sách mới, đôi khi nhà phát triển có thể phải thay đổi ứng dụng của họ. Tuỳ thuộc vào nội dung thay đổi, việc này có thể mất một chút thời gian để triển khai.

Vậy nên đôi khi những việc đó có thời hạn, đúng không?

Ví dụ: chậm nhất là vào ngày này, bạn cần phải hoàn tất XYZ để tuân thủ một chính sách mới.

Nếu thời hạn đó sắp đến nhưng nhà phát triển biết rằng họ cần thêm thời gian để có thể tuân thủ, thì họ có những lựa chọn nào?

Ừ, nghe có vẻ như một lời cảnh báo.

Đúng vậy, nghe như một lời cảnh báo.

Vâng.

Đúng vậy, đối với cảnh cáo, cách đơn giản nhất là yêu cầu thêm thời gian, đúng không?

Quy trình này thường diễn ra như sau: chúng tôi sẽ phát hành các chính sách mới, có thể là chính sách mới hoặc nội dung cập nhật cho chính sách hiện có, hoặc thậm chí chỉ là nội dung làm rõ.

Và tôi nghĩ Google thường thông báo trước khá sớm.

Và chính sách đó có thể được công bố công khai 6 tháng trước khi chúng tôi bắt đầu hành động.

Sau đó, chúng tôi sẽ gửi cảnh báo và thông báo rằng: "Ứng dụng của bạn đang vi phạm chính sách đã được công bố", bạn biết đấy, "6 hoặc 12 tháng trước" hoặc tương tự.

Nhưng có một điều mà Paul và tôi đôi khi phản đối, đó là họ có thể nói rằng bạn có 7 ngày để thực hiện thay đổi này.

Và có vẻ như quá trình phát triển mất nhiều thời gian.

Chúng tôi hiểu điều đó.

Vì vậy, tôi chỉ cần phản hồi.

Bạn có thể làm việc này thông qua đơn kháng nghị và có thể nói những điều như: "Xin chào, chúng tôi hiểu chính sách và biết rằng ứng dụng của chúng tôi không tuân thủ chính sách.

Chúng tôi đang xử lý vấn đề này hoặc đây là các bước chúng tôi sẽ thực hiện để giải quyết vấn đề về chính sách, nhưng chúng tôi cần thêm thời gian".

Vì vậy, họ thường sẽ cho bạn thêm một chút thời gian.

Nếu sau 7 ngày nữa mà bạn vẫn chưa nhận được mã PIN, thì bạn có thể yêu cầu gửi lại mã PIN.

Tất nhiên là không vô hạn.

Nhưng như tôi đã nói, Paul và tôi phản đối, nhưng đó là trên cơ sở cá nhân và cũng trên cơ sở cấp cao hơn.

Chẳng hạn như khi biết sắp có chính sách mới và biết ai đang soạn thảo chính sách đó, chúng tôi sẽ đề xuất: "Này, chúng ta có thể cảnh báo trước 28 ngày thay vì 7 ngày, hoặc ít nhất là 14 ngày không?"

Vâng.

Phải.

Nếu bạn thể hiện thiện chí, bạn biết đấy, chứng minh rằng bạn đang thiện chí thực hiện các thay đổi để tuân thủ, thì Google Play sẽ hợp tác với bạn để, bạn biết đấy, đặt ra một thời hạn mới để thực hiện.

Dòng thời gian phù hợp hơn với bạn.

Được rồi.

Vậy có vẻ như quy trình khiếu nại là một công cụ đa năng giúp giải quyết nhiều tình huống, miễn là được sử dụng đúng cách.

Chẳng hạn như việc gửi đơn kháng nghị khi hợp lý và cung cấp đủ thông tin chi tiết về lý do bạn gửi đơn kháng nghị có thể là một cách hiệu quả để được xem xét và hỗ trợ.

Được rồi.

Vậy nếu một nhà phát triển có nhiều ứng dụng trong một tài khoản nhà phát triển, điều mà tôi biết là luôn xảy ra.

Và một ứng dụng bị tạm ngưng do vi phạm chính sách, thì điều đó có ý nghĩa gì đối với toàn bộ tài khoản nhà phát triển của họ?

Điều đó có khiến tài khoản hoặc các ứng dụng tuân thủ khác gặp rủi ro không?

Nút này hoạt động như thế nào?

Có thể.

Đó sẽ là những nhà phát triển không có nhãn.

Trước đó, tôi đã nói về Joe's Chicken, đúng không?

Và có thể bạn có những khách hàng đều hoạt động trong ngành đó.

Tôi nghĩ việc này cũng giống như khi bạn chơi bóng chày và bị loại, đúng không?

Rất tiếc là có những đối tượng xấu tìm cách xâm nhập vào Cửa hàng Play. Đó là một trong những lý do chúng tôi áp dụng các biện pháp thực thi từ nhẹ đến nặng, chẳng hạn như xoá, tạm ngưng và thậm chí là cấm tài khoản.

Và nếu bạn gặp phải một trong những trường hợp có rất nhiều ứng dụng tương tự nhau trên Cửa hàng Play và một trong số đó bị tạm ngưng, giả sử rằng…

Ừm.

Bạn là một đối tượng xấu, đúng không?

Và thế là bạn sửa lại rồi một tháng sau, bạn tìm cách đưa lại vào.

Sau đó, nhóm của chúng tôi phát hiện ra và bạn lại bị tạm ngưng, đúng không?

Sau đó, bạn xoá tính năng đó khỏi ứng dụng rồi thêm lại sau khoảng một tháng. Giờ thì chúng tôi đã có một mẫu hành vi lặp lại và bạn đã bị loại sau ba lần đánh hụt, đúng không?

Nhưng giả sử bạn đang tạo một ứng dụng cho một nhà hàng gà, tức là ứng dụng này sẽ không có nội dung độc hại hay bất cứ thứ gì tương tự, bạn chỉ đang cố gắng mang đến món ăn ngon cho mọi người.

Giả sử bạn gửi tất cả các ứng dụng này cùng một lúc bằng quy trình CI/CD hoặc quy trình tương tự và bạn có 10 ứng dụng đều bị từ chối hoặc tạm ngưng cùng một lúc, thì chúng tôi sẽ chỉ coi đó là một lần vi phạm vì chúng tôi hiểu rằng bạn đang gửi rất nhiều ứng dụng cùng một lúc.

Ừm.

Thú vị đấy!

Vì vậy, tôi nghĩ đó là câu trả lời cho câu hỏi.

Vâng, tuyệt vời.

Cảm ơn bạn.

Và tôi còn một câu hỏi nữa.

Và câu hỏi này có lẽ là... Nhiều câu hỏi trong số này có lẽ dành cho các nhà phát triển đã có kinh nghiệm, nhưng câu hỏi này lại liên quan nhiều hơn đến việc thiết lập lần đầu trong Play Console.

Giả sử hồ sơ thanh toán của bạn trên Google Play đã được xác minh, hãy xác định... Ôi, dài dòng quá.

Lỗi xác minh danh tính hiện đã được khắc phục, chỉ còn lỗi xác minh số điện thoại.

Chẳng hạn như nhà phát triển cần làm gì trong trường hợp cụ thể đó để đảm bảo tài khoản nhà phát triển của họ đã sẵn sàng xuất bản ứng dụng?

Đôi khi, bạn phải tự mình giải quyết từng vấn đề nhỏ, hoặc nếu họ không biết cách hoàn tất quy trình trong trường hợp như vậy, thì họ có thể làm gì?

Đúng vậy, cách đây không lâu, tôi cũng gặp một câu hỏi tương tự tại một sự kiện khác. Tôi nghĩ rằng điều đó rõ ràng là đúng đối với các nhà phát triển mới, nhưng tôi nghĩ rằng nhiều nhà phát triển hiện tại cũng phải thực hiện lại quy trình xác minh đó.

Chuyện này xảy ra khoảng một năm trước, đúng không?

Tôi không nhớ rõ.

Nhiều người trong số họ đã được xác minh tự động, nhưng một số người chưa được xác minh thì phải thực hiện quy trình này.

Được rồi.

Hoặc có thể là địa chỉ và hồ sơ Dun & Bradstreet của họ không khớp, chẳng hạn như…

Phải.

Phải.

Hồ sơ trên Google.

Được rồi.

Đúng vậy, giả sử đó là số điện thoại.

Tôi sẽ trả lời câu hỏi này theo hai cách.

Được rồi.

Một là, được rồi, vậy nên nhiều khi bạn thực hiện các bước này, bạn sẽ nhận được thông báo xuất hiện trong Play Console.

Và bạn sẽ nhận được thông báo cho biết: "Đã đến lúc bạn cần đăng ký số điện thoại của mình".

Và điều đó khá đơn giản.

Bạn nhập số điện thoại theo định dạng quốc tế, dấu cộng 1 408, rồi đến số điện thoại.

Bạn sẽ xác minh qua tin nhắn SMS hoặc cuộc gọi điện thoại và làm theo các bước trong đó.

Nhưng đôi khi, có thể bạn đã thử làm việc đó và nhận được thông báo lỗi hoặc thông báo tương tự, vì chúng tôi cũng có những nhà phát triển gặp phải trường hợp đó hoặc họ không nhận được mã SMS.

Tôi sẽ hướng dẫn bạn các bước để liên hệ với nhóm kháng nghị.

Đó là một nhóm, nhưng thực ra còn có khoảng nửa tá hoặc hai tá nhóm khác…

Will.

Trả lời các câu hỏi trên Play Console mà bạn thực sự có quyền truy cập, thông qua trình đơn trợ giúp.

Giờ thì giao diện người dùng đã thay đổi một chút.

Trước đây, mục này nằm trong trình đơn ở bên trái màn hình chính.

Ở dưới cùng, bạn có một nút trợ giúp.

Và nút đó đã biến mất, nhưng giờ đây, nếu bạn chỉ cần di chuyển xuống cuối trang bất kỳ trong phần chân trang, bạn sẽ thấy nút trợ giúp đó.

Khi nhấp vào đó, bạn sẽ thấy một nút nhỏ màu xanh dương có hình viên thuốc, có nội dung là tạo phiếu yêu cầu hỗ trợ.

Tôi nghĩ đó là nội dung của câu này.

Ừm.

Có.

Sau đó, bạn sẽ thấy một số trình đơn thả xuống để đặt câu hỏi.

Và thực ra có một loạt trình đơn thả xuống sẽ đưa bạn đến thẳng số điện thoại, tôi nghĩ là tôi gần như đã nhớ hết, nhưng nó giống như xác minh tài khoản nhà phát triển của bạn, trình đơn thả xuống thứ hai khá giống, bạn sẽ nhận được một loạt nút chọn.

Một trong số đó là để xác minh số điện thoại.

Sau đó, có thể bạn sẽ nhận được mã xác minh qua SMS hoặc có thể bạn sẽ gặp lỗi trên màn hình khi cố gắng thực hiện quy trình đó.

Vì vậy, bạn có thể làm việc này để xác minh số điện thoại, cũng như để giải đáp nhiều câu hỏi khác mà bạn có thể có liên quan đến tài khoản nhà phát triển của mình trên Play.

Và hầu hết thời gian, Play Console đều hiển thị rất rõ các bước tiếp theo để xác minh, vì vậy, bạn chỉ cần làm theo các bước đó là được.

Tuyệt vời.

Chúng ta tìm hiểu tiếp nhé.

Chúng ta sắp hết thời gian rồi, nên tôi xin cảm ơn tất cả các bạn đã tham gia buổi thảo luận này.