Những tù nhân của phát triển Android dưới Google

• Một tác vụ bảo trì nhỏ nhằm nâng targetSdkVersion của một ứng dụng Android legacy để đáp ứng yêu cầu của Google đã biến thành sự cố crash trên production ở Android 13 và thời gian chờ xét duyệt dài trên Google Play
• Để tiếp tục được cung cấp cho người dùng thiết bị chạy phiên bản Android cao hơn mức target hiện tại, ứng dụng hiện có phải nhắm tới API level 31 trở lên; tác giả đã nâng từ API level 30 lên 33 rồi phát hành
• Bản phát hành đầu tiên được duyệt trong vòng 1 giờ, nhưng trên thiết bị Android 13 thật, ứng dụng bị crash ngay sau khi đăng nhập và không có cách rollback về phiên bản ổn định trước đó
• Bản build sửa lỗi được gửi ngay sau khi thay đổi code nhưng nằm trong trạng thái chờ xét duyệt khoảng 72 giờ, rồi mãi đến ngày 4/9 mới được đưa lên production sau 11 ngày
• Với ứng dụng mobile native, ngay cả khi trực tiếp vận hành mã nguồn và hạ tầng, kênh phân phối cuối cùng vẫn do nhà vận hành app store kiểm soát, tạo ra hạn chế về sửa lỗi khẩn cấp, rollback và tốc độ phát hành

---

Một cập nhật SDK nhỏ biến thành sự cố production

• Đối tượng bảo trì là một ứng dụng Android legacy mà khách hàng đang sử dụng
  • Chức năng đã hoàn thiện trong nhiều năm và đây không phải là ứng dụng đang được phát triển tích cực
  • Lý tưởng nhất là muốn giữ nguyên phiên bản ổn định
• Google thông báo qua email vào ngày 18/8/2023 về yêu cầu cấp Android API
• Điểm chính trong hướng dẫn của Google là để ứng dụng hiện có tiếp tục được cung cấp cho người dùng thiết bị chạy phiên bản Android cao hơn, ứng dụng phải nhắm tới API level 31 trở lên
• Tác động chính xác lên các ứng dụng đã cài đặt không rõ ràng, nên theo cách diễn giải an toàn hơn, nhóm ưu tiên xử lý cập nhật
• Còn chưa đến 3 tuần trước hạn chót, và Google đã không gửi lời nhắc sớm hơn về yêu cầu này

Thay đổi targetSdkVersion từ 30 lên 33

• Công việc bắt đầu ngày 23/8, nâng targetSdkVersion của ứng dụng từ API level 30 lên 33
• Bản build đầu tiên thất bại vì một dependency phân tích không tương thích
  • Dependency đó không gắn chặt với logic nghiệp vụ nên có thể gỡ bỏ
• Sau đó ứng dụng được chạy trên Android emulator, và các chức năng cốt lõi có vẻ vẫn hoạt động như trước
• Thay đổi này là một cập nhật để đáp ứng chính sách, không mang lại giá trị nghiệp vụ mới

Phát hành Google Play đầu tiên và crash trên Android 13

• Quy trình phát hành trên Google Play ban đầu diễn ra suôn sẻ
  • Vì ứng dụng legacy chỉ được cập nhật một hoặc hai lần mỗi năm, cần hoàn thành nhiều bảng khảo sát
  • Bản phát hành vượt qua xét duyệt trong vòng 1 giờ và được triển khai lên production
• Tối hôm đó, khoảng 21:30, vấn đề lộ ra khi khách hàng báo có người dùng không thể đăng nhập trên phiên bản ứng dụng mới
• Khi kiểm thử trên thiết bị Android thật, ứng dụng crash ngay sau khi đăng nhập
• Điều tra thêm cho thấy vấn đề xảy ra trên Android 13, phiên bản Android mới nhất lúc đó, còn các phiên bản trước vẫn hoạt động bình thường
• Ở công việc ban đầu, chỉ các image emulator cũ được kiểm thử nên vấn đề tương thích không lộ ra
• Nếu đã kiểm thử nhiều phiên bản Android, vấn đề có thể đã được phát hiện
  • Phạm vi thay đổi nhỏ và áp lực hạn chót đã tạo ra sự tự tin sai lầm, nhưng việc thiếu độ phủ kiểm thử là lỗi của nhóm

Cấu trúc phát hành chặn đường rollback

• Phản ứng ban đầu an toàn nhất là khôi phục bản phát hành ổn định trước đó và điều tra crash vào giờ làm việc hôm sau, nhưng Google Play không có tùy chọn đó
• Không có cách rút bản phát hành production mới nhất và kích hoạt lại phiên bản trước
• Phương án tiếp theo là đưa targetSdkVersion về 30, tăng version của ứng dụng và đăng một bản build mới, nhưng Google Play từ chối
  • Hướng dẫn đã công bố trông như vẫn cho phép target thấp hơn cho đến ngày 1/9, nhưng lỗi báo rằng bản cập nhật mới phải nhắm tới API level 33
• Nhóm đã yêu cầu gia hạn cho phép API level 30 đến ngày 1/11, nhưng lỗi đăng vẫn không thay đổi
• Con đường khả thi duy nhất là sửa crash trên Android 13 và gửi bản phát hành mới

Sửa lỗi dưới áp lực và chờ xét duyệt kéo dài

• Phiên bản bị lỗi đang được tự động cập nhật dần tới người dùng, và bản build sửa lỗi càng nhanh lên production thì càng giảm được số khách hàng bị ảnh hưởng
• Crash có thể tái hiện trên Android 13 emulator, và thay đổi code cần thiết không nhiều
• Tuy vậy, công việc phải thực hiện vào tối muộn dưới áp lực, và thời gian dành cho kiểm thử hồi quy toàn diện rất hạn chế
• Kế hoạch khi đó thiên về cách ứng phó thực dụng
  • Sửa tất cả crash đã biết
  • Kiểm thử các luồng quan trọng nhất
  • Gửi ngay phiên bản đã sửa
  • Tiếp tục kiểm thử rộng hơn và chuẩn bị cập nhật bổ sung nếu cần
• Bản build mới được gửi lên Google Play nhưng sau 2 giờ vẫn ở trạng thái chờ xét duyệt, và đến khoảng 01:00 vẫn chưa được phê duyệt
• Sáng hôm sau, ứng dụng vẫn ở trạng thái in review
• Phần lớn cả ngày được dùng để kiểm thử Android 13 và kiểm tra Google Play Console; một vài vấn đề nhỏ, không nghiêm trọng bằng crash khi đăng nhập, được phát hiện và sửa
• Đến hết ngày hôm đó, bản sửa production vẫn chưa được phê duyệt
• Khi ấy bản build sửa lỗi đã chờ khoảng 72 giờ; code đã được sửa nhưng việc phát hành bị kẹt trong hàng đợi xét duyệt thiếu minh bạch

Cập nhật sau đó: xét duyệt, chat hỗ trợ, phát hành theo giai đoạn

• Ngày 27/8, tác giả đăng bài lên Hacker News, và phần thảo luận có cả chiến lược phát hành Android lẫn các ý kiến phê bình
  • Bài viết lên trang nhất và trong vài ngày nhận khoảng 130.000 lượt truy cập duy nhất
  • Website tĩnh chạy trên VPS tốn khoảng €5/tháng đã xử lý được lưu lượng
  • Sự chú ý này không dẫn tới phản hồi từ Google, và bản cập nhật ứng dụng vẫn tiếp tục trong trạng thái xét duyệt
• Ngày 1/9, tác giả phát hiện chat hỗ trợ nằm sau biểu tượng dấu hỏi trong Google Play Console
  • Nhân viên hỗ trợ hứa sẽ thúc đẩy việc xét duyệt nhanh hơn nhưng không đưa ra thời hạn hay giải pháp rõ ràng
  • Điều đáng chú ý là không ai trong cuộc thảo luận lớn trên Hacker News nhắc đến con đường này
  • Có thể vì tiếng tăm khó tiếp cận của bộ phận hỗ trợ Google khiến các nhà phát triển không kỳ vọng nhận được trợ giúp trực tiếp
• Ngày 4/9, bản cập nhật sửa lỗi cuối cùng được đăng sau 11 ngày xét duyệt
• Sau đó, thay vì triển khai ngay cho 100% người dùng, tác giả gửi một bản phát hành tiếp theo nhỏ hơn dùng phát hành theo giai đoạn, và bản cập nhật này vượt qua xét duyệt trong vòng 1 giờ
• Ngày 7/9, một cập nhật nhỏ khác được gửi để thay thế phiên bản đã tới 99,9999% người dùng
  • Khi phiên bản mới vào xét duyệt, Google tự động dừng rollout trước đó mà không cảnh báo
  • Nếu lần xét duyệt mới mất vài ngày, cả bản phát hành trước đó cũng sẽ không được cung cấp cho số người dùng còn lại
  • Việc rút bản gửi mới cũng không khôi phục rollout trước đó
  • May mắn là lần xét duyệt này kết thúc trong vòng 1 giờ

Quyền kiểm soát nền tảng làm thay đổi trách nhiệm production

• Các nhà phát triển mobile đã gặp nhiều trường hợp tương tự, trong đó Google hoặc Apple trì hoãn bản sửa production khẩn cấp, gỡ ứng dụng, hoặc gần như không đưa ra giải thích cho quyết định của họ
• Ngay cả khi đội kỹ thuật nhanh chóng chẩn đoán và sửa lỗi, thời điểm người dùng nhận được giải pháp vẫn do nhà vận hành app store kiểm soát
• Với người dùng phổ thông, có thể không có rollback, kênh phân phối thay thế, hay cách tăng tốc xét duyệt đáng tin cậy
• Dù sở hữu mã nguồn và hạ tầng, nếu không kiểm soát được kênh phân phối cuối cùng thì bản chất của quyền sở hữu production sẽ thay đổi
• Khi không nhất thiết cần ứng dụng mobile native, lý do để ưu tiên nền tảng web mở trở nên mạnh hơn
  • Ứng dụng web thường có thể cung cấp các chức năng cần thiết trong khi đội ngũ tự thực hiện triển khai, giám sát và rollback
• Ứng dụng native vẫn có các trường hợp sử dụng hợp lệ
  • Phụ thuộc vào tính năng thiết bị
  • Hoạt động nền
  • Khi cần phân phối qua app store
• Lựa chọn mobile là quyết định chấp nhận chi phí vận hành khi một bên thứ ba quyền lực tham gia vào quy trình phát hành, bên cạnh lợi ích sản phẩm

[GN⁺]

Ý kiến trên Hacker News

• Tôi đã nhận email này cả với tư cách cá nhân lẫn trong công việc
  Về cá nhân, tôi tự nguyện tạo và vận hành các ứng dụng mã nguồn mở cho hệ thống giao thông công cộng của 16 thành phố, và vì một việc chẳng mang lại lợi ích cho ai, tôi đã phải cập nhật 16 ứng dụng trong vòng 2 tuần
  Ứng dụng của tôi là PWA, còn phiên bản Android là dạng dùng Cordova cùng vài plugin để thêm một chút tùy chọn native. Khi nâng Cordova để hỗ trợ Android API mục tiêu mới, các plugin chưa được cập nhật bị hỏng, nên tôi phải làm và kiểm thử suốt cả cuối tuần
  Thành thật mà nói, tôi muốn bỏ ứng dụng đi và để người dùng vào website rồi cài PWA, nhưng người dùng trung bình vẫn chưa biết cách làm. Nơi đầu tiên người dùng tìm ứng dụng vẫn là Play Store. Chỉ cần Google cho phép gửi PWA trực tiếp lên app store là tốt rồi, và tôi không muốn lặp lại chuyện này hằng năm
  Trong công việc tôi cũng đang xử lý đến quay cuồng. Có một ứng dụng legacy mà một số khách hàng được hỗ trợ dùng đến cuối năm; đó là một ứng dụng khá phức tạp nên chỉ đổi phiên bản API mục tiêu thôi mà nhiều phần đã hỏng ở các bài kiểm thử cơ bản. Chúng tôi đã được gia hạn, nhưng tôi biết sẽ tốn 1–2 tuần của developer và 1–2 tuần QA cho một bản cập nhật không có thay đổi tính năng nào ngoài việc làm vừa lòng Google. Dù đây là ứng dụng sẽ chính thức bị gỡ khỏi store vào cuối năm khi tất cả khách hàng chuyển sang ứng dụng mới

  • Có Trusted Web Activities (TWA) để dùng trong những trường hợp như thế này. Có thể đưa PWA lên Play Store mà không cần framework như Cordova
    https://rangle.io/blog/publishing-a-web-app-to-the-play-stor...
    https://developers.google.com/codelabs/pwa-in-play#0
  • Nói cho rõ, không chỉ vì người dùng không biết cách. Đó là vì Google và Apple đã không làm cho việc này dễ như cài ứng dụng từ app store của họ. Đó là một lựa chọn, và là một lựa chọn có chủ ý
  • Có vẻ bạn hiểu nhầm người dùng. Đây không đơn thuần là vấn đề thiếu hiểu biết. Tôi muốn ứng dụng quay lại là ứng dụng native thật sự, tức không phải Cordova. Hầu như không có web app nào sánh được với trải nghiệm của một ứng dụng thực sự được làm tốt, chứ không phải một thứ dựa trên web làm qua loa
  • Đồng cảm. Một vài ứng dụng cá nhân của tôi cũng bị ảnh hưởng
    Tuy vậy, hạn chót này đã được thông báo liên tục từ vài tháng trước, và rõ ràng sớm muộn gì nó cũng sẽ được hiển thị một cách trực diện hơn. Tôi không thích câu chữ đó, và việc phàn nàn rằng bản production thì ổn nhưng bản test không đạt chuẩn cũng chẳng hợp lý
    Ngoài ra, vấn đề luôn là phải đẩy một bản cập nhật mới, và năm nào cũng vậy. Ứng dụng vẫn có thể tiếp tục ở trạng thái công khai một thời gian
    Vì vậy nói rằng chỉ có 2 tuần là không chính xác
  • Không biết có giúp được không, nhưng nếu là tôi trong tình huống này, tôi sẽ phát hành vài bản cập nhật ứng dụng kèm màn hình hướng dẫn cách cài phiên bản PWA, rồi dần dần rút khỏi những vấn đề này. Có lẽ cũng có thể cung cấp biểu mẫu phản hồi để ghi nhận những khó khăn người dùng gặp phải

• Tôi đồng ý rằng phát triển Android có nhiều khó khăn, nhưng tác giả đã mắc hai sai lầm lớn
  Thứ nhất, không kiểm thử ứng dụng trên phiên bản Android mới nhất. Đây là sai lầm rất lớn, và là lý do chúng tôi duy trì 11 máy ảo cho tất cả các phiên bản Android mà chúng tôi hỗ trợ
  Thứ hai, khi phân phối ứng dụng trên Google Play, tuyệt đối không được triển khai ngay cho 100% người dùng từ đầu. Triển khai theo giai đoạn là mặc định; sau khi đăng bản phát hành, ban đầu chúng tôi không vượt quá 10% người dùng. Khi tự tin hơn thì triển khai cho 99%, chứ không phải 100%. Như vậy nếu vì bất kỳ lý do gì cần dừng triển khai, miễn là chưa triển khai đến 100% thì có thể dừng dễ dàng
  Dù thích hay không, hai cách này là các chiến thuật mà developer Android giàu kinh nghiệm đều biết rõ

  • Tôi đồng ý rằng có thể làm tốt hơn ở nhiều khía cạnh. Tuy nhiên, như đã giải thích, đây là một ứng dụng legacy, không phải ứng dụng đang được phát triển tích cực hiện nay, nên xây dựng một hệ thống QA vững chắc như vậy là không hợp lý. Ứng dụng này do một công ty khác viết từ lâu và thậm chí không có unit test đơn giản nào. Đó là thực tế
    Nhưng ngay cả khi có một hệ thống phức tạp đến mức đó, sai sót vẫn xảy ra, và vấn đề thật sự là không có cách nào hoàn tác, hủy hoặc rollback bản phát hành
    Trong tình huống này, triển khai theo giai đoạn giúp tất cả khách hàng như thế nào? Khi người dùng cuối nhận được phiên bản bị lỗi, có cách nào để họ nhận lại phiên bản hoạt động bình thường không?
  • Gợi ý nhỏ: ô nhập đó cũng nhận số thập phân. Chúng tôi luôn đặt là 99.99999999% để không có người dùng nào vô tình bị bỏ sót. Đồng thời, như đã nói, vẫn có thể hủy triển khai
  • Nếu phải duy trì máy ảo cho từng phiên bản Android được hỗ trợ thì cũng đành, nhưng rốt cuộc tôi tự hỏi khoản phí 30% doanh thu được thu để làm gì
  • Điều này hơi giống đổ lỗi cho nạn nhân. Hai chuyện đó lẽ ra ngay từ đầu không nên trở thành vấn đề
  • Những gì bạn nói hoàn toàn đúng, và là cách thực tế duy nhất để cập nhật và phát hành. Nhưng thật đáng tiếc khi không thể kỳ vọng rằng chỉ cần bản cập nhật API biên dịch được thì nó sẽ hoạt động nguyên như vậy

• Tôi không hiểu phản ứng dồn ép tác giả bài gốc. Dĩ nhiên họ có thể đã cẩn thận hơn, và cũng có thể đã kiểm thử đăng nhập trên Android mới nhất. Nhưng nếu đó không phải là lỗi crash khi đăng nhập thì sao? Nếu nó hoạt động trên phiên bản mới nhất nhưng không hoạt động trên phiên bản khác thì sao? Phải vạch ranh giới ở đâu?
  Đến một lúc nào đó, cần phải nói rằng “đây đúng nghĩa là một nền tảng được hàng triệu ứng dụng và hàng triệu nhà phát triển sử dụng; sai sót có thể xảy ra; và ngay cả khi không biết các mẹo như dừng bản phát hành của mình hay phát hành theo giai đoạn, vẫn phải có cách sửa dễ dàng, chẳng hạn lập tức công khai lại phiên bản cũ đã được phê duyệt”. Đặc biệt ở những nơi như app store, khả năng hoàn tác và khôi phục phải là nguyên tắc thiết kế cơ bản

  • Tôi là tác giả bài gốc, cảm ơn vì đã suy nghĩ cùng tôi. Như tôi đã nói trong nhiều phản hồi, tôi hoàn toàn đồng ý rằng mình đã có thể làm tốt hơn về mặt kiểm thử. Tất nhiên phần đó luôn có chỗ để cải thiện
    Google đặt ra hạn chót, và xin nhắc lại, tôi chỉ nghe đến nó lần đầu vào ngày 18 tháng 8, trước đó tôi không hề biết. Thay đổi lúc đó trông có vẻ nhỏ, và vì ứng dụng vẫn hoạt động như trước trên các phiên bản Android cũ, tôi không ngờ nó lại thất bại thảm hại đến vậy
    Tôi không phải là một nhà phát triển Android dày dạn, nhưng tôi có hơn 15 năm kinh nghiệm phát triển phần mềm nói chung, nên cũng có cảm giác riêng về việc mọi thứ sẽ hoạt động ra sao, cần kỳ vọng gì và lo sợ điều gì. Tôi thật sự không biết rằng phát hành theo giai đoạn 99,99999999% là best practice nếu muốn giữ khả năng “rút lại” phần nào bản phát hành mới nhất
    Tôi chưa từng mơ tới việc không có cách nào hủy hoặc xóa bản phát hành mới nhất để quay lại phiên bản ổn định trước đó. Có vẻ phải trải qua tình huống như thế này mới học được
    Bạn có thể trách tôi vì đã không kiểm thử mọi tính năng trên mọi phiên bản Android, và tôi cũng nghĩ vậy, nhưng tôi mong mọi người mở mắt ra và hiểu rằng cách Play Store hiện xử lý phát hành không phải là cách mà một người bình thường sẽ làm nếu ở ngoài Play Store. Bất kỳ ai rồi cũng có thể gặp vấn đề như thế này, và tôi hy vọng bài viết này cùng thread này sẽ giảm số nhà phát triển rơi vào tình huống tương tự
  • “Nếu nó hoạt động trên phiên bản mới nhất nhưng không hoạt động trên phiên bản khác thì sao?” là một lời bào chữa yếu. Ngay cả với web app cũng phải kiểm thử trên nhiều trình duyệt
    Smoke test cho bản phát hành mới là đạo đức nghề nghiệp cơ bản
    Phát hành theo giai đoạn có rollback cũng không phải khái niệm mới
  • Việc port ứng dụng lên Android 13, tức targetSdkVersion 33, mà lại không kiểm thử Android 13 thì không thể bào chữa được

• Câu “hãy quay lại các tiêu chuẩn web mở và giành lại quyền kiểm soát” có thể sẽ khác đi khi biết rằng web cũng đang bị Google, chính công ty gây ra vấn đề hiện tại, kiểm soát một nửa. Apple, với Safari gần như là trình duyệt duy nhất trên iOS, cũng chẳng hẳn là bạn bè gì

  • Điều đó cũng đúng, nhưng ít nhất những vấn đề như thế này có thể xử lý bằng các cách như rollback. Tình huống hiện tại là biết rằng một build lỗi đang ở production và điện thoại đang tự động cập nhật lên đó, nhưng lại không thể làm gì. Đó mới là điều tệ nhất
  • Nếu tự host trên web, có thể việc bảo trì sẽ nhiều hơn là chỉ trả chi phí
    Tôi chắc chắn thích website hơn một app vô dụng chỉ tồn tại để theo dõi tốt hơn, nhưng tôi đọc bài này như một trường hợp bảo trì nửa vời
  • Nếu bạn từ chối đi theo hướng ưu tiên quyền riêng tư và bảo mật của người dùng thì Apple chắc chắn không phải là bạn. Nếu cần nêu lý do thì là vậy

• Đây là tình huống không thể thắng
  Microsoft đổ rất nhiều công sức vào khả năng tương thích ngược, và điểm đó rất đáng được ghi nhận. Nhưng đổi lại bề mặt tấn công cũng tăng lên rất nhiều
  Tương tự, nhiều mặt tệ nhất của C++ vốn thường bị chửi oan xuất phát từ lập trường cứng rắn về tương thích ngược. Code cũ nhất có thể, thậm chí cả code C cũ, vẫn phải tiếp tục compile và hoạt động như kỳ vọng, đến mức chấp nhận cả việc link với các binary cũ đã mất source code
  Phần lớn không bỏ công đến mức đó, mà vô hiệu hóa những thứ cũ vì lý do khả năng bảo trì, độ tin cậy và bảo mật
  Dù chọn điểm rẽ nào thì cũng sẽ có người bị thiệt. Nếu không thì nghĩa là chẳng ai dùng đoạn code đó cả

  • Đúng. Đó là một phía của vấn đề, và tôi cũng không đòi hỏi tương thích ngược quá mức. Điều đáng lo nhất trong tình huống cụ thể này là trên Android không có cách nào để hoàn tác, hủy hay rollback một bản phát hành, và mọi thứ đều bị chặn sau quy trình xét duyệt của Google
    Tại sao không thể “rút lại” một bản phát hành có vấn đề và tiếp tục hiển thị bản phát hành trước đó như phiên bản mới nhất? Như vậy trong bối cảnh vấn đề này thì gần như sẽ giải quyết được phần lớn
  • Tôi nghĩ điểm cân bằng có lợi cho mọi người là thay đổi API và làm hỏng quá trình compile. Cứ buộc nhà phát triển sửa lỗi compile và dùng API cho đúng
    Nhưng không nên thay đổi hành vi của một hàm hiện có với cùng signature. Nếu là bên cung cấp API, nên cố hết sức để việc compile có ý nghĩa
  • Không có lựa chọn thắng tối ưu, nhưng cũng có thể phân phối ứng dụng riêng. Đây không phải là yêu cầu của Android mà là yêu cầu của Play Store
    Trong nhiều trường hợp việc đó hoàn toàn không đơn giản và cũng sẽ không được dùng nhiều như phiên bản Play Store, nhưng có một lối thoát vẫn là điều tốt
  • Có vẻ điều tác giả chủ yếu phàn nàn là việc Google đóng vai trọng tài quyết định người dùng được chạy phần mềm nào. Vấn đề API bị loại bỏ chỉ là cái cớ khiến ta nhận ra mình đã dễ tổn thương đến mức nào trước sự thất thường của Google
  • Khó có thể chấp nhận điều này như một lời bào chữa cho Google
    Phần lớn ứng dụng được phân phối trên Android nhắm tới Android bytecode. Chúng không phải là ứng dụng compile native
    Lý do C++ tạo ra các vấn đề bảo mật khó khắc phục là vì tính chất cấp thấp của nó, và vì một khi đã có binary native thì coi như xong
    Nhưng nếu là bytecode của một ngôn ngữ có an toàn bộ nhớ, thì có lý do gì mà không backport được các bản sửa bảo mật? Bản thân việc chạy loại code đó đã mang tính chất liên tục compile lại bytecode rồi
    Để thấy lập trường này vô lý với Google đến mức nào, JVM đến nay vẫn có thể chạy và sử dụng các class nhắm tới Java 1.0 ra đời năm 1996
    Đây không phải là vấn đề bảo mật, mà là vấn đề “Google không muốn hỗ trợ nền tảng”
    Việc Google nghiêm khắc hơn với các artifact có code compile native ở mức nào đó còn có thể hiểu được. Nhưng một chính sách hàng loạt kiểu “ứng dụng được build nhắm tới phiên bản Android cũ nên chúng tôi sẽ không hỗ trợ nữa” thì thật vô lý. Nó trông giống một cách tỉa bớt ứng dụng cũ khỏi store hơn là vì bảo mật
    Đặc biệt, kiểu chính sách này về bản chất đẩy gánh nặng bảo trì lớn sang nhà phát triển Android. Để hỗ trợ ứng dụng rộng nhất có thể, họ sẽ nhắm tới phiên bản Android cũ nhất có thể. Rất ít người nhắm tới phiên bản Android mới nhất vì sợ loại trừ quá nhiều khách hàng
    Nếu Google nghiêm túc với bảo mật và khả năng tiếp cận rộng rãi các công nghệ Android mới nhất, họ sẽ cố tách Android runtime khỏi phiên bản hệ điều hành. Không có lý do gì ART và Dalvik runtime không thể được phân phối qua Google Play như những phần khác của hệ sinh thái Android. Điều đó cũng có thể loại bỏ tình huống ngớ ngẩn kiểu “để làm việc này cần Android 17… à, nhà sản xuất phần cứng lại không cập nhật driver”
    Nhưng như vậy sẽ ảnh hưởng đến doanh số thiết bị mới, nên chắc là không thể chấp nhận được

• Việc Play Store và “cộng đồng” nhà phát triển bị nhốt bên trong nó là một cái bẫy thì từ trước đến nay luôn rất rõ ràng. Ép nâng cấp API chỉ là một khía cạnh của nó
  Rõ ràng có những việc điện thoại hoặc ứng dụng di động làm tốt nhất. Thường là những thứ liên quan đến di chuyển như điều hướng, hoặc những việc dựa vào cảm biến điện thoại như xác định phía nào là “trên”. Nhưng gần như mọi thứ còn lại đều có thể làm bằng website
  Tôi thật sự thấy vất vả và đồng cảm nếu bạn là một nhà phát triển một mình bảo trì ứng dụng di động đa nền tảng. Chỉ là từ lâu tôi đã quyết định không muốn tham gia trò chơi của các nền tảng độc quyền và gatekeeper, nên tôi chỉ đồng cảm từ vị thế hoàn toàn là người ngoài cuộc

  • Thật ra hai việc đó cũng có thể làm dễ dàng trong ứng dụng trình duyệt
    Gần như thứ duy nhất hiện chưa dễ làm trên mobile là GPU compute shader. Nhưng khi WebGPU từ trình duyệt desktop lan sang thì điều đó cũng sẽ sụp đổ
    Một thứ khác tôi nghĩ tới là quản lý file toàn hệ thống nói chung. Cái đó có lẽ sẽ không bao giờ xuất hiện. File System API đúng là cho phép người dùng cấp quyền truy cập vào một thư mục cụ thể, nhưng tôi không biết quyền đó có còn tồn tại sau khi refresh trang hay không
  • Tôi từng chắc rằng app store sẽ thất bại. Vì tôi không nghĩ sẽ có đủ nhà phát triển tập hợp lại đến mức sẵn sàng từ bỏ sự bảo đảm rằng họ có thể thực sự phân phối ứng dụng của mình
  • Đọc điều này trên một trang thường xuyên công kích Google vì không gatekeep phần mềm đủ chặt trên Android, và ca ngợi iPhone là tốt hơn vì kiểm soát mạnh tay hơn, thật buồn cười
  • Chắc hẳn bạn không muốn cố chấp về mặt ý thức hệ đối với chủ quyền của người dùng trên chính thiết bị của họ đâu nhỉ? Thay vào đó cứ hành xử thông minh và thực dụng, đi theo con đường ít kháng cự nhất để bước vào chuồng là được

• Thật mỉa mai khi nghĩ rằng một trong các nguyên tắc SRE của Google là “rollback là chuyện bình thường”
  https://cloud.google.com/blog/products/gcp/reliable-releases...
  “Ở Google, triết lý của chúng tôi là ‘rollback là chuyện bình thường’. Khi phát hiện lỗi trong bản phát hành mới, hoặc có nghi ngờ hợp lý rằng có lỗi, đội ngũ phát hành trước hết sẽ rollback rồi sau đó mới điều tra vấn đề. Yêu cầu rollback không được diễn giải như một sự công kích đối với đội ngũ phát hành hay người đã viết đoạn mã có lỗi. Trái lại, nó được hiểu là việc đúng đắn nhằm làm cho hệ thống đáng tin cậy nhất có thể vì người dùng. Miễn là danh sách thay đổi rollback mô tả vấn đề đã quan sát được, sẽ không ai hỏi ‘tại sao lại rollback thay đổi này’”

  • Tính đến năm ngoái, do sự kết hợp giữa chính sách Google Play và các bản cập nhật Android, nếu phân phối ứng dụng qua Play Store thì cách duy nhất để rollback là gỡ rồi xóa dữ liệu người dùng
    Không thể downgrade xuống versionCode thấp hơn, và versionCode do lập trình viên định nghĩa
    Android 11 cấm ghi vào bộ nhớ “vĩnh viễn” của điện thoại, trừ việc dùng ngoại lệ cho media hoặc API DocumentFile vốn coi thư mục cục bộ như kho lưu trữ đám mây. DocumentFile không dùng được trong nhiều trường hợp sử dụng
    Lập trình viên có thể đặt hasFragileUserData, khi đó lúc gỡ ứng dụng phải hỏi người dùng có xóa dữ liệu hay không. Nhưng do lỗi của Google/Android, hộp thoại này có thể không hiển thị
    Nếu ứng dụng đã bị gỡ mà người dùng không xóa dữ liệu, Android sẽ chặn downgrade xuống versionCode thấp hơn
    Nếu yêu cầu MANAGE_EXTERNAL_STRORAGE thì có thể dùng java.io.File thông thường
    Google Play chỉ cho phép MANAGE_EXTERNAL_STRORAGE trong các trường hợp ngoại lệ
  • “Với tôi thì có rollback, với bạn thì không”

• Điều tương tự cũng đã xảy ra với nhiều ứng dụng dựa trên framework do tôi làm. Phiên bản API mới xung đột với các dependency hiện có, và để quay lại đúng trạng thái vốn đã tồn tại trước đó, tôi đã phải làm một khối lượng công việc thật sự khổng lồ
  Tôi ngày càng tôn trọng Microsoft hơn nhiều: những thứ từ thập niên 90 chạy trên Windows mới nhất còn ít vấn đề hơn ứng dụng di động tôi viết trên Android 4 năm trước

  • Nếu framework bạn dùng không đến từ Google thì nói vậy là không công bằng
    Bạn đâu có trách Microsoft vì Adobe Flash không chạy trên Windows 11 Store, đúng không?

• Tôi cho rằng việc bị ép buộc chỉ được phân phối ứng dụng thông qua một kho ứng dụng “tự phê duyệt” duy nhất có quá nhiều nhược điểm và gần như không có ưu điểm
  Nếu gọi là ưu điểm thì trớ trêu thay, đó là việc quản trị viên kho ứng dụng kiểm tra mã độc và virus trước khi đăng. Nhưng những ứng dụng đầy quảng cáo Google và tracker của Google/Facebook thì lại được chào đón dưới đủ mọi hình thức
  Cũng có điểm là giúp người dùng dễ tìm kiếm, cài đặt và cập nhật ứng dụng. Nếu họ có thể tìm được thứ mình muốn giữa hàng tỷ ứng dụng game và vô số ứng dụng rất giống nhau được đăng lên chỉ để gửi quảng cáo hoặc thu thập dữ liệu cá nhân
  Nhược điểm là bị ràng buộc bởi sự thất thường của quản trị viên kho ứng dụng, và không có quyền kiểm soát quy trình đăng ứng dụng. Tôi không thể quyết định liệu ứng dụng có được đăng hay không, và đăng khi nào; quản trị viên App Store sẽ quyết định dựa trên việc điều đó có thuận tiện cho họ hay không. Tôi nghĩ quyền này chỉ nên thuộc về người dùng
  Với các ứng dụng native thương mại, chẳng hạn ứng dụng ngân hàng tại nhà, tôi muốn đăng nhập vào khu vực cá nhân trên website của nhà phát triển để tải xuống. Ứng dụng nên được ký bằng GPG và có thể kiểm tra tính toàn vẹn của gói. Tự động cập nhật cũng có thể làm được
  Với ứng dụng mã nguồn mở thì có kho F-Droid và có thể thêm kho riêng. Tôi thừa nhận nó hơi kỹ thuật và không phù hợp với tất cả mọi người. Nếu F-Droid được cài sẵn trên điện thoại mới thì sẽ giúp ích rất nhiều, nhưng có lẽ Google sẽ không cho phép
  Một lựa chọn thực tế khác là PWA. Theo tôi, rất ít ứng dụng thật sự cần các tính năng native, còn hầu như mọi thứ còn lại đều có thể làm bằng công nghệ PWA. Cũng không cần gửi bản cập nhật cho người dùng hay yêu cầu họ nâng cấp
  Các kho ứng dụng độc quyền và thương mại, vận hành dưới cái cớ làm cuộc sống người dùng dễ dàng hơn và cung cấp “bảo mật tốt hơn”, là một phương tiện “tuyệt vời” để Apple và Google kiếm hàng tỷ đô la từ lao động của các nhà phát triển độc lập, và trong trường hợp của Google là thu thập, bán dữ liệu cá nhân của người dùng cũng như bán quảng cáo bằng đủ mọi cách

  • Còn bỏ sót một ưu điểm khác. Đó là có thể giữ Boston Strangler[0] ở ngoài nhà. Nếu trói tay người dùng ra sau lưng, bạn có thể quyết định họ sử dụng tác phẩm của bạn trong những điều kiện nào. Không có sao chép lậu, cũng không có chặn quảng cáo
    Đây là lý do các nhà phát triển game trong thập niên 80–90 phần lớn đi theo mô hình “Licensed by Nintendo”, và các nhà phát triển ứng dụng di động cuối thập niên 2000 cũng làm y hệt với iOS App Store. Họ không muốn hợp tác trực tiếp với người dùng để đi vòng qua chủ sở hữu nền tảng. Họ muốn chủ sở hữu nền tảng trói tay người dùng, và chấp nhận việc tay mình cũng bị trói trong quá trình đó
    Lấy ví dụ ứng dụng ngân hàng: ngân hàng muốn chứng thực từ xa an toàn. Họ muốn chặn người dùng thực hiện tấn công credential stuffing vào ứng dụng, ngăn mã độc mở ứng dụng ngân hàng rồi bấm nút “chuyển tiền cho kẻ lừa đảo”, ngăn người dùng trích xuất các giá trị bí mật mã hóa liên quan đến tap-to-pay, và cũng ngăn việc nhúng các bí mật bị đánh cắp vào ứng dụng trên điện thoại
    Ứng dụng không thể tự xác minh rằng tay người dùng đã bị trói hay chưa. Cần một bên thứ ba đáng tin cậy đối với ngân hàng, chứ không phải đối với người dùng, nằm trong chuỗi khởi động hoặc EL3. Vì vậy họ không chỉ muốn đưa ứng dụng và chữ ký, mà muốn Google làm việc đó để Google có thể trói tay người dùng
    Điều quan trọng là mọi lợi ích phía người dùng của kho ứng dụng đều chỉ là biện minh sau sự kiện. Mục tiêu ngay từ đầu là trói buộc người dùng. Vì đối với họ, người dùng giống như những con muỗi ăn cắp vặt. Đây là “phần im lặng” mà họ không nói to ra
    Mong rằng đề xuất WEI của Google sẽ không thành hiện thực và PWA không được truy cập khả năng chứng thực. Google vốn đã làm trò vớ vẩn kiểu “không cho đăng nhập bằng trình duyệt không xác định”, và căn bệnh ung thư đó không cần lan rộng thêm
    F-Droid rất tuyệt. Những trò của Google trên Android cần bị chặn lại. EU đã có thể làm điều đó, nhưng Mỹ cũng nên làm vậy và khiến nó được áp dụng trên phạm vi quốc tế
    [0] Mật danh mà MPAA dùng để gọi việc sao chép phi thương mại quy mô nhỏ, tức ghi lại chương trình TV bằng VCR. Jack Valenti đúng là một người tệ hại, nhỉ?

• Tôi cũng đã phản đối việc phát triển ứng dụng di động trong nhiều năm, vì ngay khi quyết định phát triển ứng dụng di động là bạn trao quyền kiểm soát sản phẩm hoặc dịch vụ của mình cho một bên thứ ba
  Không khó để đồng ý
  Nếu “hỗ trợ” chỉ ở mức hy vọng nhận được sự chú ý hữu ích trên HN hoặc Twitter, thì chúng ta đang đi sai hướng