অ্যান্ড্রয়েড ১৪-এর নতুন কার OEM প্লাগইন সার্ভিসগুলো গাড়ির কিছু কম্পোনেন্ট কনফিগার করার সুযোগ করে দেয়। বিশেষ করে অডিওর জন্য তিনটি নতুন প্লাগইন সার্ভিস চালু করা হয়েছে, যা OEM-দের AAOS ডিভাইসগুলোতে অডিও ম্যানেজমেন্টকে সুবিধাজনকভাবে কনফিগার করতে সক্ষম করে:
- অডিও ফোকাস নিয়ন্ত্রণ
- অডিও ভলিউম এবং মিউট নিয়ন্ত্রণ
- অডিও ডাকিং নিয়ন্ত্রণ
গাড়ির প্লাগইন পরিষেবা স্থাপত্য
নিচের চিত্রটিতে গাড়ির পরিষেবাগুলো এবং OEM গাড়ির পরিষেবার সাথে তাদের সম্পর্কের একটি সংক্ষিপ্ত বিবরণ দেওয়া হয়েছে। অ্যাপ প্রসেস এবং গাড়ির পরিষেবা প্রসেসের মতোই, OEM গাড়ির পরিষেবা প্রসেসটিও তার নিজস্ব প্রসেস স্পেস দখল করে।
কার সার্ভিস, config_oemCarService এ সংজ্ঞায়িত কম্পোনেন্টটি খুঁজে বের করার মাধ্যমে OEM কার সার্ভিস চালু করে। যদি কনফিগটি খালি থাকে, তাহলে OEM সার্ভিসটির অস্তিত্ব থাকে না এবং কোনো সার্ভিস চালু হয় না। কম্পোনেন্টটিকে অবশ্যই OemCarService এক্সটেন্ড করতে হবে। কার অডিও সার্ভিসকে অবশ্যই কার অডিও OEM সার্ভিস অ্যাকোয়ার করার জন্য ব্যবহৃত API-গুলোকে ওভাররাইট করতে হবে।
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-এ, গাড়ির অডিও পরিষেবা এই কাজগুলো পরিচালনা করে:
- অডিও রাউটিং
- অডিও ফোকাস
- অডিও ডাকিং
- ভলিউম এবং মিউট
অ্যান্ড্রয়েড ১৪-এর আগে, এই আচরণটি মূলত অপরিবর্তিত ছিল এবং শুধুমাত্র সেটিংসের মাধ্যমে পরিবর্তন করা যেত, যদিও তা ছিল খুবই সীমিত কিছু ক্ষেত্রে। অ্যান্ড্রয়েড ১৪ গাড়ির অডিও পরিষেবার জন্য একটি ব্যবস্থা চালু করেছে, যার মাধ্যমে এটি একটি 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);
}
যখনই অডিও ফোকাস মূল্যায়নের জন্য কোনো অনুরোধ আসে, তখন গাড়ির অডিও পরিষেবা থেকে evaluateAudioFocusRequest API-টি কল করা হয়। এটি একটি দ্বি-মুখী API যা ফলাফল ফিরে আসা পর্যন্ত ব্লক করে থাকে। অনুরোধটিতে অডিও স্ট্যাকের বর্তমান অবস্থা সম্পর্কিত তথ্য থাকে:
এই তথ্যটি focusHolders এ থাকা বর্তমান ফোকাস হোল্ডার এবং focusLosers এ থাকা বর্তমান ফোকাস হারানো ব্যক্তিদের সাথে newFocusRequest কে তুলনা করে মূল্যায়ন করতে ব্যবহার করা যেতে পারে। API-টি নিম্নলিখিত ফলাফল ফেরত দেবে:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
audioFocusEvaluationResults এ প্রকৃত মূল্যায়ন ফলাফল সম্পর্কিত তথ্য থাকে, যা নির্দেশ করে যে বর্তমান অনুরোধটি মঞ্জুর করা হয়েছে, বিলম্বিত হয়েছে, নাকি ব্যর্থ হয়েছে। স্ট্যাক পরিবর্তনের প্রকৃতির উপর নির্ভর করে, বর্তমান ফোকাস স্ট্যাকের যেকোনো পরিবর্তন newLosers এবং newlyBlocked এন্ট্রিতে সেট করা উচিত।
যেখানে newLosers এমন এন্ট্রিগুলো থাকে যেগুলো আগে ফোকাস ধরে রেখেছিল কিন্তু এখন স্থায়ীভাবে বা সাময়িকভাবে ফোকাস হারানো উচিত। স্থায়ীভাবে ফোকাস হারানো এন্ট্রিগুলোকে অডিও ফোকাস স্ট্যাক থেকে আরও সরিয়ে দেওয়া হবে, এবং সাময়িকভাবে ফোকাস হারানো এন্ট্রিগুলোকে বর্তমান ফোকাস হারানো স্ট্যাকে স্থানান্তরিত করা হবে যতক্ষণ না তারা পুনরায় ফোকাস ফিরে পায় বা মূল ফোকাস অনুরোধকারী থেকে পরিত্যক্ত হয়। যাই হোক না কেন, অনুরোধগুলোর জন্য ফোকাস লিসেনার একটি সংশ্লিষ্ট ফোকাস হারানোর বার্তা পাবে।
newlyBlocked তালিকায় এমন এন্ট্রিগুলো থাকে যেগুলো আগে ফোকাস হারানো এন্ট্রির তালিকায় ছিল কিন্তু এখন নতুন এন্ট্রির কারণে ব্লক হয়েছে। এই ব্লক স্থায়ী বা অস্থায়ী হতে পারে। স্থায়ীভাবে ফোকাস ব্লক হলে, এন্ট্রিটি স্ট্যাক থেকে সরিয়ে দেওয়া হবে এবং ফোকাস লিসেনারদের কাছে ফোকাস হারানোর বার্তা পাঠানো হবে। অস্থায়ীভাবে ফোকাস হারানোর ক্ষেত্রে, এন্ট্রিটি ফোকাস হারানো এন্ট্রির স্ট্যাকে থেকে যাবে, কিন্তু এর ব্লকারের তালিকায় একটি নতুন ফোকাস ব্লকার যুক্ত হবে। এক্ষেত্রে কোনো ফোকাস হারানোর বার্তা পাঠানো হবে না, কারণ প্রথমবার ব্লক হওয়ার সময় একটি বার্তা পাঠানো হয়েছিল। যখন বর্তমান সব ব্লকার সরিয়ে দেওয়া হবে, তখন অনুরোধটি অবশেষে আনব্লক হবে, অথবা ফোকাস পরিত্যক্ত হলে এটি স্ট্যাক থেকে সরিয়ে দেওয়া হবে।
দ্বিতীয় এপিআই, notifyAudioFocusChange , একটি একমুখী এপিআই যা প্রতিটি অডিও ফোকাস অনুরোধ বা পরিত্যাগের ক্ষেত্রে কল করা হয়। এই এপিআইটি মূলত ফোকাস পরিবর্তন সম্পর্কে OEM সার্ভিসকে জানানোর জন্য ব্যবহৃত হয়, যা OEM কার অডিও সার্ভিসের আচরণকে প্রভাবিত করতে পারে।
ফোকাস মূল্যায়নের জন্য নির্দেশিকা
AAOS-এ, অডিও প্লেব্যাক পরিচালনা করতে এবং ব্যবহারকারীকে সর্বোত্তম অভিজ্ঞতা প্রদানের জন্য কোন অ্যাপটি তা মেনে চলবে তা নির্ধারণ করতে অডিও ফোকাস ব্যবহার করা হয়। সেই হিসেবে, একটি অডিও ফোকাস অনুরোধ পরিচালনা করার সময় OEM প্লাগইন পরিষেবাটির নিম্নলিখিত বিষয়গুলি বিবেচনা করা উচিত:
কোনো স্থায়ী উচ্চ অগ্রাধিকারের অডিও ফোকাস (যেমন ফোন কল, জরুরি অবস্থা বা নিরাপত্তা) না থাকলেও, অ্যাপগুলো ক্ষণস্থায়ীভাবে বা স্থায়ীভাবে অডিও ফোকাস অর্জন করতে সক্ষম হওয়া উচিত।
গণমাধ্যমের মনোযোগ সক্রিয় থাকাকালীন, অ্যাপগুলো অনুরোধ করছে:
কল ব্যবহারের ফোকাস, যা একই সাথে অথবা একচেটিয়াভাবে ফোকাস গ্রহণ করতে সক্ষম হওয়া উচিত।
নেভিগেশন ব্যবহারের ফোকাস, একই সাথে অথবা একচেটিয়াভাবে ফোকাস গ্রহণ করতে সক্ষম হওয়া উচিত।
অ্যাসিস্ট্যান্ট ব্যবহারের ফোকাস, একই সাথে অথবা স্বতন্ত্রভাবে ফোকাস গ্রহণ করতে সক্ষম হওয়া উচিত।
যখন উচ্চ অগ্রাধিকারের অডিও ফোকাস (যেমন ফোন কল, জরুরি সতর্কতা বা নিরাপত্তা সতর্কতা) অ্যাপগুলো সক্রিয় থাকে, তখন আগত যেকোনো বিলম্বিত অডিও ফোকাসের অনুরোধ প্রয়োজন অনুযায়ী মঞ্জুর বা বিলম্বিত করা উচিত।
যদিও উপরের পরামর্শগুলোই সব নয়, তবুও এগুলো এটা নিশ্চিত করতে সাহায্য করতে পারে যে, যখন কোনো সক্রিয় উচ্চ অগ্রাধিকারের সাউন্ড থাকবে না, তখনও ফোকাসের জন্য অনুরোধকারী অ্যাপগুলো যেন ফোকাস পেতে পারে। এমনকি উচ্চ অগ্রাধিকারের সাউন্ড সক্রিয় থাকা অবস্থাতেও, বিলম্বিত ফোকাসের অনুরোধগুলোকে সম্মান করা উচিত এবং সাউন্ডটি বন্ধ হয়ে গেলে সেগুলোর ফোকাস পাওয়ার সক্ষমতা থাকা উচিত।
OEM গাড়ির ভলিউম পরিষেবা
গাড়ির অডিও সার্ভিসটি অডিও সিস্টেম থেকে ভলিউম অ্যাডজাস্টমেন্ট শুনে অথবা সরাসরি গাড়ির ইনপুট সার্ভিস থেকে ভলিউম কী ইভেন্ট শুনে ভলিউম কী ইভেন্টগুলো পরিচালনা করে। উভয় ক্ষেত্রেই, গাড়ির অডিও সার্ভিসের ডিফল্ট আচরণ হলো সক্রিয় অডিও প্লেয়ার এবং একটি অডিও কনটেক্সট প্রায়োরিটি লিস্টের উপর ভিত্তি করে কোন ভলিউম গ্রুপটি পরিবর্তন করতে হবে তা নির্ধারণ করা।
আমরা দুটি ভলিউম অগ্রাধিকার তালিকা প্রদান করি। প্রথম তালিকাটি সমস্ত অডিও কনটেক্সটকে এই ক্রমে বিবেচনা করে। তালিকাটি অবরোহী ক্রমে উপস্থাপন করা হয়, সর্বোচ্চ অগ্রাধিকার শীর্ষে এবং সর্বনিম্ন অগ্রাধিকার নীচে থাকে। উদাহরণস্বরূপ, যদি নেভিগেশন অডিও এবং মিউজিক অডিও উভয়ই একই সময়ে সক্রিয় থাকে, তাহলে একটি ভলিউম কী ইভেন্টের সময় নেভিগেশন ভলিউম পরিবর্তন করা হয়।
- নেভিগেশন
- কল করুন
- সঙ্গীত
- ঘোষণা
- ভয়েস কমান্ড
- কল রিং
- সিস্টেম সাউন্ড
- নিরাপত্তা
- অ্যালার্ম
- বিজ্ঞপ্তি
- গাড়ির অবস্থা
- জরুরি অবস্থা
ভলিউম কী ইভেন্ট ম্যানেজমেন্টকে কম জটিল করার জন্য, কার অডিও সার্ভিসের একটি দ্বিতীয় অগ্রাধিকার তালিকা রয়েছে, যা অডিও কনটেক্সটকে নির্দেশ করে:
- কল করুন
- মিডিয়া
- ঘোষণা
- ভয়েস কমান্ড
এই তালিকাটিও অবরোহী ক্রমে সাজানো আছে। এই দ্বিতীয় তালিকার উদ্দেশ্য হলো কী ইভেন্টের মাধ্যমে সাধারণ সাউন্ডগুলো পরিবর্তন করার সুযোগ দেওয়া। অস্বাভাবিক, বা সম্ভবত স্বল্পস্থায়ী সাউন্ডগুলো শুধুমাত্র অডিও সেটিংস UI-এর মাধ্যমেই নিয়ন্ত্রণ করা যায়।
audioVolumeAdjustmentContextsVersion কনফিগারেশনের মাধ্যমে ভলিউমের প্রকৃত ভার্সন সেট করা যায়। এই কনফিগারেশনটি 1 অথবা 2 এ সেট করা যেতে পারে (ডিফল্ট হলো 2 )।
ভলিউম ব্যবস্থাপনায় আরও নমনীয়তা আনতে অ্যান্ড্রয়েড ১৪-এ OemCarAudioVolumeService চালু করা হয়েছে:
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 হলো বর্তমানে ডাকড থাকা সমস্ত অডিও অ্যাট্রিবিউট। volumeGroupState এ ভলিউম গ্রুপের বর্তমান অবস্থা থাকে। অনুরোধটি অডিও স্ট্যাকের বর্তমান অবস্থা উপস্থাপন করে এবং কোন ভলিউম গ্রুপ পরিবর্তন করা উচিত তা নির্ধারণ করতে এটি ব্যবহার করা যেতে পারে। ফলাফলগুলো OemCarVolumeChangeInfo তে ফেরত দেওয়া উচিত।
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
` change বুলিয়ানটি নির্দেশ করে যে কোনো ভলিউম পরিবর্তিত হয়েছে কিনা; true মানে হলো একটি পরিবর্তন হয়েছে এবং ভলিউম গ্রুপটি আপডেট করা উচিত। ` volumeGroupChanged হলো সেই প্রকৃত ভলিউম গ্রুপ যা পরিবর্তন করা উচিত। এপিআই-তে পাঠানো মূল volumeAdjustment প্যারামিটার অনুযায়ী এই গ্রুপটি পরিবর্তন করা উচিত। উদাহরণস্বরূপ, যদি ফলাফল থেকে বোঝা যায় যে নেভিগেশন ভলিউম গ্রুপটি মিউট করা উচিত, তাহলে বুলিয়ানটির মান true হবে এবং ফেরত আসা ভলিউম গ্রুপটি হবে নেভিগেশনের জন্য নির্ধারিত গ্রুপটি।
OEM গাড়ি ডাকিং পরিষেবা
গাড়ির অডিও পরিষেবা অডিও ফোকাসের পরিবর্তন পর্যবেক্ষণ করে এবং কোন অডিও ডিভাইসগুলোকে ডাক করতে হবে সে সম্পর্কে AudioControl HAL-এ একটি সংকেত পাঠিয়ে অডিও ডাকিং পরিচালনা করে। যখন ফোকাস পরিবর্তিত হয়, তখন এই নির্দিষ্ট ডাকিং নিয়মাবলীর উপর ভিত্তি করে কোন ডিভাইসগুলোকে ডাক করা উচিত তা নির্ধারণ করার জন্য সমস্ত সক্রিয় ফোকাস হোল্ডারদের মূল্যায়ন করা হয়।
- জরুরি অবস্থার শব্দ: ডাকের শব্দ ছাড়া বাকি সব শব্দ এড়িয়ে যান।
- নিরাপত্তাজনিত শব্দ ছাড়া বাকি সবকিছু ঢেকে রাখে।
- নিরাপত্তা ও জরুরি শব্দ ছাড়া নেভিগেশন বাকি সবকিছু এড়িয়ে যায়।
- নিরাপত্তা, জরুরি অবস্থা এবং দিকনির্দেশনার শব্দ ছাড়া হাঁসদের বাকি সব শব্দ ডাকতে বলুন।
- হাঁসের ডাকের রিং সাউন্ড
- সঙ্গীত এবং ঘোষণা সবকিছু থেকে আড়াল করা উচিত।
এই নিয়মগুলিই চূড়ান্ত নয় এবং এই নির্দেশিকাগুলির উপর ভিত্তি করে শব্দ কীভাবে কমানো হবে তা নির্ধারণের দায়িত্ব OEM-দেরই থাকে। উপলব্ধ প্রয়োজনীয়তার উপর ভিত্তি করে OEM-রা এই সুপারিশগুলিকে আরও সক্রিয়ভাবে নিয়ন্ত্রণ করতে পারে। Android 14-এ OemCarDuckingService চালু করা হয়েছে:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
অডিও ফোকাস পরিবর্তনের সময় কার অডিও সার্ভিস থেকে এই এপিআই-টি কল করা হয়। এটি OEM কার ভলিউম সার্ভিসে প্রবর্তিত OemCarAudioVolumeRequest কে পুনরায় ব্যবহার করে এবং কোন অ্যাট্রিবিউটগুলোকে ডাক করতে হবে সেই সিদ্ধান্ত নেওয়ার জন্য প্রাসঙ্গিক তথ্য ধারণ করে। এপিআই থেকে ডাক করার জন্য অডিও অ্যাট্রিবিউটের তালিকাটি বর্তমান অডিও স্টেটের সাথে তুলনা করা হয়:
অডিও অ্যাট্রিবিউট বর্তমানে ডাউনগ্রেড করা আছে:
- তালিকায় থাকা সত্ত্বেও, এড়িয়ে যাওয়া অব্যাহত রয়েছে।
- তালিকায় নেই, হাঁস বন্ধ করা হয়েছে
অডিও অ্যাট্রিবিউট বর্তমানে ডাকড নয়:
- তালিকায়, মাথা নিচু করে
- তালিকায় নেই, হাঁস বন্ধ করা হয়েছে
এরপর কার অডিও সার্ভিসটি নির্ধারণ করে যে অডিও অ্যাট্রিবিউটগুলো কোন অডিও আউটপুট ডিভাইসের অন্তর্গত এবং সেগুলোকে যথাক্রমে ডাকড অডিও আউটপুট ডিভাইস লিস্ট বা আনডাকড অডিও ডিভাইস লিস্টে যুক্ত করে। সবশেষে, হার্ডওয়্যার লেভেলে প্রয়োজনীয় ডাকিং সম্পন্ন করার জন্য এটি AudioControl HAL- এ পাঠানো হয়।
নিচের চিত্রে, OEM ডাকিং পরিষেবা ব্যবহার করার সময় একটি ফোকাস অনুরোধের জন্য অডিও ডাকিং নিয়ন্ত্রণের একটি সরলীকৃত সিকোয়েন্স ডায়াগ্রাম দেখানো হয়েছে:
যখন কোনো অ্যাপ পাবলিক অডিও ম্যানেজার এপিআই-এর মাধ্যমে 'ম্যানেজ অডিও ফোকাস'-এর জন্য অনুরোধ করে, তখন এই প্রক্রিয়াটি শুরু হয়। ফলাফল নির্ধারণের জন্য অনুরোধটি কার অডিও সার্ভিসে পাঠানো হয়। অডিও ফোকাস নির্ধারিত হয়ে গেলে, কোন কোন অডিও অ্যাট্রিবিউট ডাকিং করা উচিত তা মূল্যায়ন করার জন্য কার অডিও সার্ভিসটি OemCarAudioDuckingService কল করে অডিও ডাকিং-এর বিষয়টি মূল্যায়ন করে। evaluateAttributesToDuck এপিআই থেকে ফলাফল ফিরে আসার পর, কোন কোন অডিও ডিভাইস ডাকিং করা হবে তা গণনা করা হয় এবং সবশেষে অডিও হার্ডওয়্যারে ডাকিং প্রয়োগ করার জন্য তথ্যটি AudioControl এ পাঠানো হয়।
OEM গাড়ির অডিও পরিষেবা রেফারেন্স বাস্তবায়ন
AAOS packages/services/Car/tests/OemCarServiceTestApp এ OEM কার সার্ভিসের একটি রেফারেন্স ইমপ্লিমেন্টেশন প্রদান করে, যা 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 কার সার্ভিসটি যাচাই করতে, OEM সার্ভিসের জন্য 'car service dump কমান্ডটি ব্যবহার করুন:
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 তথ্যের প্রতিটি ব্যাচের প্রতিটি বুলিয়ান কোনো ফিচার এবং সার্ভিসের অবস্থা নির্ধারণ করে। উদাহরণস্বরূপ, mIsOemServiceReady ডাম্প তথ্যটি নির্দিষ্ট করে যে সার্ভিসটি ব্যবহারের জন্য প্রস্তুত কিনা, যেখানে true মানে এটি প্রস্তুত এবং false মানে এটি প্রস্তুত নয়।