Kể từ Android 17, khung âm thanh sẽ thực thi các quy tắc hạn chế đối với hoạt động tương tác âm thanh ở chế độ nền, bao gồm cả việc phát âm thanh, yêu cầu lấy tiêu điểm âm thanh và API thay đổi âm lượng để đảm bảo rằng người dùng chủ ý bắt đầu những thay đổi này.
Nếu dự định kiểm soát âm thanh mà không có hoạt động hiển thị, thì nhà phát triển ứng dụng phải đảm bảo rằng ứng dụng có một dịch vụ trên nền trước (không thuộc loại SHORT_SERVICE) đã được bắt đầu bằng các chức năng khi đang sử dụng (WIU). Dịch vụ trên nền trước được cấp các chức năng WIU nếu dịch vụ này được khởi động để phản hồi MediaSessionEvent hoặc trong khi người dùng nhìn thấy ứng dụng.
Nếu ứng dụng cố gắng gọi các API âm thanh khi ứng dụng không ở trong một vòng đời hợp lệ, thì các API phát âm thanh và thay đổi âm lượng sẽ âm thầm không hoạt động mà không đưa ra một ngoại lệ hoặc cung cấp thông báo lỗi. API lấy tiêu điểm âm thanh không thành công với mã kết quả AUDIOFOCUS_REQUEST_FAILED.
Mục đích của việc đưa ra những hạn chế này là để giảm các trải nghiệm âm thanh nền không mong muốn do lỗi. Một số ví dụ bao gồm:
- Các ứng dụng phát âm thanh mà không có dịch vụ trên nền trước có thể bị đóng băng. Khi ứng dụng cuối cùng được giải phóng, ứng dụng sẽ tiếp tục phát âm thanh một cách bất ngờ, có thể là vài giờ sau đó.
- Các ứng dụng phát âm thanh mà không có dịch vụ trên nền trước phải đối mặt với nhiều hạn chế khi chạy, dẫn đến hiệu suất âm thanh bị giật.
- Quá trình phát tách biệt với vòng đời hoạt động, điều này có thể dẫn đến rò rỉ phiên phát hoặc rò rỉ các sự kiện lấy tiêu điểm tiếp tục mà người dùng không có cách nào dừng phát.
Nhà phát triển nên kiểm thử ứng dụng của mình và gửi ý kiến phản hồi về thay đổi hành vi nếu có trường hợp sử dụng âm thanh có chủ đích nào bị ảnh hưởng tiêu cực. Vui lòng báo cáo mọi vấn đề bằng công cụ theo dõi vấn đề về khả năng tương thích của ứng dụng Android 17.
Xác định các trường hợp sử dụng âm thanh trong nền bị ảnh hưởng
Kiểm tra việc triển khai tính năng phát âm thanh và xác định xem ứng dụng của bạn có ý định cung cấp chức năng tương tác âm thanh ở chế độ nền hay không, ngay cả trong các trường hợp có điều kiện.
Nếu ứng dụng của bạn chỉ có ý định phát âm thanh hoặc sử dụng các API âm thanh trong khi đang hiển thị một hoạt động mà người dùng có thể thấy, bao gồm cả việc sử dụng chế độ Hình trong hình (PiP), thì ứng dụng đó sẽ không bị ảnh hưởng bởi bất kỳ thay đổi nào trong số này.
Nếu ứng dụng của bạn cung cấp chức năng VOIP (bao gồm cả ứng dụng gọi video), thì ứng dụng đó phải đáp ứng các yêu cầu được đưa ra đối với hoạt động phát (thường là thông qua việc sử dụng API viễn thông được đề xuất) để ghi lại âm thanh thành công. Do đó, ứng dụng của bạn khó có khả năng bị ảnh hưởng.
Nếu ứng dụng của bạn dự định tiếp tục phát âm thanh trong khi màn hình tắt hoặc trong khi người dùng đã hoàn toàn đóng hoạt động của bạn (thường thấy nhất trong các ứng dụng phát nhạc trực tuyến hoặc ứng dụng podcast), thì ứng dụng của bạn được coi là cung cấp chức năng âm thanh ở chế độ nền và phải đáp ứng các yêu cầu mới.
Các trường hợp âm thanh ở chế độ nền có khả năng bị ảnh hưởng
Nếu ứng dụng của bạn không tuân theo mô hình tiếp tục một hoạt động tương tác bằng âm thanh được bắt đầu khi ứng dụng của bạn đang mở hoặc để phản hồi một thao tác kích hoạt rõ ràng của người dùng, thì có thể chức năng của ứng dụng sẽ bị chặn âm thầm.
Ví dụ: nếu ứng dụng của bạn khởi động một dịch vụ trên nền trước để phản hồi BOOT_COMPLETE và cố gắng tương tác với âm thanh, thì dịch vụ đó sẽ bị chặn.
Các phương pháp hay nhất về âm thanh nền để giảm thiểu tác động
Sử dụng thành phần
MediaSessionServicecủa thư viện jetpack media3 để quản lý hoạt động phát âm thanh trong nền.Nếu bạn làm như vậy, ứng dụng của bạn sẽ không bị ảnh hưởng bởi quy trình tăng cường bảo mật ở chế độ nền do thư viện này hỗ trợ quản lý vòng đời phát.
Nếu không tận dụng thư viện media3, bạn sẽ cần phải tự khởi động một FGS
mediaPlayback. Luôn khởi động một dịch vụ trên nền trước trong khi ứng dụng đang ở nền trước nếu có thể xảy ra âm thanh trong nền.Ví dụ: nếu ứng dụng của bạn là một ứng dụng phát trực tuyến video thường chỉ chạy ở nền trước nhưng có một thành phần tương tác để người dùng tiếp tục phát khi màn hình tắt, thì khi xảy ra sự kiện kích hoạt hoạt động phát do người dùng khởi tạo, ứng dụng của bạn vẫn phải bắt đầu một dịch vụ trên nền trước.
Việc này giúp đảm bảo rằng dịch vụ trên nền trước được khởi động bằng các chức năng WIU.
Duy trì trạng thái hoạt động của
mediaPlaybackFGS trong thời gian xảy ra lỗi tạm thời dưới 10 phút.Nếu ứng dụng của bạn gặp lỗi tạm thời, chẳng hạn như vấn đề về việc lưu vào bộ nhớ đệm do hoạt động mạng hoặc có gián đoạn tạm thời dự kiến, chẳng hạn như
AUDIOFOCUS_LOSS_TRANSIENT, thì ý định phát phải tiếp tục. Do đó, FGS của bạn phải luôn hoạt động.Dừng dịch vụ trên nền trước khi kết thúc quá trình phát và chỉ khởi động lại quá trình phát nếu người dùng tiếp tục phát một cách rõ ràng.
Trong trường hợp có tín hiệu cố định để kết thúc quá trình phát (ví dụ: nội dung đã hoàn tất mà không có chế độ tự động phát,
AUDIOFOCUS_LOSS, sự kiện tạm dừng từ UMO hoặc sự kiện nhấn phím đa phương tiện) hoặc lỗi không thể khắc phục, ứng dụng của bạn phải ngừng hoạt động tương tác âm thanh, dừng dịch vụ trên nền trước và kết thúc phiên phát nội dung nghe nhìn. Tất cả những việc này tương ứng với quan niệm của người dùng về việc "kết thúc" hoạt động tương tác âm thanh ở chế độ nền mong muốn. Sau khi thực hiện việc này, ứng dụng của bạn sẽ không còn khả năng tương tác âm thanh ở chế độ nền nữa.Sau đó, nếu người dùng tiếp tục phát một cách rõ ràng, chẳng hạn như thông qua giao diện người dùng của ứng dụng hoặc thông qua nút phát của Universal Media Object, thì ý định bắt đầu phát âm thanh sẽ quay trở lại, dẫn đến việc FGS mới bắt đầu.
Kiểm thử hành vi phát âm thanh bằng các lệnh adb shell.
Kiểm thử các thay đổi trên Android 16 và Android 17
Tính năng này đã được triển khai ở cấp "cảnh báo" từ Android 16 trở đi. Điều này có nghĩa là các ứng dụng có thể dùng adb shell cmd audio
set-enable-hardening để kiểm thử thủ công việc thực thi biện pháp tăng cường bảo mật âm thanh trong nền.
Để bật chế độ thực thi trên các thiết bị chạy Android 16, hãy chạy lệnh sau:
adb shell cmd audio set-enable-hardening 1
Để tắt chế độ thực thi trên các thiết bị chạy Android 17, hãy chạy lệnh sau:
adb shell cmd audio set-enable-hardening 0
Bạn cũng nên sử dụng logcat hoặc lệnh adb adb dumpsys audio để xác định xem ứng dụng có gặp phải lỗi âm thầm do việc thực thi tính năng tăng cường bảo mật âm thanh hay không. Nếu có, nhật ký sẽ có một mục nhập có tiền tố là AudioHardening kèm theo tên gói của bạn.
Tìm hiểu về FGS có khả năng sử dụng trong khi đang dùng
Thông thường, dịch vụ trên nền trước (FGS) phải được khởi chạy trong khi ứng dụng ở nền trước để mở rộng các thao tác do người dùng đưa ra yêu cầu. Trong một số trường hợp cụ thể, các ứng dụng được phép chạy một dịch vụ trên nền trước trong khi ứng dụng đang ở chế độ nền. Tuy nhiên, các dịch vụ trên nền trước này thường không được cấp các chức năng Khi đang sử dụng (WIU).
WIU đóng vai trò là cổng bảo mật – ngăn FGS bắt đầu từ nền tham gia vào một số hành vi nhạy cảm khi người dùng có thể không biết về hoạt động của ứng dụng. Quyền này ngăn ứng dụng truy cập vào dữ liệu nhạy cảm như vị trí, camera hoặc micrô. Kể từ Android 17, quyền này cũng chặn các API âm thanh thường yêu cầu một bối cảnh giao diện người dùng hiển thị.
Sau đây là thông tin tham khảo hữu ích:
- FGS tiêu chuẩn: Các dịch vụ được khởi động trong khi ứng dụng hiển thị hoặc được cấp khả năng khởi chạy hoạt động ở chế độ nền sẽ được cấp quyền truy cập WIU.
- Dịch vụ ở nền trước bắt đầu từ FGS (BFSL): Hầu hết không cấp quyền truy cập WIU. Các trường hợp ngoại lệ chính cho phép WIU là những lượt tương tác liên quan đến ý định rõ ràng của người dùng, chẳng hạn như lượt nhấp vào thông báo, lượt tương tác với tiện ích hoặc sự kiện khoá đa phương tiện từ một thiết bị bên ngoài.
- Hệ thống đã khởi động FGS: FGS bắt đầu sử dụng uỷ quyền máy chủ hệ thống (ví dụ: bằng cách sử dụng thư viện Telecom Jetpack) được cấp quyền truy cập WIU.
Đọc thêm trong phần Các hạn chế khi khởi động dịch vụ trên nền trước từ nền.
Danh sách đầy đủ các API âm thanh bị ảnh hưởng
Chức năng âm thanh |
Kết quả |
Các API bị ảnh hưởng |
Phát âm thanh |
Đã tắt tiếng khi phát Không có ngoại lệ, không có thông báo lỗi nào do API cung cấp |
(NDK) Mọi thư viện nội dung đa phương tiện phía máy khách quản lý hoạt động phát (chẳng hạn như media3, Exoplayer và Oboe) cũng có thể bị ảnh hưởng. |
Yêu cầu quyền phát âm thanh |
Trả về Không ảnh hưởng đến việc phát âm thanh của các ứng dụng khác, không có quyền phát âm thanh |
|
API âm lượng và chế độ chuông |
Không ảnh hưởng đến chế độ hoặc âm lượng chuông (lệnh gọi phương thức sẽ bị bỏ qua một cách âm thầm) Không có ngoại lệ, không có thông báo lỗi nào do API cung cấp |
|