یکپارچه سازی جریان دارد

انتخاب VIA فعال توسط ManageAssistActivity در CarSettings انجام می‌شود. این جریان توسط برنامه PackageInstaller ، به عنوان بخشی از بخش برنامه‌های پیش‌فرض در صفحه تنظیمات، آغاز می‌شود.

برنامه‌های پیش‌فرض در صفحه تنظیمات

شکل ۱. برنامه‌های پیش‌فرض در صفحه تنظیمات

VIA انتخاب شده به دو روش در معرض سیستم قرار می‌گیرد:

  1. به عنوان بخشی از سرویس سیستم RolesManager
  2. توسط VoiceInteractionManagerService از طریق API داخلی AssistUtils .

فهرستی از VIA های کاندید را می‌توان با استفاده از RolesManager با نام نقش android.app.role.ASSISTANT بدست آورد.

فعال‌سازی کلمات کلیدی

اندروید AlwaysOnHotwordDetector را به عنوان یک انتزاع در بالای DSP سخت‌افزاری ارائه می‌دهد. این یک روش مناسب برای مرتبط کردن VoiceInteractionService با یک مدل صوتی برای تشخیص صدای همیشه روشن با مصرف انرژی کم فراهم می‌کند. این رایج‌ترین و شناخته‌شده‌ترین جریان تعامل است که در آن کاربر درخواست تعامل با یک برنامه صوتی (VA) را برای شروع یک مکالمه جدید می‌دهد. جلسات صوتی که از این طریق آغاز می‌شوند با SHOW_SOURCE_ASSIST_GESTURE flag شناسایی می‌شوند.

فعال‌سازی کلمات کلیدی

شکل ۲. فعال‌سازی کلید واژه

راهنما. سرویس‌های سیستم با رنگ آبی روشن و اجزای VIA با رنگ سبز نمایش داده می‌شوند.

فعال شدن PTT

این امر در مورد فشار دادن طولانی یا کوتاه دکمه سخت‌افزاری صدق می‌کند. در AAOS، PTT توسط CarInputService مدیریت می‌شود. در پیاده‌سازی پیش‌فرض، این سرویس رویدادهای ورودی دریافتی از طریق Vehicle HAL را مدیریت می‌کند و در مورد خاص تعامل صوتی، منطق زیر را برای رویدادهای کلیدی اعمال می‌کند:

  • رویدادهای کوتاه PTT ( KeyEvent.KEYCODE_VOICE_ASSIST ) برای شروع یک جلسه صوتی جدید به VoiceInteractionManagerService هدایت می‌شوند.
  • رویدادهای PTT طولانی ابتدا به گیرنده‌های پروژکتور (مثلاً Android Auto یا CarPlay)، سپس به دستگاه‌های متصل به بلوتوث و در نهایت به برنامه محلی VIA ارسال می‌شوند.

جلساتی که با استفاده از این جریان شروع می‌شوند با SHOW_SOURCE_PUSH_TO_TALK شناسایی می‌شوند.

فعال شدن PTT

شکل 3. فعال‌سازی PTT

برای ادغام دکمه کنترل صوتی سخت‌افزاری با AAOS، به ادغام ورودی کلید خودرو مراجعه کنید.

فعال‌سازی با لمس (یا دکمه نرم‌افزاری)

فعال‌سازی تعامل صوتی از رابط کاربری سیستم با استفاده از AssistUtil انجام می‌شود. این یک API سیستمی پنهان است که فقط می‌تواند توسط برنامه‌های سیستمی همراه مانند رابط کاربری سیستم که موارد زیر را فعال می‌کند، استفاده شود:

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

برای ارائه پویای برنامه VIA انتخاب شده، رابط کاربری سیستم می‌تواند از RoleManager استفاده کند و تغییرات را در دارنده نقش برای ROLE_ASSISTANT دنبال کند. نمونه‌ای از نحوه پیاده‌سازی راه‌اندازی TTT را می‌توان در CarSystemUI، AssistantButton ، یافت.

فعال‌سازی با لمس کردن برای صحبت کردن

شکل ۴. فعال‌سازی با لمس کردن و صحبت کردن

دستیار صوتی با لمس کردن و خواندن (TTR)

در صنعت خودرو، اعلان‌های ارسال شده به مرکز اعلان‌ها که با نام‌های INBOX یا INBOX_IN_GROUP شناخته می‌شوند (برای مثال، پیام‌های SMS) شامل یک دکمه‌ی پخش هستند که به کاربر اجازه می‌دهد اعلان‌ها را با صدای بلند توسط VIA انتخاب شده بخواند و در صورت تمایل، با صدا پاسخ دهد.

اعلان‌ها

شکل ۵. اعلان‌ها

برای اطلاعات بیشتر در مورد نحوه پیاده‌سازی این جریان، به دستورات مدیریت پیام‌رسانی مراجعه کنید.

راه اندازی VIA از لانچر ماشین

مانند هر برنامه دیگری، VIAها می‌توانند یک یا چند فعالیت لانچر را در مانیفست خود داشته باشند. تصمیم‌گیری در مورد اینکه این فعالیت‌ها چه کاری انجام دهند، به توسعه‌دهنده برنامه و تولیدکننده اصلی (OEM) که نصب اولیه این برنامه را پذیرفته است، بستگی دارد.

مهم. در صنعت خودرو، تمام فعالیت‌ها، از جمله فعالیت‌های سیستم، مشمول محدودیت‌های UX در حین رانندگی هستند. اگر تجربه‌ای که می‌خواهید از یک آیکون لانچر فعال کنید باید در حین رانندگی در دسترس باشد، یا آن را به لیست مجاز اضافه کنید (اگر تولیدکننده اصلی تجهیزات هستید) یا فعالیت را با فراداده distractionOptimized حاشیه‌نویسی کنید. برای اطلاعات بیشتر، به دستورالعمل‌های حواس‌پرتی راننده مراجعه کنید.

DSP و HAL صوتی

حتماً دستورالعمل‌های به‌روز شده در مورد ضبط صدای همیشه روشن همزمان و HAL صوتی را در Concurrent capture بررسی کنید. دسترسی به این APIها ممکن است تأثیر قابل توجهی بر عملکرد تشخیص کلمات کلیدی داشته باشد، همانطور که در Responding to hotwords توضیح داده شده است.

مجوزها

اعطای مجوزهای سیستمی

با توجه به اینکه کاربر نمی‌تواند مجوزهای ویژه را اعطا کند، اگر یک VIA به هر یک از آنها نیاز داشته باشد، تولیدکنندگان اصلی تجهیزات (OEM) باید APK خود را در تصاویر سیستم خود از قبل بارگذاری کنند و آن مجوزها را صریحاً در ساخت‌های خود اعطا کنند. به درخواست مجوزها مراجعه کنید.

برای انجام این کار، یک وابستگی به privilege allowlist به پروژه خود اضافه کنید:

Android.bp

android_app {
     ...
     required: ["privapp_allowlist_com.example.myvoicecontrol"],
     ...
}

فایل مجوز system-privilege allowlist را به پوشه yourdata/etc/car اضافه کنید:

vendor/…/data/etc/car/Android.bp

prebuilt_etc {
    name:privapp_allowlist_com.example.myvoicecontrol",
    sub_dir: "permissions",
    src: "com.example.myvoicecontrol.xml",
    filename_from_src: true,
}

vendor/…/data/etc/car/com.example.myvoicecontrol.xml

<?xml version="1.0" encoding="utf-8"?>
<permissions>
    <privapp-permissions package="com.android.car.voicecontrol">
        <permission name="android.permission.MEDIA_CONTENT_CONTROL"/>
    </privapp-permissions>
</permissions>

پیش‌اعطای مجوزهای خطرناک

همانطور که در بخش درخواست مجوزها نشان داده شده است، VIA برای دسترسی به برخی از قابلیت‌ها به رضایت کاربر نیاز دارد. برخی از این مجوزها به VoiceInteractionService پیش‌فرض اعطا شده‌اند (به DefaultPermissionGrantPolicy.java مراجعه کنید). برای اطلاعات بیشتر در مورد مجوزهای مربوط به کنترل‌کننده‌های پیش‌فرض، به Permissions used only in default handlers مراجعه کنید. همچنین می‌توان با استفاده از فایل پیکربندی default-permissions.xml ، مجوزها را از قبل اعطا کرد. برای جزئیات بیشتر در مورد محدودیت‌های مربوط به پیش اعطای مجوزها، به بخش 9 در سند تعریف سازگاری اندروید (CDD) مراجعه کنید.

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

توزیع (پیش نصب و استقرار به‌روزرسانی‌ها)

VIA های از پیش نصب شده باید در پارتیشن‌ها و پوشه‌های /product/priv-apps یا /vendor/priv-apps قرار داشته باشند (برای اطلاعات بیشتر در مورد پارتیشن‌ها به Partitions overview و Build product partitions مراجعه کنید).

در حالت دوم، با توجه به اینکه پارتیشن فروشنده می‌تواند جداگانه از سیستم به‌روزرسانی شود، برنامه‌های میزبانی شده در اینجا قادر به دسترسی به APIهای سیستم @hide نخواهند بود. بسته به محل برنامه‌های از پیش نصب شده، به‌روزرسانی‌ها می‌توانند به صورت OTA (به به‌روزرسانی‌های OTA مراجعه کنید) یا از طریق به‌روزرسانی‌های برنامه از یک فروشگاه برنامه انجام شوند.

سفارشی‌سازی

همانطور که در مفاهیم خاص خودرو ذکر شد، سازگاری و سفارشی‌سازی رابط کاربری/تجربه کاربری در خودرو از هر فرم فاکتور دیگری مهم‌تر است. برای حداکثر قابلیت همکاری، استفاده از کتابخانه رابط کاربری خودرو AAOS اکیداً توصیه می‌شود. این کتابخانه شامل اجزا و منابعی است که می‌توانند در برنامه‌های خودرو که برای سفارشی‌سازی توسط تولیدکنندگان اصلی تجهیزات (OEM) طراحی شده‌اند، ادغام شوند. به این ترتیب، می‌توان یک APK واحد را به گونه‌ای ساخت که رابط کاربری آن با طراحی هر مدل خودرو سفارشی شود.