Các dịch vụ plugin mới của OEM trên ô tô trong Android 14 cho phép định cấu hình một số thành phần của ô tô. Cụ thể đối với âm thanh, chúng tôi giới thiệu 3 dịch vụ plugin mới, cho phép OEM linh hoạt định cấu hình tính năng quản lý âm thanh trên các thiết bị AAOS:
- Kiểm soát quyền phát âm thanh
- Kiểm soát âm lượng và tắt tiếng
- Kiểm soát tính năng giảm âm thanh
Kiến trúc dịch vụ plugin trên ô tô
Hình dưới đây cung cấp thông tin tổng quan về các dịch vụ trên ô tô và mối quan hệ của chúng với dịch vụ trên ô tô của OEM. Tương tự như các quy trình của ứng dụng và quy trình dịch vụ trên ô tô, quy trình dịch vụ trên ô tô của OEM chiếm không gian quy trình riêng.
Dịch vụ trên ô tô khởi động dịch vụ trên ô tô của OEM bằng cách tìm thành phần được xác định trong config_oemCarService. Nếu cấu hình trống, thì dịch vụ của OEM không tồn tại và không có dịch vụ nào được khởi động. Thành phần này phải mở rộng
OemCarService.
Dịch vụ âm thanh trên ô tô phải ghi đè các API để thu thập dịch vụ âm thanh trên ô tô của OEM:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Ví dụ
: hãy xem
ứng dụng kiểm thử tham chiếu được xác định trong
packages/services/Car/tests/OemCarServiceTestApp.
Mặc dù dịch vụ này được khởi động bởi dịch vụ trên ô tô, nhưng dịch vụ này không tự động kế thừa các quyền có sẵn cho dịch vụ âm thanh trên ô tô. Do đó, mọi quyền mà dịch vụ của OEM yêu cầu đều phải được thu thập bằng cơ chế thích hợp. Ví dụ: hãy xem packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Dịch vụ âm thanh trên ô tô có kiến trúc dịch vụ của OEM
Trong AAOS, dịch vụ âm thanh trên ô tô quản lý các hành động sau:
- Định tuyến âm thanh
- Quyền phát âm thanh
- Giảm âm thanh
- Âm lượng và tắt tiếng
Trước Android 14, hành vi này phần lớn là tĩnh và chỉ có thể được sửa đổi thông qua phần cài đặt, mặc dù chỉ dành cho một số trường hợp rất hạn chế. Android 14 đã giới thiệu một cơ chế để dịch vụ âm thanh trên ô tô giao tiếp với một thành phần do OEM xác định để quản lý:
- Quyền phát âm thanh
- Giảm âm thanh
- Âm lượng và tắt tiếng
Hình dưới đây cho thấy kiến trúc đơn giản hoá cho dịch vụ âm thanh trên ô tô và dịch vụ OEM trên ô tô. Dịch vụ âm thanh trên ô tô xác định nhiều hook có thể gọi dịch vụ âm thanh OEM trên ô tô để quản lý hành vi âm thanh. Điều này chỉ xảy ra nếu thành phần dịch vụ âm thanh trên ô tô của OEM tương ứng được xác định. Nếu không, dịch vụ âm thanh trên ô tô sẽ sử dụng hành vi mặc định.
Để đảm bảo rằng dịch vụ âm thanh trên ô tô và dịch vụ âm thanh OEM trên ô tô luôn đồng bộ, đối với mỗi lệnh gọi, dịch vụ âm thanh trên ô tô sẽ chuyển các phần bắt buộc của trạng thái hiện tại của ngăn xếp âm thanh sang dịch vụ âm thanh OEM trên ô tô. Ví dụ: khi dịch vụ âm thanh trên ô tô chặn một yêu cầu đánh giá quyền phát âm thanh, dịch vụ này sẽ chuyển trạng thái hiện tại của ngăn xếp sang dịch vụ âm thanh OEM trên ô tô. Trạng thái hiện tại bao gồm người giữ quyền phát âm thanh hiện tại và người mất quyền phát âm thanh hiện tại. Người mất quyền phát âm thanh là các yêu cầu về quyền phát âm thanh vẫn nằm trong ngăn xếp nhưng đã tạm thời mất quyền phát âm thanh.
Dịch vụ âm thanh trên ô tô phải quản lý mọi hoạt động âm thanh trong ô tô. Nếu dịch vụ âm thanh trên ô tô không quản lý một số phần của hành vi âm thanh, thì thông tin được cung cấp cho dịch vụ âm thanh OEM trên ô tô sẽ không đầy đủ. Ví dụ: nếu OEM ghi đè việc xử lý quyền phát âm thanh trong dịch vụ trên ô tô bằng cách đăng ký chính sách quyền phát âm thanh của riêng họ, thì dịch vụ âm thanh trên ô tô sẽ không thể cung cấp thông tin đầy đủ cho dịch vụ âm thanh OEM trên ô tô. Điều này có thể ảnh hưởng đến khả năng đưa ra quyết định của dịch vụ âm thanh OEM trên ô tô vì dịch vụ này có thể thiếu thông tin mà dịch vụ âm thanh trên ô tô không thấy được.
Để thực hiện các hành động, dịch vụ âm thanh trên ô tô sẽ gọi các dịch vụ trên ô tô của OEM. Các lệnh gọi này được thực hiện trên các quy trình, yêu cầu giao tiếp giữa các quy trình (IPC). IPC làm tăng độ trễ cho mỗi lệnh gọi. Bạn cần giảm thiểu độ trễ trong dịch vụ của OEM.
Vì các lệnh gọi dịch vụ âm thanh trên ô tô đến dịch vụ của OEM đang chặn, nên dịch vụ của OEM không được gọi dịch vụ âm thanh trên ô tô trong các lượt đánh giá API trực tiếp. Thay vào đó, dịch vụ âm thanh trên ô tô cung cấp thông tin cần thiết để các lệnh gọi giữa 2 quy trình chỉ cần di chuyển theo một hướng.
Định nghĩa dịch vụ âm thanh trên ô tô của OEM
Dịch vụ quyền phát âm thanh trên ô tô của OEM
Dịch vụ âm thanh trên ô tô quản lý các yêu cầu về quyền phát âm thanh từ ứng dụng bằng cách đăng ký trình nghe quyền phát âm thanh. Dịch vụ âm thanh trên ô tô có cơ chế quản lý hành vi quyền phát âm thanh dựa trên ma trận Tương tác tĩnh. Ma trận này xác định 3 loại tương tác:
Tương tác đồng thời. Người giữ quyền phát âm thanh có thể duy trì quyền phát âm thanh cùng lúc.
Tương tác độc quyền. Yêu cầu quyền phát âm thanh đến sẽ lấy quyền phát âm thanh từ người giữ quyền phát âm thanh hiện tại.
Tương tác từ chối. Yêu cầu quyền phát âm thanh đến bị từ chối dựa trên người giữ quyền phát âm thanh hiện tại.
Mặc dù điều này đủ cho một số trường hợp sử dụng trong lĩnh vực ô tô, nhưng không đáp ứng mọi nhu cầu tương tác có thể khác nhau do yêu cầu của OEM. Vì vậy, chúng tôi giới thiệu OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
API evaluateAudioFocusRequest được gọi từ dịch vụ âm thanh trên ô tô bất cứ khi nào có yêu cầu về quyền phát âm thanh cần được đánh giá. Đây là API 2 chiều chặn để trả về kết quả. Yêu cầu này chứa thông tin về trạng thái hiện tại của ngăn xếp âm thanh:
Bạn có thể sử dụng thông tin này để đánh giá newFocusRequest so với người giữ quyền phát âm thanh hiện tại trong focusHolders và người mất quyền phát âm thanh hiện tại trong focusLosers. API này sẽ trả về kết quả:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Kết quả này chứa thông tin về kết quả đánh giá thực tế trong audioFocusEvaluationResults, cho biết liệu yêu cầu hiện tại đã được cấp, bị trì hoãn hay không thành công. Mọi thay đổi đối với ngăn xếp quyền phát âm thanh hiện tại đều phải được đặt trong các mục newLosers và newlyBlocked, tuỳ thuộc vào bản chất của thay đổi ngăn xếp.
Trong đó, newLosers chứa các mục trước đây giữ quyền phát âm thanh nhưng hiện phải mất quyền phát âm thanh, vĩnh viễn hoặc tạm thời. Người mất quyền phát âm thanh vĩnh viễn sẽ bị xoá khỏi ngăn xếp quyền phát âm thanh và người mất quyền phát âm thanh tạm thời sẽ được chuyển sang ngăn xếp người mất quyền phát âm thanh hiện tại cho đến khi họ lấy lại quyền phát âm thanh hoặc bị người yêu cầu quyền phát âm thanh ban đầu bỏ qua. Bất kể điều gì, trình nghe quyền phát âm thanh cho các yêu cầu sẽ nhận được thông báo tương ứng về việc mất quyền phát âm thanh.
Danh sách newlyBlocked chứa các mục trước đây nằm trong danh sách người mất quyền phát âm thanh nhưng hiện bị mục mới chặn. Việc chặn có thể là vĩnh viễn hoặc tạm thời. Đối với việc chặn quyền phát âm thanh vĩnh viễn, mục này sẽ bị xoá khỏi ngăn xếp và thông báo mất quyền phát âm thanh sẽ được gửi đến trình nghe quyền phát âm thanh. Đối với việc mất quyền phát âm thanh tạm thời, mục này sẽ vẫn nằm trong ngăn xếp người mất quyền phát âm thanh nhưng một trình chặn quyền phát âm thanh mới sẽ được thêm vào danh sách trình chặn của mục đó. Không có thông báo mất quyền phát âm thanh nào được gửi vì thông báo đã được gửi trước đó khi mục này bị chặn lần đầu. Cuối cùng, yêu cầu sẽ được bỏ chặn khi tất cả trình chặn hiện tại bị xoá hoặc yêu cầu sẽ bị xoá khỏi ngăn xếp nếu quyền phát âm thanh bị bỏ qua.
API thứ hai, notifyAudioFocusChange, là API một chiều được gọi trên mọi yêu cầu hoặc bỏ qua quyền phát âm thanh. API này chủ yếu được dùng để thông báo cho dịch vụ của OEM về các thay đổi về quyền phát âm thanh, có thể ảnh hưởng đến hành vi của dịch vụ âm thanh trên ô tô của OEM.
Nguyên tắc đánh giá quyền phát âm thanh
Trong AAOS, quyền phát âm thanh được dùng để quản lý việc phát âm thanh và xác định ứng dụng nào phải tuân thủ để mang lại trải nghiệm tối ưu cho người dùng. Do đó, dịch vụ plugin của OEM phải tính đến những điều sau khi quản lý yêu cầu về quyền phát âm thanh:
Nếu không có quyền phát âm thanh có mức độ ưu tiên cao (chẳng hạn như cuộc gọi điện thoại, trường hợp khẩn cấp hoặc an toàn), thì ứng dụng sẽ có thể giành được quyền phát âm thanh tạm thời hoặc vĩnh viễn.
Trong khi quyền phát âm thanh cho nội dung nghe nhìn đang hoạt động, các ứng dụng yêu cầu:
Quyền phát âm thanh cho việc sử dụng cuộc gọi, sẽ có thể nhận được quyền phát âm thanh đồng thời hoặc độc quyền.
Quyền phát âm thanh cho việc sử dụng tính năng chỉ đường, sẽ có thể nhận được quyền phát âm thanh đồng thời hoặc độc quyền.
Quyền phát âm thanh cho việc sử dụng Trợ lý, sẽ có thể nhận được quyền phát âm thanh đồng thời hoặc độc quyền.
Trong khi các ứng dụng có quyền phát âm thanh có mức độ ưu tiên cao (chẳng hạn như cuộc gọi điện thoại, cảnh báo khẩn cấp hoặc cảnh báo an toàn) đang hoạt động, mọi yêu cầu quyền phát âm thanh đến bị trì hoãn sẽ được cấp hoặc bị trì hoãn theo nhu cầu.
Mặc dù các đề xuất ở trên chưa đầy đủ, nhưng có thể giúp đảm bảo rằng các ứng dụng yêu cầu quyền phát âm thanh sẽ có thể giành được quyền phát âm thanh khi không có âm thanh có mức độ ưu tiên cao đang hoạt động. Ngay cả khi âm thanh có mức độ ưu tiên cao đang hoạt động, các yêu cầu quyền phát âm thanh bị trì hoãn vẫn phải được tôn trọng và sẽ có thể giành được quyền phát âm thanh sau khi âm thanh có mức độ ưu tiên cao dừng.
Dịch vụ âm lượng trên ô tô của OEM
Dịch vụ âm thanh trên ô tô quản lý các sự kiện phím âm lượng bằng cách nghe các điều chỉnh âm lượng từ hệ thống âm thanh hoặc bằng cách nghe các sự kiện phím âm lượng trực tiếp từ dịch vụ đầu vào trên ô tô. Trong mỗi trường hợp, hành vi mặc định của dịch vụ âm thanh trên ô tô là xác định nhóm âm lượng nào cần thay đổi dựa trên các trình phát âm thanh đang hoạt động và danh sách mức độ ưu tiên theo bối cảnh âm thanh.
Chúng tôi cung cấp 2 danh sách mức độ ưu tiên theo âm lượng. Danh sách đầu tiên xem xét tất cả bối cảnh âm thanh theo thứ tự này. Danh sách được trình bày theo thứ tự giảm dần, mức độ ưu tiên cao nhất ở trên cùng và mức độ ưu tiên thấp nhất ở dưới cùng. Ví dụ: nếu âm thanh chỉ đường và âm thanh nhạc đều hoạt động cùng lúc, thì âm lượng chỉ đường sẽ thay đổi trong sự kiện phím âm lượng.
- Chỉ đường
- Gọi
- Âm nhạc
- Thông báo
- Lệnh thoại
- Chuông cuộc gọi
- Âm hệ thống
- An toàn
- Báo thức
- Thông báo
- Trạng thái xe
- Khẩn cấp
Để giúp việc quản lý sự kiện phím âm lượng ít phức tạp hơn, dịch vụ âm thanh trên ô tô có danh sách mức độ ưu tiên thứ hai theo bối cảnh âm thanh:
- Gọi
- Nội dung nghe nhìn
- Thông báo
- Lệnh thoại
Danh sách này cũng được trình bày theo thứ tự giảm dần. Mục đích của danh sách thứ hai này là cho phép thay đổi nhiều âm thanh phổ biến hơn thông qua các sự kiện phím. Bạn chỉ có thể quản lý các âm thanh không phổ biến, có thể là âm thanh có thời lượng ngắn hơn thông qua giao diện người dùng cài đặt âm thanh.
Bạn có thể đặt phiên bản thực tế của âm lượng bằng cấu hình audioVolumeAdjustmentContextsVersion. Bạn có thể đặt cấu hình thành 1 hoặc 2 (2 là giá trị mặc định).
Để mang lại sự linh hoạt hơn cho việc quản lý âm lượng, OemCarAudioVolumeService được giới thiệu trong Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Dịch vụ âm lượng trên ô tô của OEM có một phương thức duy nhất, nhận volumeAdjustment và OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
activePlaybackAttributes của yêu cầu có các thuộc tính âm thanh đang hoạt động. duckedAttributes là tất cả các thuộc tính âm thanh hiện đang giảm âm lượng. volumeGroupState có trạng thái hiện tại của nhóm âm lượng. Yêu cầu này thể hiện trạng thái hiện tại của ngăn xếp âm thanh và có thể được dùng để xác định nhóm âm lượng nào cần thay đổi. Kết quả sẽ được trả về trong OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Giá trị boolean change cho biết liệu có âm lượng nào thay đổi hay không, true cho biết có thay đổi và nhóm âm lượng cần được cập nhật. volumeGroupChanged là nhóm âm lượng thực tế cần thay đổi. Nhóm này phải được thay đổi theo tham số volumeAdjustment ban đầu được chuyển đến API. Ví dụ: nếu kết quả cho biết nhóm âm lượng chỉ đường phải bị tắt tiếng, thì giá trị boolean sẽ là true và nhóm âm lượng được trả về sẽ là nhóm âm lượng cho chỉ đường.
Dịch vụ giảm âm thanh trên ô tô của OEM
Dịch vụ âm thanh trên ô tô quản lý tính năng giảm âm thanh bằng cách theo dõi các thay đổi về quyền phát âm thanh và gửi tín hiệu đến HAL AudioControl về các thiết bị âm thanh cần giảm âm lượng.
Khi quyền phát âm thanh thay đổi, tất cả người giữ quyền phát âm thanh đang hoạt động sẽ được đánh giá để xác định
người nào cần giảm âm lượng dựa trên tập hợp quy tắc giảm âm thanh tĩnh
này:
- Âm thanh khẩn cấp giảm âm lượng mọi thứ, ngoại trừ âm thanh cuộc gọi
- Âm thanh an toàn giảm âm lượng mọi thứ, ngoại trừ âm thanh khẩn cấp
- Âm thanh chỉ đường giảm âm lượng mọi thứ, ngoại trừ âm thanh an toàn và khẩn cấp
- Âm thanh cuộc gọi giảm âm lượng mọi thứ, ngoại trừ âm thanh an toàn, khẩn cấp và chỉ đường
- Âm thanh thoại giảm âm lượng chuông cuộc gọi
- Âm nhạc và thông báo phải được giảm âm lượng bởi mọi thứ
Các quy tắc này chưa đầy đủ và OEM vẫn chịu trách nhiệm xác định cách giảm âm lượng âm thanh dựa trên các nguyên tắc này. OEM có thể kiểm soát các đề xuất này một cách chủ động hơn dựa trên các yêu cầu hiện có. OemCarDuckingService được giới thiệu trong Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
API này được gọi từ dịch vụ âm thanh trên ô tô khi có thay đổi về quyền phát âm thanh. API này sử dụng lại
OemCarAudioVolumeRequest được giới thiệu trong
dịch vụ âm lượng trên ô tô của OEM và chứa thông tin liên quan
để đưa ra quyết định về các thuộc tính cần giảm âm lượng. Danh sách các thuộc tính âm thanh cần giảm âm lượng từ API được so sánh với trạng thái âm thanh hiện tại:
Thuộc tính âm thanh hiện đang giảm âm lượng:
- Trong danh sách, tiếp tục giảm âm lượng
- Không có trong danh sách, đã tắt tính năng giảm âm lượng
Thuộc tính âm thanh hiện không giảm âm lượng:
- Trong danh sách, đã giảm âm lượng
- Không có trong danh sách, đã tắt tính năng giảm âm lượng
Sau đó, dịch vụ âm thanh trên ô tô sẽ xác định các thiết bị đầu ra âm thanh mà các thuộc tính âm thanh thuộc về và thêm các thiết bị đó vào danh sách thiết bị đầu ra âm thanh đã giảm âm lượng hoặc danh sách thiết bị âm thanh chưa giảm âm lượng. Cuối cùng, thông tin này được gửi đến AudioControl HAL để thực hiện việc giảm âm lượng cần thiết ở cấp phần cứng.
Hình dưới đây cho thấy sơ đồ trình tự đơn giản hoá của tính năng kiểm soát giảm âm thanh cho yêu cầu về quyền phát âm thanh khi dịch vụ giảm âm thanh của OEM được sử dụng:
Trình tự bắt đầu khi một ứng dụng yêu cầu
Quản lý quyền phát âm thanh
thông qua các API trình quản lý âm thanh công khai. Yêu cầu này được chuyển tiếp đến dịch vụ âm thanh trên ô tô để xác định kết quả. Khi quyền phát âm thanh được quyết định, tính năng giảm âm thanh sẽ được dịch vụ âm thanh trên ô tô đánh giá bằng cách gọi OemCarAudioDuckingService để đánh giá các thuộc tính âm thanh cần giảm âm lượng. Sau khi kết quả được trả về từ API evaluateAttributesToDuck, các thiết bị âm thanh cần giảm âm lượng sẽ được tính toán và cuối cùng, thông tin sẽ được gửi đến AudioControl để áp dụng tính năng giảm âm lượng cho phần cứng âm thanh.
Triển khai tham chiếu dịch vụ âm thanh trên ô tô của OEM
AAOS cung cấp bản triển khai tham chiếu dịch vụ trên ô tô của OEM trong
packages/services/Car/tests/OemCarServiceTestApp, triển khai
OemCarService, cùng với OemCarAudioFocusService,
OemCarAudioDuckingService, và OemCarAudioVolumeService. Đối với bản triển khai sau, mỗi dịch vụ sử dụng tệp XML để tải hành vi tĩnh. Ví dụ: OemCarAudioFocusServiceImp tải oem_focus_config.xml, chứa ma trận tương tác. Ma trận này được dùng để đánh giá yêu cầu về quyền phát âm thanh khi evaluateAudioFocusRequest được gọi.
Gỡ lỗi ứng dụng kiểm thử tham chiếu
Ứng dụng kiểm thử dịch vụ trên ô tô của OEM là một phần của mã nguồn AOSP. OEM có thể thay đổi theo nhu cầu của họ. Để gỡ lỗi, hãy sử dụng cấu hình config_oemCarService để bật ứng dụng kiểm thử.
<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>
Cách xác minh dịch vụ trên ô tô của OEM sử dụng lệnh dump của dịch vụ trên ô tô cho dịch vụ của OEM:
adb shell dumpsys car_service --oem-service
Kết quả có thể tương tự như đầu ra bên dưới:
***CarOemProxyService dump***
mIsFeatureEnabled: true
mIsOemServiceBound: true
mIsOemServiceReady: true
mIsOemServiceConnected: true
mInitComplete: true
OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl
Mỗi giá trị boolean trong mỗi lô thông tin dump sẽ xác định trạng thái của tính năng và dịch vụ. Ví dụ: thông tin dump mIsOemServiceReady chỉ định xem dịch vụ đã sẵn sàng sử dụng hay chưa, trong đó true cho biết dịch vụ đã sẵn sàng và false cho biết dịch vụ chưa sẵn sàng.