خدمات پلاگین صوتی خودرو

خدمات پلاگین OEM جدید خودرو در اندروید 14 پیکربندی برخی از اجزای خودرو را امکان پذیر می کند. به طور خاص برای صدا، سه سرویس افزونه جدید معرفی شده است که OEM ها را قادر می سازد تا مدیریت صوتی را به طور انعطاف پذیر در دستگاه های AAOS پیکربندی کنند:

  • کنترل فوکوس صوتی
  • کنترل صدا و بی صدا
  • کنترل اردک صوتی

معماری خدمات پلاگین خودرو

شکل زیر نمای کلی سرویس های خودرو و ارتباط آن ها با سرویس خودروهای OEM را ارائه می دهد. مشابه فرآیندهای برنامه و فرآیند خدمات خودرو، فرآیند سرویس خودرو OEM فضای فرآیند خود را اشغال می کند.

تصویر

سرویس خودرو با یافتن مؤلفه تعریف شده در config_oemCarService ، سرویس اتومبیل OEM را شروع می کند. اگر پیکربندی خالی باشد، سرویس OEM وجود ندارد و هیچ سرویسی راه اندازی نمی شود. مؤلفه باید OemCarService را گسترش دهد. سرویس صوتی خودرو باید APIها را برای دریافت سرویس OEM صدای خودرو بازنویسی کند:

public final class OemCarServiceImp extends OemCarService {
    @Override
    public OemCarAudioFocusService getOemAudioFocusService();

    @Override
    public OemCarAudioDuckingService getOemAudioDuckingService();

    @Override
    public OemCarAudioVolumeService getOemAudioVolumeService();
}

به عنوان مثال ، برنامه آزمایش مرجع تعریف شده در packages/services/Car/tests/OemCarServiceTestApp ببینید.

حتی اگر این سرویس توسط سرویس خودرو راه اندازی شود، به طور خودکار مجوزهای موجود برای سرویس صوتی خودرو را به ارث نمی برد. به این ترتیب، هر گونه مجوز مورد نیاز توسط سرویس های OEM باید با مکانیزم مناسب به دست آید. برای مثال، packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml ببینید.

خدمات صوتی خودرو با معماری سرویس OEM

در AAOS، سرویس صوتی خودرو این اقدامات را مدیریت می کند:

  • مسیریابی صدا
  • فوکوس صوتی
  • اردک صوتی
  • صدا و بی صدا

قبل از اندروید 14، این رفتار تا حد زیادی ثابت بود و فقط از طریق تنظیمات قابل تغییر بود، البته برای موارد بسیار محدود. اندروید 14 مکانیزمی را برای سرویس صوتی خودرو معرفی کرد تا با یک مؤلفه OEM تعریف شده ارتباط برقرار کند که مدیریت می کند:

  • فوکوس صوتی
  • اردک صوتی
  • صدا و بی صدا

شکل زیر یک معماری ساده شده برای سرویس صوتی خودرو و سرویس OEM خودرو را نشان می دهد. سرویس صوتی خودرو قلاب‌های مختلفی را تعریف می‌کند که می‌تواند با سرویس صوتی OEM خودرو برای مدیریت رفتار صوتی تماس بگیرد. مورد دوم تنها در صورتی رخ می‌دهد که مؤلفه خدمات صوتی OEM مربوطه تعریف شده باشد. در غیر این صورت سرویس صوتی خودرو از رفتار پیش فرض استفاده می کند.

تصویر

برای اطمینان از اینکه سرویس صوتی خودرو و سرویس صوتی OEM خودرو همیشه همگام هستند، برای هر تماس، سرویس صوتی خودرو قسمت های مورد نیاز وضعیت فعلی پشته صوتی را به سرویس صوتی OEM خودرو منتقل می کند. به عنوان مثال، هنگامی که سرویس صوتی خودرو درخواستی را برای ارزیابی فوکوس صوتی رهگیری می کند، وضعیت فعلی پشته را به سرویس صوتی OEM خودرو منتقل می کند. وضعیت فعلی شامل نگهدارنده تمرکز فعلی و بازنده‌های تمرکز فعلی است. بازنده‌های تمرکز، درخواست‌های تمرکز هستند که هنوز بخشی از پشته هستند، اما به طور موقت تمرکز خود را از دست داده‌اند.

سرویس صوتی خودرو باید تمامی فعالیت های صوتی خودرو را مدیریت کند. اگر سرویس صوتی خودرو برخی از بخش‌های رفتار صوتی را مدیریت نکند، اطلاعاتی که در معرض سرویس صوتی OEM خودرو قرار می‌گیرد ناقص است. به عنوان مثال، اگر یک OEM با ثبت خط مشی فوکوس صوتی خود، کنترل فوکوس صوتی را در سرویس خودرو بازنویسی کند، سرویس صوتی خودرو نمی تواند اطلاعات کاملی را به سرویس صوتی OEM خودرو ارائه دهد. این می‌تواند بر توانایی تصمیم‌گیری سرویس صوتی OEM خودرو تأثیر بگذارد، زیرا ممکن است فاقد اطلاعاتی باشد که برای سرویس صوتی خودرو قابل مشاهده نباشد.

برای انجام اقدامات، سرویس صوتی خودرو با خدمات خودرو OEM تماس می گیرد. این تماس ها در سراسر فرآیندها انجام می شود که به ارتباطات بین فرآیندی (IPC) نیاز دارد. IPC به هر تماس تاخیر اضافه می کند. به حداقل رساندن تاخیر در سرویس OEM بسیار مهم است.

از آنجایی که تماس‌های سرویس صوتی خودرو با سرویس OEM مسدود می‌شوند، سرویس OEM نباید در ارزیابی‌های مستقیم API با سرویس صوتی خودرو تماس بگیرد. در عوض، سرویس صوتی خودرو اطلاعات لازم را ارائه می دهد تا تماس بین دو فرآیند فقط در یک جهت انجام شود.

تعاریف سرویس صوتی اتومبیل OEM

خدمات فوکوس صوتی خودرو OEM

سرویس صوتی خودرو درخواست‌های فوکوس صوتی از برنامه‌ها را با ثبت شنونده تمرکز خط مشی صوتی مدیریت می‌کند. سرویس صوتی خودرو مکانیزمی برای مدیریت رفتار تمرکز بر اساس یک ماتریس تعامل ایستا دارد. ماتریس سه نوع تعامل مختلف را تعریف می کند:

  • تعامل همزمان دارندگان فوکوس می توانند در همان زمان تمرکز را حفظ کنند.

  • تعاملات انحصاری درخواست فوکوس ورودی فوکوس را از دارنده فوکوس فعلی می گیرد.

  • تعامل را رد کنید. درخواست فوکوس ورودی بر اساس دارنده فوکوس فعلی رد شد.

در حالی که این برای برخی موارد استفاده از خودرو کافی است، اما تمام نیازهای تعاملی را که ممکن است به دلیل نیازهای OEM متفاوت باشد، برآورده نمی کند. برای این کار ما OemCarAudioFocusService را معرفی می کنیم:

public interface OEmCarAudioFocusService {
    OemCarAuddioFocusResults evaluateAudioFocusRequest(
        OemCarAudioFocusEvaluationRequest request);
    
    void notifyAudioFocusChange(
        List<AudioFocusEntry> holder,
        List<AudioFocusEntry> losers, int zoneId);
}

API evaluateAudioFocusRequest هر زمان که درخواستی برای فوکوس صوتی وجود داشته باشد که باید ارزیابی شود از سرویس صوتی خودرو فراخوانی می شود، این یک API دو طرفه است که بازگشت نتایج را مسدود می کند. این درخواست حاوی اطلاعاتی درباره وضعیت فعلی پشته صوتی است:

این اطلاعات می تواند برای ارزیابی newFocusRequest در مقایسه با دارندگان تمرکز فعلی در focusHolders و بازنده های فعلی تمرکز در focusLosers استفاده شود. API باید نتایج را برگرداند:

class OemCarAudioFocusResult {
    int audioZoneId;
    int audioFocusEvaluationResults;
    AudioFocusEntry focusResult;
    List<AudioFocusEntry> newLosers;
    List<AudioFocusEntry> newlyBlocked;
}

این شامل اطلاعات مربوط به نتایج ارزیابی واقعی در audioFocusEvaluationResults است که نشان می‌دهد آیا درخواست فعلی اعطا شده است، به تأخیر افتاده است یا ناموفق بوده است. بسته به ماهیت تغییر پشته، هرگونه تغییر در پشته فوکوس فعلی باید در ورودی‌های newLosers و newlyBlocked تنظیم شود.

جایی که newLosers حاوی ورودی‌هایی است که قبلاً فوکوس را حفظ می‌کردند، اما اکنون باید به طور دائم یا موقتی تمرکز خود را از دست بدهند. بازنده‌های فوکوس دائمی بیشتر از پشته فوکوس صوتی حذف می‌شوند، و بازنده‌های فوکوس گذرا به پشته بازنده‌های فوکوس فعلی منتقل می‌شوند تا زمانی که فوکوس را دوباره به دست آورند یا از درخواست‌کننده تمرکز اصلی رها شوند. صرف نظر از این، شنونده فوکوس درخواست ها فوکوس مربوطه را از دست می دهد.

لیست newlyBlocked شامل ورودی‌هایی است که قبلاً در فهرست بازنده تمرکز بودند اما اکنون توسط ورودی جدید مسدود شده‌اند. بلوک می تواند دائمی یا گذرا باشد، برای فوکوس دائمی مسدود شده، ورودی از پشته حذف می شود و از دست دادن فوکوس برای شنوندگان فوکوس ارسال می شود. برای از دست دادن فوکوس گذرا، ورودی در پشته بازنده‌های فوکوس باقی می‌ماند، اما یک مسدودکننده فوکوس جدید به فهرست مسدودکننده‌های آن اضافه می‌شود، هیچ از دست دادن فوکوس ارسال نمی‌شود، همانطور که قبلاً در هنگام مسدود شدن آن ارسال شده بود. زمانی که تمام مسدودکننده‌های فعلی حذف شوند، درخواست در نهایت رفع انسداد می‌شود، یا در صورت رها شدن تمرکز، از پشته حذف می‌شود.

دومین API، notifyAudioFocusChange ، راهی است که در هر درخواست فوکوس صوتی یا رها کردن آن فراخوانی می شود. API بیشتر برای اطلاع رسانی به سرویس OEM در مورد تغییرات فوکوس استفاده می شود که ممکن است بر رفتار سرویس صوتی اتومبیل OEM تأثیر بگذارد.

رهنمودهایی برای ارزیابی تمرکز

در AAOS، فوکوس صوتی برای مدیریت پخش صدا و تعیین اینکه کدام برنامه باید از آن استفاده کند تا تجربه مطلوبی را برای کاربر فراهم کند، استفاده می‌شود. به این ترتیب، سرویس پلاگین OEM باید موارد زیر را هنگام مدیریت درخواست فوکوس صوتی در نظر بگیرد:

  • برنامه‌ها بدون فوکوس صوتی با اولویت بالا (مانند تماس تلفنی، اضطراری یا ایمنی) باید بتوانند فوکوس صوتی را به‌طور موقت یا دائم به دست آورند.

  • وقتی تمرکز رسانه فعال است، برنامه‌ها درخواست می‌کنند:

    • تمرکز استفاده از تماس، باید بتواند فوکوس را همزمان یا انحصاری دریافت کند.

    • فوکوس استفاده از ناوبری، باید بتواند فوکوس را به صورت همزمان یا انحصاری دریافت کند.

    • فوکوس استفاده از دستیار، باید بتواند فوکوس را به صورت همزمان یا انحصاری دریافت کند.

  • در حالی که برنامه‌های فوکوس صوتی با اولویت بالا (مانند تماس تلفنی، هشدار اضطراری، یا هشدار ایمنی) فعال هستند، هر درخواست فوکوس صوتی تاخیری دریافتی باید در صورت لزوم اعطا شود یا به تأخیر بیفتد.

در حالی که پیشنهادات بالا جامع نیستند، می‌توانند تضمین کنند که برنامه‌هایی که فوکوس را درخواست می‌کنند، زمانی که صداهای با اولویت بالا فعال وجود ندارد، بتوانند فوکوس را به دست آورند. حتی در حالی که صداهای با اولویت بالا فعال هستند، درخواست‌های فوکوس تأخیری همچنان باید رعایت شوند و پس از توقف صدای اولویت بالا باید بتوان فوکوس را به دست آورد.

سرویس حجم خودرو OEM

سرویس صدای خودرو، رویدادهای کلید میزان صدا را با گوش دادن به تنظیمات صدا از سیستم صوتی یا با گوش دادن به رویدادهای کلید صدا مستقیماً از سرویس ورودی خودرو مدیریت می‌کند. در هر مورد، رفتار پیش‌فرض سرویس صوتی خودرو این است که بر اساس پخش‌کننده‌های صوتی فعال و فهرست اولویت‌های زمینه صوتی، تعیین کند که کدام گروه صدا را تغییر دهد.

ما دو لیست اولویت جلد را ارائه می دهیم. فهرست اول تمام زمینه های صوتی را به این ترتیب در نظر می گیرد. فهرست به ترتیب نزولی، بالاترین اولویت در بالا و کمترین اولویت در پایین ارائه شده است. به عنوان مثال، اگر صدای پیمایش و صدای موسیقی هر دو همزمان فعال باشند، صدای پیمایش در طول یک رویداد کلید صدا تغییر می‌کند.

  1. ناوبری
  2. تماس بگیرید
  3. موسیقی
  4. اعلامیه
  5. فرمان صوتی
  6. زنگ تماس
  7. صدای سیستم
  8. ایمنی
  9. زنگ هشدار
  10. اطلاع رسانی
  11. وضعیت خودرو
  12. اورژانس

برای اینکه مدیریت رویداد کلید حجم صدا کمتر پیچیده شود، سرویس صوتی خودرو دارای یک لیست اولویت دوم از زمینه صوتی است:

  1. تماس بگیرید
  2. رسانه ها
  3. اعلامیه
  4. فرمان صوتی

این لیست نیز به ترتیب نزولی ارائه شده است. هدف از این فهرست دوم این است که امکان تغییر صداهای رایج تر از طریق رویدادهای کلیدی را فراهم کند. غیر معمول، شاید صداهایی با مدت زمان کمتر، فقط از طریق رابط کاربری تنظیمات صوتی قابل مدیریت هستند.

نسخه واقعی صدا را می توان با پیکربندی audioVolumeAdjustmentContextsVersion تنظیم کرد. پیکربندی را می توان روی 1 یا 2 تنظیم کرد ( 2 پیش فرض است).

برای ارائه انعطاف‌پذیری بیشتر به مدیریت حجم، OemCarAudioVolumeService در اندروید 14 معرفی شده است:

public interface OemCarAudioVolumeService {
    OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}

سرویس ولوم صدای خودرو OEM یک روش دارد که شامل یک volumeAdjustment و یک OemCarAudioVolumeRequest می شود:

class OemCarAudioVolumeRequest {
    int audioZoneId;
    int callState;
    List<AudioAttributes> activePlaybackAttributes;
    List<AudioAttributes> duckedAttributes;
    List<CarVolumeGroupInfo> volumeGroupState;
}

activePlaybackAttributes درخواست دارای ویژگی های صوتی فعال است. duckedAttributes همه در حال حاضر ویژگی های صوتی ducked هستند. volumeGroupState وضعیت فعلی گروه volume را دارد. این درخواست وضعیت فعلی پشته صوتی را نشان می دهد و می تواند برای تعیین اینکه کدام گروه صدا باید تغییر کند استفاده می شود. نتایج باید در OemCarVolumeChangeInfo بازگردانده شوند:

class OemCarVolumeChangeInfo {
    boolean change;
    CarVolumeGroupInfo volumeGroupChanged;
}

change بولی نشان می دهد که اگر حجمی تغییر کرده باشد، true نشان می دهد که تغییری وجود دارد و گروه حجم باید به روز شود. volumeGroupChanged گروه حجم واقعی است که باید تغییر کند. این گروه باید با توجه به پارامتر volumeAdjustment اصلی که به API ارسال شده تغییر کند. به عنوان مثال، اگر نتایج نشان می‌دهد که گروه حجم ناوبری باید بی‌صدا شود، آنگاه مقدار بولی true است و گروه حجم بازگشتی باید برای ناوبری باشد.

سرویس اردک خودرو OEM

سرویس صوتی خودرو با نظارت بر تغییرات فوکوس صدا و ارسال سیگنالی به AudioControl HAL در مورد اینکه کدام دستگاه‌های صوتی باید اردک صدا را انجام دهند، پخش صدا را مدیریت می‌کند. هنگامی که فوکوس تغییر می‌کند، همه نگهدارنده‌های فوکوس فعال ارزیابی می‌شوند تا بر اساس این مجموعه از قوانین داکینگ استاتیک، مشخص شود که کدام یک باید از بین برود:

  • صداهای اضطراری همه چیز را به جز صداهای تماس خراب می کند
  • ایمنی همه چیز را به جز صداهای اضطراری رد می کند
  • ناوبری همه چیز را به جز صداهای ایمنی و اضطراری کاهش می دهد
  • همه چیز را به جز صداهای ایمنی، اضطراری و ناوبری صدا کنید
  • اردک های صوتی صدای زنگ را صدا می زنند
  • موسیقی و اعلان ها باید با همه چیز کنار گذاشته شوند

این قوانین جامع نیستند و OEM ها مسئول تعیین نحوه پخش صداها بر اساس این دستورالعمل ها هستند. OEM ها می توانند این توصیه ها را به طور فعالتری بر اساس نیازهای موجود کنترل کنند. OemCarDuckingService در اندروید 14 معرفی شده است:

class OemCarAudioDuckingService {
List<AudioAttributes>   evaluateAttributesToDuck(
        OemCarAudioVolumeRequest request);
}

این API از سرویس صوتی خودرو در مورد تغییرات فوکوس صوتی فراخوانی می شود. مجدداً از OemCarAudioVolumeRequest معرفی شده در سرویس حجم خودرو OEM استفاده می‌کند و حاوی اطلاعات مربوطه برای تصمیم‌گیری درباره ویژگی‌های اردک است. فهرست ویژگی‌های صوتی duck از API با وضعیت صوتی فعلی مقایسه می‌شود:

  • ویژگی صوتی در حال حاضر کاهش یافته است:

    • در لیست، همچنان در حال رد شدن است
    • در لیست نیست، ducking خاموش است

  • ویژگی صوتی در حال حاضر حذف نشده است:

    • در لیست، نادیده گرفته شده است
    • در لیست نیست، ducking خاموش است

سپس سرویس صوتی خودرو تعیین می‌کند که ویژگی‌های صوتی به کدام دستگاه‌های خروجی صوتی تعلق دارند و آنها را به ترتیب به لیست دستگاه‌های خروجی صدای دوک یا فهرست دستگاه‌های صوتی بدون بند اضافه می‌کند. این در نهایت به AudioControl HAL فرستاده می‌شود تا در سطح سخت‌افزاری ducking مورد نیاز را انجام دهد.

شکل زیر یک نمودار توالی ساده از کنترل داکینگ صوتی را برای درخواست فوکوس در هنگام استفاده از سرویس داکینگ OEM نشان می دهد:

تصویر

این توالی زمانی شروع می‌شود که یک برنامه درخواست مدیریت فوکوس صوتی از طریق APIهای مدیریت صوتی عمومی را می‌دهد. درخواست برای تعیین نتایج به سرویس صوتی خودرو ارسال می شود. هنگامی که فوکوس صوتی تصمیم گیری می شود، پخش صدا توسط سرویس صوتی خودرو که OemCarAudioDuckingService را فراخوانی می کند، ارزیابی می شود تا مشخص شود کدام ویژگی های صوتی باید حذف شوند. هنگامی که نتایج از API evaluateAttributesToDuck برگردانده شد، دستگاه‌های صوتی به duck محاسبه می‌شوند و در نهایت اطلاعات به AudioControl ارسال می‌شود تا ducking به سخت‌افزار صوتی اعمال شود.

پیاده سازی مرجع خدمات صوتی اتومبیل OEM

AAOS یک پیاده‌سازی مرجع از سرویس خودرو OEM در packages/services/Car/tests/OemCarServiceTestApp ارائه می‌کند که OemCarService را همراه با OemCarAudioFocusService ، OemCarAudioDuckingService و OemCarAudioVolumeService پیاده‌سازی می‌کند. برای مورد دوم، هر سرویس از فایل XML برای بارگذاری یک رفتار ثابت استفاده می کند. به عنوان مثال، OemCarAudioFocusServiceImp oem_focus_config.xml را بارگیری می کند که حاوی یک ماتریس تعامل است. هنگامی که evaluateAudioFocusRequest فراخوانی می شود، ماتریس برای ارزیابی درخواست تمرکز استفاده می شود.

مرجع اشکال زدایی برنامه آزمایشی

برنامه تست خدمات خودرو OEM بخشی از کد منبع AOSP است. OEM ها می توانند با توجه به نیاز خود تغییراتی ایجاد کنند. برای رفع اشکال، از پیکربندی config_oemCarService برای فعال کردن برنامه آزمایشی استفاده کنید.

<!-- 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>

برای تأیید سرویس اتومبیل OEM از دستور dump car service برای سرویس OEM استفاده می کند:

adb shell dumpsys car_service --oem-service

نتایج می تواند مشابه خروجی زیر باشد: 

***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

هر بولی در هر دسته از اطلاعات dump وضعیت ویژگی و سرویس را تعیین می کند. به عنوان مثال، اطلاعات dump mIsOemServiceReady مشخص می کند که آیا سرویس آماده استفاده است، جایی که true نشان دهنده آماده بودن و false نشان دهنده آماده نبودن آن است.