রিভিশন ঘ
সর্বশেষ আপডেট: জানুয়ারি 12, 2015

কপিরাইট © 2015, Google Inc. সর্বস্বত্ব সংরক্ষিত৷
compatibility@android.com

সুচিপত্র

1। পরিচিতি

ডিভাইসগুলিকে Android 5.0 এর সাথে সামঞ্জস্যপূর্ণ হওয়ার জন্য এই নথিতে প্রয়োজনীয় প্রয়োজনীয়তাগুলিকে গণনা করা উচিত৷

"অবশ্যই", "অবশ্যই নয়", "প্রয়োজনীয়", "শালা", "শালা নয়", "উচিত", "উচিত নয়", "প্রস্তাবিত", "মেয়ে" এবং "ঐচ্ছিক" এর ব্যবহার IETF মান অনুযায়ী RFC2119 [ সম্পদ, 1 ] এ সংজ্ঞায়িত।

এই নথিতে যেমন ব্যবহার করা হয়েছে, একজন "ডিভাইস ইমপ্লিমেন্টার" বা "বাস্তবায়নকারী" হল একজন ব্যক্তি বা সংস্থা যা Android 5.0 চালিত একটি হার্ডওয়্যার/সফ্টওয়্যার সমাধান তৈরি করে। একটি "ডিভাইস বাস্তবায়ন" বা "বাস্তবায়ন" হল হার্ডওয়্যার/সফ্টওয়্যার সমাধান তাই উন্নত।

অ্যান্ড্রয়েড 5.0 এর সাথে সামঞ্জস্যপূর্ণ বলে বিবেচিত হতে, ডিভাইস বাস্তবায়নকে অবশ্যই এই সামঞ্জস্যতার সংজ্ঞায় উপস্থাপিত প্রয়োজনীয়তাগুলি পূরণ করতে হবে, রেফারেন্সের মাধ্যমে অন্তর্ভুক্ত করা যেকোনো নথি সহ।

যেখানে এই সংজ্ঞা বা বিভাগ 10- এ বর্ণিত সফ্টওয়্যার পরীক্ষাগুলি নীরব, অস্পষ্ট বা অসম্পূর্ণ, সেখানে বিদ্যমান বাস্তবায়নের সাথে সামঞ্জস্যতা নিশ্চিত করা ডিভাইস বাস্তবায়নকারীর দায়িত্ব৷

এই কারণে, অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্প [ সম্পদ, 2 ] হল অ্যান্ড্রয়েডের রেফারেন্স এবং পছন্দসই বাস্তবায়ন। ডিভাইস ইমপ্লিমেন্টারদের জোরালোভাবে উত্সাহিত করা হয় যে তারা Android ওপেন সোর্স প্রজেক্ট থেকে উপলব্ধ "আপস্ট্রিম" সোর্স কোডের উপর তাদের বাস্তবায়নকে সর্বাধিক পরিমাণে ভিত্তি করে। যদিও কিছু উপাদান অনুমানমূলকভাবে বিকল্প বাস্তবায়নের সাথে প্রতিস্থাপিত হতে পারে এই অনুশীলনটি দৃঢ়ভাবে নিরুৎসাহিত করা হয়, কারণ সফ্টওয়্যার পরীক্ষায় উত্তীর্ণ হওয়া যথেষ্ট কঠিন হয়ে উঠবে। সামঞ্জস্য পরীক্ষা স্যুট সহ এবং এর বাইরেও আদর্শ Android বাস্তবায়নের সাথে সম্পূর্ণ আচরণগত সামঞ্জস্য নিশ্চিত করা বাস্তবায়নকারীর দায়িত্ব। পরিশেষে, মনে রাখবেন যে কিছু উপাদান প্রতিস্থাপন এবং পরিবর্তনগুলি এই নথি দ্বারা স্পষ্টভাবে নিষিদ্ধ।

অধ্যায় 14- এ তালিকাভুক্ত অনেক সংস্থানই প্রত্যক্ষ বা পরোক্ষভাবে Android SDK থেকে প্রাপ্ত, এবং সেই SDK-এর ডকুমেন্টেশনের তথ্যের সাথে কার্যকরীভাবে অভিন্ন হবে৷ যে কোনও ক্ষেত্রে যেখানে এই সামঞ্জস্যতার সংজ্ঞা বা সামঞ্জস্য পরীক্ষা স্যুট SDK ডকুমেন্টেশনের সাথে একমত নয়, SDK ডকুমেন্টেশনকে প্রামাণিক হিসাবে বিবেচনা করা হয়। ধারা 14- এ অন্তর্ভুক্ত রেফারেন্সে প্রদত্ত যেকোন প্রযুক্তিগত বিশদ এই সামঞ্জস্যতার সংজ্ঞার অংশ হিসাবে অন্তর্ভুক্ত করার দ্বারা বিবেচনা করা হয়।

2. ডিভাইসের ধরন

যদিও অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টটি বিভিন্ন ধরনের ডিভাইস এবং ফর্ম ফ্যাক্টর বাস্তবায়নে ব্যবহার করা হয়েছে, আর্কিটেকচারের অনেক দিক এবং সামঞ্জস্যের প্রয়োজনীয়তা হ্যান্ডহেল্ড ডিভাইসগুলির জন্য অপ্টিমাইজ করা হয়েছে। অ্যান্ড্রয়েড 5.0 থেকে শুরু করে, অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্টের লক্ষ্য এই বিভাগে বর্ণিত বিভিন্ন ধরনের ডিভাইসের বিস্তৃত প্রকারকে আলিঙ্গন করা।

অ্যান্ড্রয়েড হ্যান্ডহেল্ড ডিভাইস একটি অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নকে বোঝায় যা সাধারণত এটিকে হাতে ধরে রাখার দ্বারা ব্যবহৃত হয়, যেমন mp3 প্লেয়ার, ফোন এবং ট্যাবলেট। অ্যান্ড্রয়েড হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন:

• ডিভাইসে একটি টাচস্ক্রিন এমবেড করা আবশ্যক
• একটি শক্তির উৎস থাকতে হবে যা গতিশীলতা প্রদান করে, যেমন একটি ব্যাটারি

অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বলতে একটি অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নকে বোঝায় যা ডিজিটাল মিডিয়া, সিনেমা, গেমস, অ্যাপস এবং/অথবা লাইভ টিভি ব্যবহার করার জন্য একটি বিনোদন ইন্টারফেস যা প্রায় দশ ফুট দূরে বসে থাকা ব্যবহারকারীদের জন্য (একটি "ফিরে ঝুঁকে" বা "10-ফুট ইউজার ইন্টারফেস) ”)। অ্যান্ড্রয়েড টেলিভিশন ডিভাইস:

• একটি এমবেডেড স্ক্রিন থাকতে হবে বা একটি ভিডিও আউটপুট পোর্ট অন্তর্ভুক্ত করতে হবে, যেমন VGA, HDMI, বা প্রদর্শনের জন্য একটি বেতার পোর্ট
• android.software.leanback এবং android.hardware.type.television বৈশিষ্ট্যগুলি ঘোষণা করতে হবে [ সম্পদ, 3 ]

অ্যান্ড্রয়েড ওয়াচ ডিভাইসটি একটি অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নকে বোঝায় যা শরীরে, সম্ভবত কব্জিতে পরা হবে এবং:

• 1.1 থেকে 2.5 ইঞ্চি পরিসরে ভৌত তির্যক দৈর্ঘ্য সহ একটি পর্দা থাকা আবশ্যক
• android.hardware.type.watch বৈশিষ্ট্যটি অবশ্যই ঘোষণা করতে হবে
• uiMode = UI_MODE_TYPE_WATCH সমর্থন করা আবশ্যক [ সম্পদ, 4 ]

সমস্ত অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন যা উপরের যেকোনও ধরনের ডিভাইসের সাথে খাপ খায় না, এখনও এই নথিতে থাকা সমস্ত প্রয়োজনীয়তা অবশ্যই অবশ্যই পূরণ করতে হবে Android 5.0 সামঞ্জস্যপূর্ণ হতে, যদি না প্রয়োজনটি শুধুমাত্র একটি নির্দিষ্ট Android ডিভাইসের জন্য প্রযোজ্য বলে স্পষ্টভাবে বর্ণনা করা হয়।

2.1 ডিভাইস কনফিগারেশন

এটি ডিভাইসের ধরন অনুসারে হার্ডওয়্যার কনফিগারেশনের প্রধান পার্থক্যগুলির একটি সারাংশ। (খালি কক্ষ একটি "MAY" নির্দেশ করে)। সমস্ত কনফিগারেশন এই টেবিলে কভার করা হয় না; আরো বিস্তারিত জানার জন্য প্রাসঙ্গিক হার্ডওয়্যার বিভাগ দেখুন.

3. সফটওয়্যার

3.1। পরিচালিত API সামঞ্জস্য

পরিচালিত ডালভিক বাইটকোড এক্সিকিউশন এনভায়রনমেন্ট হল অ্যান্ড্রয়েড অ্যাপ্লিকেশনের জন্য প্রাথমিক বাহন। অ্যান্ড্রয়েড অ্যাপ্লিকেশন প্রোগ্রামিং ইন্টারফেস (API) হল অ্যান্ড্রয়েড প্ল্যাটফর্ম ইন্টারফেসের একটি সেট যা পরিচালিত রানটাইম পরিবেশে চলমান অ্যাপ্লিকেশনগুলির জন্য উন্মুক্ত। ডিভাইস বাস্তবায়ন অবশ্যই Android SDK [ রিসোর্সেস, 5 ] বা আপস্ট্রিম অ্যান্ড্রয়েড সোর্স কোডে "@SystemApi" মার্কার দিয়ে সজ্জিত যেকোন এপিআই দ্বারা প্রকাশ করা যেকোন নথিভুক্ত API-এর সমস্ত নথিভুক্ত আচরণ সহ সম্পূর্ণ বাস্তবায়ন প্রদান করতে হবে।

এই সামঞ্জস্যতা সংজ্ঞা দ্বারা বিশেষভাবে অনুমোদিত স্থান ব্যতীত ডিভাইস বাস্তবায়নে কোনো পরিচালিত API বাদ দেওয়া, API ইন্টারফেস বা স্বাক্ষর পরিবর্তন করা, নথিভুক্ত আচরণ থেকে বিচ্যুত হওয়া, বা নো-অপস অন্তর্ভুক্ত করা উচিত নয়।

এই সামঞ্জস্যতার সংজ্ঞাটি এমন কিছু হার্ডওয়্যারের অনুমতি দেয় যার জন্য Android এ API গুলিকে ডিভাইস বাস্তবায়ন দ্বারা বাদ দেওয়া হয়। এই ধরনের ক্ষেত্রে, APIগুলি অবশ্যই উপস্থিত থাকতে হবে এবং যুক্তিসঙ্গতভাবে আচরণ করতে হবে। এই দৃশ্যের জন্য নির্দিষ্ট প্রয়োজনীয়তার জন্য বিভাগ 7 দেখুন।

3.2। সফট এপিআই সামঞ্জস্য

বিভাগ 3.1 থেকে পরিচালিত API গুলি ছাড়াও, Android-এ একটি উল্লেখযোগ্য রানটাইম-শুধুমাত্র "সফ্ট" API অন্তর্ভুক্ত রয়েছে, যেমন উদ্দেশ্য, অনুমতি এবং Android অ্যাপ্লিকেশনগুলির অনুরূপ দিকগুলির আকারে যা অ্যাপ্লিকেশন কম্পাইলের সময় প্রয়োগ করা যায় না।

3.2.1। অনুমতি

ডিভাইস বাস্তবায়নকারীদের অবশ্যই অনুমতি রেফারেন্স পৃষ্ঠা দ্বারা নথিভুক্ত সমস্ত অনুমতি ধ্রুবক সমর্থন এবং প্রয়োগ করতে হবে [ সম্পদ, 6] । মনে রাখবেন যে বিভাগ 9 এ অ্যান্ড্রয়েড নিরাপত্তা মডেল সম্পর্কিত অতিরিক্ত প্রয়োজনীয়তা তালিকাভুক্ত করা হয়েছে।

3.2.2। প্যারামিটার তৈরি করুন

অ্যান্ড্রয়েড এপিআই-এ android.os.Build ক্লাস [ রিসোর্সেস, 7 ]-এ বেশ কয়েকটি ধ্রুবক অন্তর্ভুক্ত রয়েছে যা বর্তমান ডিভাইস বর্ণনা করার উদ্দেশ্যে। ডিভাইস বাস্তবায়ন জুড়ে সামঞ্জস্যপূর্ণ, অর্থপূর্ণ মান প্রদান করার জন্য, নীচের সারণীতে এই মানগুলির ফর্ম্যাটগুলির উপর অতিরিক্ত বিধিনিষেধ অন্তর্ভুক্ত করা হয়েছে যা ডিভাইস বাস্তবায়নকে অবশ্যই মেনে চলতে হবে।

3.2.3। অভিপ্রায় সামঞ্জস্য

ডিভাইস বাস্তবায়ন অবশ্যই Android এর লুজ-কাপলিং ইন্টেন্ট সিস্টেমকে সম্মান করবে, যেমনটি নীচের বিভাগে বর্ণিত হয়েছে। "সম্মানিত" দ্বারা বোঝানো হয়েছে যে ডিভাইস বাস্তবায়নকারীকে অবশ্যই একটি Android কার্যকলাপ বা পরিষেবা প্রদান করতে হবে যা একটি মিলিত অভিপ্রায় ফিল্টার নির্দিষ্ট করে যা প্রতিটি নির্দিষ্ট অভিপ্রায় প্যাটার্নের জন্য সঠিক আচরণের সাথে আবদ্ধ এবং প্রয়োগ করে৷

3.2.3.1। মূল আবেদন উদ্দেশ্য

অ্যান্ড্রয়েড ইন্টেন্টগুলি অ্যাপ্লিকেশন উপাদানগুলিকে অন্যান্য অ্যান্ড্রয়েড উপাদানগুলির থেকে কার্যকারিতার অনুরোধ করার অনুমতি দেয়৷ অ্যান্ড্রয়েড আপস্ট্রিম প্রকল্পে মূল অ্যান্ড্রয়েড অ্যাপ্লিকেশন হিসাবে বিবেচিত অ্যাপ্লিকেশনগুলির একটি তালিকা অন্তর্ভুক্ত রয়েছে, যা সাধারণ ক্রিয়া সম্পাদনের জন্য বেশ কয়েকটি অভিপ্রায় প্যাটার্ন প্রয়োগ করে। মূল অ্যান্ড্রয়েড অ্যাপ্লিকেশন হল:

• ডেস্ক ঘড়ি
• ব্রাউজার
• ক্যালেন্ডার
• পরিচিতি
• গ্যালারি
• গ্লোবাল সার্চ
• লঞ্চার
• সঙ্গীত
• সেটিংস

ডিভাইস বাস্তবায়নে মূল অ্যান্ড্রয়েড অ্যাপ্লিকেশানগুলিকে উপযুক্ত হিসাবে অন্তর্ভুক্ত করা উচিত তবে এই মূল অ্যান্ড্রয়েড অ্যাপ্লিকেশনগুলির সমস্ত "পাবলিক" অ্যাক্টিভিটি বা পরিষেবা উপাদানগুলির দ্বারা সংজ্ঞায়িত একই অভিপ্রায়ের প্যাটার্নগুলি প্রয়োগ করে এমন একটি উপাদান অবশ্যই অন্তর্ভুক্ত করা উচিত৷ মনে রাখবেন যে অ্যাট্রিবিউট android:exported অনুপস্থিত বা মান সত্য হলে কার্যকলাপ বা পরিষেবা উপাদানগুলিকে "সর্বজনীন" হিসাবে বিবেচনা করা হয়৷

3.2.3.2। অভিপ্রায় ওভাররাইড করে

যেহেতু অ্যান্ড্রয়েড একটি এক্সটেনসিবল প্ল্যাটফর্ম, তাই ডিভাইস বাস্তবায়ন অবশ্যই 3.2.3.1 বিভাগে উল্লেখ করা প্রতিটি ইন্টেন্ট প্যাটার্নকে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে ওভাররাইড করার অনুমতি দিতে হবে। আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স বাস্তবায়ন ডিফল্টরূপে এটির অনুমতি দেয়; ডিভাইস বাস্তবায়নকারীরা অবশ্যই সিস্টেম অ্যাপ্লিকেশনগুলির এই উদ্দেশ্য প্যাটার্নগুলির ব্যবহারে বিশেষ সুবিধাগুলি সংযুক্ত করবেন না, বা তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে এই প্যাটার্নগুলির সাথে আবদ্ধ হওয়া এবং নিয়ন্ত্রণ করা থেকে বাধা দেবেন না। এই নিষেধাজ্ঞার মধ্যে বিশেষভাবে অন্তর্ভুক্ত রয়েছে কিন্তু "নির্বাচক" ব্যবহারকারী ইন্টারফেস নিষ্ক্রিয় করার মধ্যেই সীমাবদ্ধ নয় যা ব্যবহারকারীকে একাধিক অ্যাপ্লিকেশনের মধ্যে নির্বাচন করতে দেয় যেগুলি একই অভিপ্রায় প্যাটার্ন পরিচালনা করে।

যাইহোক, ডিভাইস বাস্তবায়ন নির্দিষ্ট URI প্যাটার্নের জন্য ডিফল্ট কার্যকলাপ প্রদান করতে পারে (যেমন। http://play.google.com) যদি ডিফল্ট কার্যকলাপ ডেটা URI-এর জন্য আরও নির্দিষ্ট ফিল্টার প্রদান করে। উদাহরণস্বরূপ, ডেটা URI "http://www.android.com" নির্দিষ্ট করে একটি অভিপ্রায় ফিল্টার "http://" এর জন্য ব্রাউজার ফিল্টার থেকে আরও নির্দিষ্ট। ইন্টেন্টের জন্য ডিফল্ট ক্রিয়াকলাপ সংশোধন করার জন্য ডিভাইস বাস্তবায়ন ব্যবহারকারীদের জন্য একটি ব্যবহারকারী ইন্টারফেস প্রদান করতে হবে।

3.2.3.3। অভিপ্রায় নামস্থান

ডিভাইস বাস্তবায়নে এমন কোনো অ্যান্ড্রয়েড উপাদান অন্তর্ভুক্ত করা উচিত নয় যা কোনো নতুন অভিপ্রায় বা সম্প্রচারের অভিপ্রায়ের প্যাটার্নগুলিকে অ্যানড্রয়েড।* বা com.android.* নামস্থানে একটি ACTION, CATEGORY বা অন্যান্য কী স্ট্রিং ব্যবহার করে সম্মান করে। ডিভাইস ইমপ্লিমেন্টারদের এমন কোনো অ্যান্ড্রয়েড উপাদান অন্তর্ভুক্ত করা উচিত নয় যা অন্য সংস্থার অন্তর্গত প্যাকেজ স্পেসে অ্যাকশন, ক্যাটাগরি বা অন্যান্য কী স্ট্রিং ব্যবহার করে কোনো নতুন অভিপ্রায় বা সম্প্রচারের অভিপ্রায় প্যাটার্নকে সম্মান করে। ডিভাইস বাস্তবায়নকারীরা অবশ্যই 3.2.3.1 বিভাগে তালিকাভুক্ত মূল অ্যাপগুলির দ্বারা ব্যবহৃত কোনো অভিপ্রায় প্যাটার্ন পরিবর্তন বা প্রসারিত করবেন না। ডিভাইস বাস্তবায়নের মধ্যে স্পষ্টভাবে এবং স্পষ্টভাবে তাদের নিজস্ব প্রতিষ্ঠানের সাথে যুক্ত নামস্থান ব্যবহার করে অভিপ্রায় প্যাটার্ন অন্তর্ভুক্ত থাকতে পারে। এই নিষেধাজ্ঞাটি বিভাগ 3.6- এ জাভা ভাষার ক্লাসের জন্য নির্দিষ্ট করা অনুরূপ।

3.2.3.4। সম্প্রচার অভিপ্রায়

থার্ড-পার্টি অ্যাপ্লিকেশনগুলি হার্ডওয়্যার বা সফ্টওয়্যার পরিবেশের পরিবর্তন সম্পর্কে তাদের অবহিত করার জন্য নির্দিষ্ট উদ্দেশ্য সম্প্রচার করার জন্য প্ল্যাটফর্মের উপর নির্ভর করে। অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিভাইসগুলিকে অবশ্যই উপযুক্ত সিস্টেম ইভেন্টগুলির প্রতিক্রিয়া হিসাবে সর্বজনীন সম্প্রচারের অভিপ্রায়গুলি সম্প্রচার করতে হবে৷ সম্প্রচারের অভিপ্রায় SDK ডকুমেন্টেশনে বর্ণনা করা হয়েছে।

3.2.3.5। ডিফল্ট অ্যাপ সেটিংস

অ্যান্ড্রয়েডের মধ্যে এমন সেটিংস রয়েছে যা ব্যবহারকারীদের তাদের ডিফল্ট অ্যাপ্লিকেশন নির্বাচন করার একটি সহজ উপায় প্রদান করে, উদাহরণস্বরূপ হোম স্ক্রীন বা এসএমএস। যেখানে এটি বোধগম্য হয়, ডিভাইস বাস্তবায়নে অবশ্যই একটি অনুরূপ সেটিংস মেনু প্রদান করতে হবে এবং নীচের মত SDK ডকুমেন্টেশনে বর্ণিত অভিপ্রায় ফিল্টার প্যাটার্ন এবং API পদ্ধতিগুলির সাথে সামঞ্জস্যপূর্ণ হতে হবে৷

ডিভাইস বাস্তবায়ন:

• হোম স্ক্রীনের জন্য একটি ডিফল্ট অ্যাপ সেটিংস মেনু দেখানোর android.settings.HOME_SETTINGS অভিপ্রায়কে অবশ্যই সম্মান করতে হবে, যদি ডিভাইস বাস্তবায়ন android.software.home_screen রিপোর্ট করে [ সম্পদ, 10]
• একটি সেটিংস মেনু প্রদান করতে হবে যা android.provider.Telephony.ACTION_CHANGE_DEFAULT কে কল করবে ডিফল্ট এসএমএস অ্যাপ্লিকেশন পরিবর্তন করার জন্য একটি ডায়ালগ দেখানোর উদ্দেশ্যে, যদি ডিভাইস বাস্তবায়ন android.hardware.telephony রিপোর্ট করে [ সম্পদ, 9 ]
• ডিভাইস বাস্তবায়ন android.hardware.nfc.hce রিপোর্ট করলে ট্যাপ এবং পে-এর জন্য একটি ডিফল্ট অ্যাপ সেটিংস মেনু দেখানোর android.settings.NFC_PAYMENT_SETTINGS অভিপ্রায়কে অবশ্যই সম্মান করতে হবে [ সম্পদ, 10]

3.3। নেটিভ API সামঞ্জস্য

3.3.1 অ্যাপ্লিকেশন বাইনারি ইন্টারফেস

পরিচালিত ডালভিক বাইটকোড একটি ELF হিসাবে অ্যাপ্লিকেশন .apk ফাইলে প্রদত্ত নেটিভ কোডে কল করতে পারে। তাই উপযুক্ত ডিভাইস হার্ডওয়্যার আর্কিটেকচারের জন্য সংকলিত ফাইল। যেহেতু নেটিভ কোড অন্তর্নিহিত প্রসেসর প্রযুক্তির উপর অত্যন্ত নির্ভরশীল, তাই Android NDK-তে বেশ কয়েকটি অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABIs) সংজ্ঞায়িত করে। ডিভাইস বাস্তবায়ন অবশ্যই এক বা একাধিক সংজ্ঞায়িত ABI-এর সাথে সামঞ্জস্যপূর্ণ হতে হবে এবং Android NDK-এর সাথে সামঞ্জস্য প্রয়োগ করতে হবে, নিচের মত।

যদি একটি ডিভাইস বাস্তবায়নে একটি Android ABI-এর জন্য সমর্থন অন্তর্ভুক্ত থাকে, তাহলে এটি:

• স্ট্যান্ডার্ড জাভা নেটিভ ইন্টারফেস (JNI) শব্দার্থবিদ্যা ব্যবহার করে নেটিভ কোডে কল করার জন্য পরিচালিত পরিবেশে চলমান কোডের সমর্থন অন্তর্ভুক্ত করতে হবে
• নীচের তালিকায় প্রতিটি প্রয়োজনীয় লাইব্রেরির সাথে উত্স-সামঞ্জস্যপূর্ণ (যেমন শিরোনাম সামঞ্জস্যপূর্ণ) এবং বাইনারি-সামঞ্জস্যপূর্ণ (ABI-এর জন্য) হতে হবে
• কোনো 64-বিট ABI সমর্থিত হলে সমতুল্য 32-বিট ABI সমর্থন করতে হবে
• android.os.Build.SUPPORTED_ABIS, android.os.Build.SUPPORTED_32_BIT_ABIS, এবং android.os.Build.SUPPORTED_64_BIT_ABIT-এর আলাদা আলাদা আলাদা একটি তালিকার মাধ্যমে ডিভাইস দ্বারা সমর্থিত নেটিভ অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI) সঠিকভাবে রিপোর্ট করতে হবে ABI গুলি সর্বাধিক থেকে সর্বনিম্ন পছন্দের অর্ডার দেওয়া হয়েছে৷
• অবশ্যই রিপোর্ট করতে হবে, উপরের প্যারামিটারগুলির মাধ্যমে, শুধুমাত্র সেই ABI গুলি যা Android NDK-এর সর্বশেষ সংস্করণে নথিভুক্ত করা হয়েছে, “NDK প্রোগ্রামার গাইড | ABI ম্যানেজমেন্ট" ডক্স/ ডিরেক্টরিতে
• আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্পে উপলব্ধ সোর্স কোড এবং হেডার ফাইলগুলি ব্যবহার করে তৈরি করা উচিত৷

নিম্নলিখিত নেটিভ কোড API গুলি অবশ্যই নেটিভ কোড অন্তর্ভুক্ত করে এমন অ্যাপগুলির জন্য উপলব্ধ হতে হবে:

• libc (সি লাইব্রেরি)
• libm (গণিত গ্রন্থাগার)
• C++ এর জন্য ন্যূনতম সমর্থন
• JNI ইন্টারফেস
• liblog (Android লগিং)
• libz (Zlib কম্প্রেশন)
• libdl (গতিশীল লিঙ্কার)
• libGLESv1_CM.so (OpenGL ES 1.x)
• libGLESv2.so (OpenGL ES 2.0)
• libGLESv3.so (OpenGL ES 3.x)
• libEGL.so (নেটিভ OpenGL পৃষ্ঠ ব্যবস্থাপনা)
• libjnigraphics.so
• libOpenSLES.so (OpenSL ES 1.0.1 অডিও সমর্থন)
• libOpenMAXAL.so (OpenMAX AL 1.0.1 সমর্থন)
• libandroid.so (নেটিভ অ্যান্ড্রয়েড কার্যকলাপ সমর্থন)
• libmediandk.so (নেটিভ মিডিয়া API সমর্থন)
• OpenGL-এর জন্য সমর্থন, নীচে বর্ণিত হিসাবে

মনে রাখবেন যে Android NDK-এর ভবিষ্যত প্রকাশগুলি অতিরিক্ত ABI-এর জন্য সমর্থন প্রবর্তন করতে পারে। যদি একটি ডিভাইস বাস্তবায়ন একটি বিদ্যমান পূর্বনির্ধারিত ABI-এর সাথে সামঞ্জস্যপূর্ণ না হয়, তবে এটি অবশ্যই কোনো ABI-এর জন্য সমর্থনের প্রতিবেদন করা উচিত নয়।

মনে রাখবেন যে ডিভাইস বাস্তবায়নে অবশ্যই libGLESv3.so অন্তর্ভুক্ত থাকতে হবে এবং এটি libGLESv2.so-তে symlink (সিম্বলিক লিঙ্ক) আবশ্যক। পরিবর্তে, সমস্ত OpenGL ES 3.1 এবং Android Extension Pack [ Resources, 11 ] ফাংশন চিহ্নগুলি অবশ্যই রপ্তানি করতে হবে যা NDK রিলিজ android-21-এ সংজ্ঞায়িত করা হয়েছে৷ যদিও সমস্ত চিহ্ন অবশ্যই উপস্থিত থাকতে হবে, শুধুমাত্র OpenGL ES সংস্করণ এবং এক্সটেনশনগুলির জন্য সংশ্লিষ্ট ফাংশনগুলি প্রকৃতপক্ষে ডিভাইস দ্বারা সমর্থিত হতে হবে৷

নেটিভ কোড সামঞ্জস্য চ্যালেঞ্জিং. এই কারণে, আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট থেকে উপরে তালিকাভুক্ত লাইব্রেরিগুলির বাস্তবায়ন ব্যবহার করার জন্য ডিভাইস বাস্তবায়নকারীরা খুব জোরালোভাবে উত্সাহিত হয়৷

3.4। ওয়েব সামঞ্জস্য

3.4.1। ওয়েবভিউ সামঞ্জস্য

প্ল্যাটফর্ম বৈশিষ্ট্য android.software.webview যে কোনো ডিভাইসে রিপোর্ট করা আবশ্যক যেটি android.webkit.WebView API-এর সম্পূর্ণ বাস্তবায়ন প্রদান করে এবং API-এর সম্পূর্ণ বাস্তবায়ন ছাড়া ডিভাইসে রিপোর্ট করা উচিত নয়। Android ওপেন সোর্স বাস্তবায়ন android.webkit.WebView [ সম্পদ, 12 ] বাস্তবায়নের জন্য Chromium প্রকল্পের কোড ব্যবহার করে। যেহেতু একটি ওয়েব রেন্ডারিং সিস্টেমের জন্য একটি বিস্তৃত পরীক্ষা স্যুট তৈরি করা সম্ভব নয়, তাই ডিভাইস বাস্তবায়নকারীদের অবশ্যই WebView বাস্তবায়নে Chromium-এর নির্দিষ্ট আপস্ট্রিম বিল্ড ব্যবহার করতে হবে। বিশেষভাবে:

• ডিভাইস android.webkit.WebView বাস্তবায়ন অবশ্যই Android 5.0 এর জন্য আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট থেকে Chromium বিল্ডের উপর ভিত্তি করে হওয়া উচিত। এই বিল্ডটিতে WebView [ সম্পদ, 13 ] এর জন্য কার্যকারিতা এবং নিরাপত্তা সংশোধনের একটি নির্দিষ্ট সেট অন্তর্ভুক্ত রয়েছে।
• WebView দ্বারা রিপোর্ট করা ব্যবহারকারী এজেন্ট স্ট্রিং এই বিন্যাসে হওয়া আবশ্যক:

Mozilla/5.0 (Linux; Android $(VERSION); $(MODEL) Build/$(BUILD)) AppleWebKit/537.36 (KHTML, Gecko এর মত) সংস্করণ/4.0 $(CHROMIUM_VER) মোবাইল সাফারি/537.36

• $(VERSION) স্ট্রিংয়ের মান অবশ্যই android.os.Build.VERSION.RELEASE-এর মানের সমান হতে হবে।
• $(MODEL) স্ট্রিংটির মান অবশ্যই android.os.Build.MODEL-এর মানের সমান হতে হবে।
• $(BUILD) স্ট্রিংয়ের মান অবশ্যই android.os.Build.ID-এর মানের সমান হতে হবে।
• $(CHROMIUM_VER) স্ট্রিংটির মান অবশ্যই আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্পে ক্রোমিয়ামের সংস্করণ হতে হবে।
• ডিভাইস বাস্তবায়ন ব্যবহারকারী এজেন্ট স্ট্রিং-এ মোবাইল বাদ দিতে পারে।

WebView উপাদানটিতে যতটা সম্ভব HTML5 বৈশিষ্ট্যের জন্য সমর্থন অন্তর্ভুক্ত করা উচিত এবং যদি এটি বৈশিষ্ট্যটিকে সমর্থন করে তাহলে HTML5 স্পেসিফিকেশনের সাথে সঙ্গতিপূর্ণ হওয়া উচিত [ সম্পদ, 14 ]৷

3.4.2। ব্রাউজার সামঞ্জস্য

স্বতন্ত্র ব্রাউজারটি WebKit ছাড়া অন্য কোন ব্রাউজার প্রযুক্তির উপর ভিত্তি করে হতে পারে। যাইহোক, এমনকি যদি একটি বিকল্প ব্রাউজার অ্যাপ্লিকেশন ব্যবহার করা হয়, তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে প্রদত্ত android.webkit.WebView উপাদানটি অবশ্যই WebKit-এর উপর ভিত্তি করে হতে হবে, যেমনটি 3.4.1 বিভাগে বর্ণিত হয়েছে।

বাস্তবায়ন স্বতন্ত্র ব্রাউজার অ্যাপ্লিকেশনে একটি কাস্টম ব্যবহারকারী এজেন্ট স্ট্রিং পাঠাতে পারে।

স্বতন্ত্র ব্রাউজার অ্যাপ্লিকেশন (আপস্ট্রিম ওয়েবকিট ব্রাউজার অ্যাপ্লিকেশন বা তৃতীয় পক্ষের প্রতিস্থাপনের উপর ভিত্তি করে) যতটা সম্ভব HTML5 [ সম্পদ, 14 ] এর জন্য সমর্থন অন্তর্ভুক্ত করা উচিত। ন্যূনতমভাবে, এইচটিএমএল 5 এর সাথে যুক্ত এই APIগুলির প্রতিটিকে ডিভাইস বাস্তবায়নকে সমর্থন করতে হবে:

• অ্যাপ্লিকেশন ক্যাশে/অফলাইন অপারেশন [ সম্পদ, 15 ]
• দ্য
• ভূ-অবস্থান [ সম্পদ, 17 ]

উপরন্তু, ডিভাইস বাস্তবায়ন অবশ্যই HTML5/W3C ওয়েবস্টোরেজ API [ সম্পদ, 18 ] সমর্থন করবে এবং HTML5/W3C IndexedDB API [ সম্পদ, 19 ] সমর্থন করবে। নোট করুন যে ওয়েব ডেভেলপমেন্ট স্ট্যান্ডার্ড সংস্থাগুলি ওয়েবস্টোরেজের উপর IndexedDB-এর পক্ষে রূপান্তরিত হচ্ছে, IndexedDB Android এর ভবিষ্যতের সংস্করণে একটি প্রয়োজনীয় উপাদান হয়ে উঠবে বলে আশা করা হচ্ছে।

3.5। API আচরণগত সামঞ্জস্য

প্রতিটি API প্রকারের আচরণ (পরিচালিত, নরম, নেটিভ এবং ওয়েব) অবশ্যই আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্পের পছন্দের বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণ হতে হবে [ সম্পদ, 2 ]। সামঞ্জস্যের কিছু নির্দিষ্ট ক্ষেত্র হল:

• ডিভাইসগুলি অবশ্যই একটি আদর্শ অভিপ্রায়ের আচরণ বা শব্দার্থ পরিবর্তন করবে না৷
• ডিভাইসগুলি অবশ্যই একটি নির্দিষ্ট ধরণের সিস্টেম উপাদানের জীবনচক্র বা জীবনচক্রের শব্দার্থ পরিবর্তন করবে না (যেমন পরিষেবা, কার্যকলাপ, সামগ্রী সরবরাহকারী, ইত্যাদি)৷
• ডিভাইসগুলি অবশ্যই একটি আদর্শ অনুমতির শব্দার্থ পরিবর্তন করবে না৷

উপরের তালিকাটি ব্যাপক নয়। কম্প্যাটিবিলিটি টেস্ট স্যুট (সিটিএস) আচরণগত সামঞ্জস্যের জন্য প্ল্যাটফর্মের উল্লেখযোগ্য অংশ পরীক্ষা করে, কিন্তু সবগুলো নয়। Android ওপেন সোর্স প্রকল্পের সাথে আচরণগত সামঞ্জস্য নিশ্চিত করা বাস্তবায়নকারীর দায়িত্ব। এই কারণে, ডিভাইস বাস্তবায়নকারীদের সিস্টেমের উল্লেখযোগ্য অংশগুলিকে পুনরায় প্রয়োগ করার পরিবর্তে যেখানে সম্ভব Android ওপেন সোর্স প্রকল্পের মাধ্যমে উপলব্ধ সোর্স কোড ব্যবহার করা উচিত।

3.6। API নামস্থান

অ্যান্ড্রয়েড জাভা প্রোগ্রামিং ভাষা দ্বারা সংজ্ঞায়িত প্যাকেজ এবং ক্লাস নেমস্পেস কনভেনশন অনুসরণ করে। তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলির সাথে সামঞ্জস্য নিশ্চিত করতে, ডিভাইস বাস্তবায়নকারীরা এই প্যাকেজ নেমস্পেসগুলিতে কোনও নিষিদ্ধ পরিবর্তন (নীচে দেখুন) করবেন না:

• java.*
• javax.*
• সূর্য।*
• অ্যান্ড্রয়েড।*
• com.android.*

নিষিদ্ধ পরিবর্তন অন্তর্ভুক্ত :

• ডিভাইস বাস্তবায়নের জন্য অ্যান্ড্রয়েড প্ল্যাটফর্মে সর্বজনীনভাবে প্রকাশ করা APIগুলিকে কোনও পদ্ধতি বা শ্রেণি স্বাক্ষর পরিবর্তন করে, বা ক্লাস বা শ্রেণি ক্ষেত্রগুলি সরিয়ে দিয়ে সংশোধন করা উচিত নয়।
• ডিভাইস বাস্তবায়নকারীরা এপিআই-এর অন্তর্নিহিত বাস্তবায়ন সংশোধন করতে পারে, কিন্তু এই ধরনের পরিবর্তনগুলি প্রকাশ্যে প্রকাশ করা কোনও API-এর বিবৃত আচরণ এবং জাভা-ভাষা স্বাক্ষরকে প্রভাবিত করবে না।
• ডিভাইস ইমপ্লিমেন্টারদের অবশ্যই উপরের API-এ কোনো প্রকাশ্য উপাদান (যেমন ক্লাস বা ইন্টারফেস, বা বিদ্যমান ক্লাস বা ইন্টারফেসে ক্ষেত্র বা পদ্ধতি) যোগ করা উচিত নয়।

একটি "পাবলিকলি এক্সপোজড এলিমেন্ট" হল এমন যেকোন কনস্ট্রাক্ট যা আপস্ট্রিম অ্যান্ড্রয়েড সোর্স কোডে ব্যবহৃত "@hide" মার্কার দিয়ে সাজানো হয় না। অন্য কথায়, ডিভাইস ইমপ্লিমেন্টারদের উচিত নয় নতুন APIs প্রকাশ করা বা উপরে উল্লিখিত নামস্থানে বিদ্যমান API গুলিকে পরিবর্তন করা উচিত নয়। ডিভাইস বাস্তবায়নকারীরা শুধুমাত্র অভ্যন্তরীণ পরিবর্তনগুলি করতে পারে, তবে সেই পরিবর্তনগুলিকে বিজ্ঞাপন দেওয়া বা অন্যথায় বিকাশকারীদের কাছে প্রকাশ করা উচিত নয়৷

ডিভাইস বাস্তবায়নকারীরা কাস্টম এপিআই যোগ করতে পারে, কিন্তু এই ধরনের কোনো এপিআই অবশ্যই অন্য প্রতিষ্ঠানের মালিকানাধীন নামস্থানে থাকা উচিত নয়। উদাহরণ স্বরূপ, ডিভাইস বাস্তবায়নকারীরা অবশ্যই com.google.* বা অনুরূপ নামস্থানে API যোগ করবেন না: শুধুমাত্র Google তা করতে পারে। একইভাবে, Google অন্য কোম্পানির নামস্থানে API যোগ করবে না। অতিরিক্তভাবে, যদি কোনো ডিভাইস বাস্তবায়নে স্ট্যান্ডার্ড অ্যান্ড্রয়েড নেমস্পেসের বাইরে কাস্টম এপিআই অন্তর্ভুক্ত থাকে, তবে সেই APIগুলিকে অবশ্যই একটি অ্যান্ড্রয়েড শেয়ার্ড লাইব্রেরিতে প্যাকেজ করা উচিত যাতে শুধুমাত্র সেই অ্যাপগুলি যা স্পষ্টভাবে ব্যবহার করে (এর মাধ্যমে মেকানিজম) এই ধরনের API-এর বর্ধিত মেমরি ব্যবহার দ্বারা প্রভাবিত হয়।

যদি কোনও ডিভাইস বাস্তবায়নকারী উপরের প্যাকেজ নেমস্পেসগুলির মধ্যে একটিকে উন্নত করার প্রস্তাব দেয় (যেমন একটি বিদ্যমান API-তে দরকারী নতুন কার্যকারিতা যোগ করে, বা একটি নতুন API যোগ করে), বাস্তবায়নকারীকে source.android.com- এ যেতে হবে এবং পরিবর্তনগুলি অবদান রাখার জন্য প্রক্রিয়া শুরু করতে হবে এবং কোড, সেই সাইটের তথ্য অনুযায়ী।

উল্লেখ্য যে উপরের বিধিনিষেধগুলি জাভা প্রোগ্রামিং ভাষায় API-এর নামকরণের জন্য আদর্শ নিয়মের সাথে মিলে যায়; এই বিভাগটি কেবল সেই কনভেনশনগুলিকে শক্তিশালী করা এবং এই সামঞ্জস্যতার সংজ্ঞায় অন্তর্ভুক্তির মাধ্যমে তাদের বাধ্যতামূলক করে তোলার লক্ষ্য রাখে।

3.7। রানটাইম সামঞ্জস্য

ডিভাইস বাস্তবায়ন অবশ্যই সম্পূর্ণ ডালভিক এক্সিকিউটেবল (ডিইএক্স) ফর্ম্যাট এবং ডালভিক বাইটকোড স্পেসিফিকেশন এবং শব্দার্থবিদ্যা [ সম্পদ, 20 ] সমর্থন করে। ডিভাইস বাস্তবায়নকারীদের ART ব্যবহার করা উচিত, ডালভিক এক্সিকিউটেবল ফরম্যাটের রেফারেন্স আপস্ট্রিম বাস্তবায়ন এবং রেফারেন্স বাস্তবায়নের প্যাকেজ ম্যানেজমেন্ট সিস্টেম।

আপস্ট্রিম অ্যান্ড্রয়েড প্ল্যাটফর্ম অনুযায়ী মেমরি বরাদ্দ করার জন্য ডিভাইস বাস্তবায়নের জন্য অবশ্যই ডালভিক রানটাইম কনফিগার করতে হবে, এবং নিম্নলিখিত টেবিলের দ্বারা নির্দিষ্ট করা হয়েছে। (স্ক্রীনের আকার এবং পর্দার ঘনত্বের সংজ্ঞার জন্য বিভাগ 7.1.1 দেখুন।)

মনে রাখবেন যে নীচে নির্দিষ্ট করা মেমরি মানগুলিকে সর্বনিম্ন মান হিসাবে বিবেচনা করা হয় এবং ডিভাইস বাস্তবায়ন অ্যাপ্লিকেশন প্রতি আরও মেমরি বরাদ্দ করতে পারে৷

3.8। ইউজার ইন্টারফেস সামঞ্জস্য

3.8.1। লঞ্চার (হোম স্ক্রীন)

অ্যান্ড্রয়েডে একটি লঞ্চার অ্যাপ্লিকেশন (হোম স্ক্রীন) এবং ডিভাইস লঞ্চার (হোম স্ক্রীন) প্রতিস্থাপনের জন্য তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলির জন্য সমর্থন অন্তর্ভুক্ত রয়েছে। ডিভাইস বাস্তবায়ন যা থার্ড-পার্টি অ্যাপ্লিকেশানগুলিকে ডিভাইসের হোম স্ক্রীন প্রতিস্থাপন করতে দেয় সেগুলিকে অবশ্যই প্ল্যাটফর্ম বৈশিষ্ট্য android.software.home_screen ঘোষণা করতে হবে।

3.8.2। উইজেট

অ্যান্ড্রয়েড একটি উপাদানের ধরন এবং সংশ্লিষ্ট API এবং জীবনচক্র সংজ্ঞায়িত করে যা অ্যাপ্লিকেশনগুলিকে শেষ ব্যবহারকারীর কাছে একটি "AppWidget" প্রকাশ করতে দেয় [ সম্পদ, 21 ] একটি বৈশিষ্ট্য যা হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নে সমর্থিত হওয়ার জন্য দৃঢ়ভাবে সুপারিশ করা হয়। হোম স্ক্রিনে উইজেট এমবেডিং সমর্থন করে এমন ডিভাইস বাস্তবায়নগুলি অবশ্যই নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ করবে এবং প্ল্যাটফর্ম বৈশিষ্ট্য android.software.app_widgets এর জন্য সমর্থন ঘোষণা করবে৷

• ডিভাইস লঞ্চারগুলিতে অবশ্যই অ্যাপউইজেটগুলির জন্য অন্তর্নির্মিত সমর্থন অন্তর্ভুক্ত করতে হবে এবং সরাসরি লঞ্চারের মধ্যে অ্যাপউইজেটগুলি যুক্ত করতে, কনফিগার করতে, দেখতে এবং সরানোর জন্য ব্যবহারকারীর ইন্টারফেস সুবিধাগুলি প্রকাশ করতে হবে৷
• ডিভাইস বাস্তবায়ন অবশ্যই মান গ্রিড আকারে 4 x 4 উইজেট রেন্ডার করতে সক্ষম হবে। বিস্তারিত জানার জন্য অ্যান্ড্রয়েড SDK ডকুমেন্টেশন [ সম্পদ, 21 ] এ অ্যাপ উইজেট ডিজাইন নির্দেশিকা দেখুন।
• লক স্ক্রিনের জন্য সমর্থন অন্তর্ভুক্ত ডিভাইস বাস্তবায়ন লক স্ক্রিনে অ্যাপ্লিকেশন উইজেটগুলিকে সমর্থন করতে পারে৷

3.8.3। বিজ্ঞপ্তি

অ্যান্ড্রয়েড-এ এমন API রয়েছে যা ডেভেলপারদের ডিভাইসের হার্ডওয়্যার এবং সফ্টওয়্যার বৈশিষ্ট্যগুলি ব্যবহার করে উল্লেখযোগ্য ইভেন্টগুলি [ সম্পদ, 22 ] সম্পর্কে ব্যবহারকারীদের অবহিত করতে দেয়।

কিছু এপিআই অ্যাপ্লিকেশনগুলিকে বিজ্ঞপ্তিগুলি সম্পাদন করতে বা হার্ডওয়্যার ব্যবহার করে মনোযোগ আকর্ষণ করার অনুমতি দেয়—বিশেষত শব্দ, কম্পন এবং আলো। ডিভাইস বাস্তবায়ন অবশ্যই SDK ডকুমেন্টেশনে বর্ণিত হার্ডওয়্যার বৈশিষ্ট্যগুলি ব্যবহার করে এবং ডিভাইস বাস্তবায়ন হার্ডওয়্যারের সাথে যতটা সম্ভব বিজ্ঞপ্তি সমর্থন করে। উদাহরণস্বরূপ, যদি একটি ডিভাইস বাস্তবায়নে একটি ভাইব্রেটর অন্তর্ভুক্ত থাকে, তবে এটি অবশ্যই ভাইব্রেশন APIগুলি সঠিকভাবে প্রয়োগ করতে হবে। যদি একটি ডিভাইস বাস্তবায়নে হার্ডওয়্যারের অভাব থাকে, তাহলে সংশ্লিষ্ট APIগুলি অবশ্যই নো-অপস হিসাবে প্রয়োগ করা উচিত। এই আচরণটি অধ্যায় 7 এ আরও বিশদ রয়েছে।

উপরন্তু, এপিআই [ সম্পদ, 23 ], অথবা স্ট্যাটাস/সিস্টেম বার আইকন স্টাইল গাইড [ সম্পদ, 24 ]-এর জন্য প্রদত্ত সমস্ত সংস্থান (আইকন, সাউন্ড ফাইল, ইত্যাদি) বাস্তবায়নের জন্য সঠিকভাবে রেন্ডার করতে হবে। ডিভাইস বাস্তবায়নকারীরা রেফারেন্স অ্যান্ড্রয়েড ওপেন সোর্স বাস্তবায়নের মাধ্যমে প্রদত্ত বিজ্ঞপ্তির জন্য বিকল্প ব্যবহারকারীর অভিজ্ঞতা প্রদান করতে পারে; যাইহোক, এই ধরনের বিকল্প নোটিফিকেশন সিস্টেমগুলি অবশ্যই বিদ্যমান বিজ্ঞপ্তি সংস্থানগুলিকে সমর্থন করে, যেমন উপরে।

Android-এ বিভিন্ন বিজ্ঞপ্তির জন্য সমর্থন রয়েছে, যেমন:

• সমৃদ্ধ বিজ্ঞপ্তি — চলমান বিজ্ঞপ্তিগুলির জন্য ইন্টারেক্টিভ ভিউ।
• হেড-আপ নোটিফিকেশন — ইন্টারেক্টিভ ভিউ ব্যবহারকারীরা বর্তমান অ্যাপটি না রেখেই কাজ করতে বা খারিজ করতে পারে।
• লকস্ক্রিন বিজ্ঞপ্তি — দৃশ্যমানতার উপর দানাদার নিয়ন্ত্রণ সহ একটি লক স্ক্রিনে দেখানো বিজ্ঞপ্তিগুলি৷

ডিভাইস ইমপ্লিমেন্টেশনগুলি অবশ্যই সঠিকভাবে এই বিজ্ঞপ্তিগুলি প্রদর্শন এবং কার্যকর করতে হবে, যার মধ্যে শিরোনাম/নাম, আইকন, টেক্সট যেমন অ্যান্ড্রয়েড এপিআইতে নথিভুক্ত রয়েছে [সম্পদ, 25] ।

অ্যান্ড্রয়েডে নোটিফিকেশন লিসেনার সার্ভিস এপিআই রয়েছে যা অ্যাপগুলিকে (ব্যবহারকারীর দ্বারা একবার স্পষ্টভাবে সক্ষম করা হয়) পোস্ট করা বা আপডেট হওয়ার সাথে সাথে সমস্ত বিজ্ঞপ্তির একটি অনুলিপি পাওয়ার অনুমতি দেয়। ডিভাইস বাস্তবায়ন অবশ্যই সঠিকভাবে এবং অবিলম্বে বিজ্ঞপ্তি অবজেক্টের সাথে সংযুক্ত যেকোনো এবং সমস্ত মেটাডেটা সহ এই ধরনের সমস্ত ইনস্টল করা এবং ব্যবহারকারী-সক্ষম শ্রোতা পরিষেবাগুলিতে সম্পূর্ণরূপে বিজ্ঞপ্তি পাঠাতে হবে।

3.8.4। অনুসন্ধান করুন

অ্যান্ড্রয়েডে রয়েছে APIs [ সম্পদ, 26 ] যা ডেভেলপারদের তাদের অ্যাপ্লিকেশনগুলিতে অনুসন্ধান অন্তর্ভুক্ত করতে এবং তাদের অ্যাপ্লিকেশনের ডেটা বিশ্বব্যাপী সিস্টেম অনুসন্ধানে প্রকাশ করতে দেয়। সাধারণভাবে বলতে গেলে, এই কার্যকারিতা একটি একক, সিস্টেম-ওয়াইড ইউজার ইন্টারফেস নিয়ে গঠিত যা ব্যবহারকারীদের ক্যোয়ারী প্রবেশ করতে দেয়, ব্যবহারকারীদের টাইপ হিসাবে সাজেশন প্রদর্শন করে এবং ফলাফল প্রদর্শন করে। অ্যান্ড্রয়েড এপিআই ডেভেলপারদের তাদের নিজস্ব অ্যাপের মধ্যে অনুসন্ধান প্রদান করতে এই ইন্টারফেসটি পুনরায় ব্যবহার করার অনুমতি দেয় এবং বিকাশকারীদের সাধারণ বিশ্বব্যাপী অনুসন্ধান ব্যবহারকারী ইন্টারফেসে ফলাফল সরবরাহ করার অনুমতি দেয়।

অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নে বিশ্বব্যাপী অনুসন্ধান অন্তর্ভুক্ত করা উচিত, একটি একক, ভাগ করা, সিস্টেম-ওয়াইড অনুসন্ধান ব্যবহারকারী ইন্টারফেস ব্যবহারকারীর ইনপুটের প্রতিক্রিয়ায় রিয়েল-টাইম পরামর্শ দিতে সক্ষম। ডিভাইস ইমপ্লিমেন্টেশনগুলিকে APIগুলি প্রয়োগ করতে হবে যা ডেভেলপারদের তাদের নিজস্ব অ্যাপ্লিকেশনগুলির মধ্যে অনুসন্ধান প্রদান করতে এই ব্যবহারকারী ইন্টারফেসটি পুনরায় ব্যবহার করতে দেয়৷ গ্লোবাল সার্চ ইন্টারফেস বাস্তবায়নকারী ডিভাইস ইমপ্লিমেন্টেশনগুলিকে অবশ্যই APIগুলি প্রয়োগ করতে হবে যা তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে সার্চ বক্সে পরামর্শ যোগ করার অনুমতি দেয় যখন এটি গ্লোবাল সার্চ মোডে চালানো হয়। যদি এই কার্যকারিতা ব্যবহার করে এমন কোনো তৃতীয় পক্ষের অ্যাপ্লিকেশন ইনস্টল করা না থাকে, তবে ডিফল্ট আচরণটি ওয়েব সার্চ ইঞ্জিন ফলাফল এবং পরামর্শ প্রদর্শন করা উচিত।

3.8.5। টোস্ট

অ্যাপ্লিকেশনগুলি শেষ ব্যবহারকারীর কাছে সংক্ষিপ্ত নন-মোডাল স্ট্রিংগুলি প্রদর্শন করতে "টোস্ট" API ব্যবহার করতে পারে, যা অল্প সময়ের পরে অদৃশ্য হয়ে যায় [ সম্পদ, 27 ]। ডিভাইস বাস্তবায়ন কিছু উচ্চ-দৃশ্যমান পদ্ধতিতে শেষ ব্যবহারকারীদের জন্য অ্যাপ্লিকেশন থেকে টোস্ট প্রদর্শন করা আবশ্যক।

3.8.6। থিম

অ্যান্ড্রয়েড একটি সম্পূর্ণ অ্যাক্টিভিটি বা অ্যাপ্লিকেশান জুড়ে শৈলী প্রয়োগ করার জন্য অ্যাপ্লিকেশনগুলির জন্য একটি প্রক্রিয়া হিসাবে "থিম" সরবরাহ করে।

অ্যাপ্লিকেশান ডেভেলপাররা যদি Android SDK দ্বারা সংজ্ঞায়িত Holo থিমের চেহারা এবং অনুভূতির সাথে মেলে তা ব্যবহার করার জন্য Android-এ একটি "Holo" থিম ফ্যামিলি রয়েছে। ডিভাইস ইমপ্লিমেন্টেশনগুলি হলো থিম অ্যাট্রিবিউটগুলির কোনও পরিবর্তন করা উচিত নয় যা অ্যাপ্লিকেশনগুলির সংস্পর্শে আসে [ সম্পদ, 29 ]৷

অ্যান্ড্রয়েড 5.0-এ একটি "মেটেরিয়াল" থিম ফ্যামিলি অন্তর্ভুক্ত রয়েছে সংজ্ঞায়িত শৈলীগুলির একটি সেট হিসাবে অ্যাপ্লিকেশন বিকাশকারীরা যদি তারা ডিজাইন থিমের চেহারা এবং অনুভূতির সাথে বিভিন্ন ধরণের Android ডিভাইসের বিভিন্ন ধরণের জুড়ে ব্যবহার করতে চান। ডিভাইস বাস্তবায়ন অবশ্যই "মেটেরিয়াল" থিম ফ্যামিলিকে সমর্থন করতে হবে এবং মেটেরিয়াল থিমের কোনো অ্যাট্রিবিউট বা অ্যাপ্লিকেশানের সংস্পর্শে থাকা তাদের সম্পদগুলিকে পরিবর্তন করতে হবে না [ সম্পদ, 30 ]৷

অ্যান্ড্রয়েডে একটি "ডিভাইস ডিফল্ট" থিম ফ্যামিলিও অন্তর্ভুক্ত রয়েছে যেটি অ্যাপ্লিকেশন ডেভেলপাররা ডিভাইস বাস্তবায়নকারীর দ্বারা সংজ্ঞায়িত ডিভাইস থিমের চেহারা এবং অনুভূতির সাথে মিল রাখতে চাইলে ব্যবহার করার জন্য সংজ্ঞায়িত শৈলীগুলির একটি সেট হিসাবে। ডিভাইস ইমপ্লিমেন্টেশন ডিভাইস ডিফল্ট থিম অ্যাট্রিবিউটগুলিকে অ্যাপ্লিকেশানগুলিতে উন্মুক্ত করতে পারে [ সম্পদ, 29 ]৷

অ্যান্ড্রয়েড ট্রান্সলুসেন্ট সিস্টেম বার সহ একটি নতুন বৈকল্পিক থিম সমর্থন করে, যা অ্যাপ্লিকেশন বিকাশকারীদের তাদের অ্যাপ সামগ্রী দিয়ে স্ট্যাটাস এবং নেভিগেশন বারের পিছনের জায়গাটি পূরণ করতে দেয়। এই কনফিগারেশনে একটি সামঞ্জস্যপূর্ণ বিকাশকারীর অভিজ্ঞতা সক্ষম করতে, বিভিন্ন ডিভাইস বাস্তবায়নে স্ট্যাটাস বার আইকন শৈলী বজায় রাখা গুরুত্বপূর্ণ। অতএব, অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নে অবশ্যই সিস্টেম স্ট্যাটাস আইকন (যেমন সিগন্যাল শক্তি এবং ব্যাটারি লেভেল) এবং সিস্টেম দ্বারা জারি করা বিজ্ঞপ্তিগুলির জন্য সাদা ব্যবহার করা উচিত, যদি না আইকনটি একটি সমস্যাযুক্ত স্থিতি নির্দেশ করে [ সম্পদ, 29 ]।

3.8.7। লাইভ ওয়ালপেপার

অ্যান্ড্রয়েড একটি উপাদানের প্রকার এবং সংশ্লিষ্ট API এবং জীবনচক্র সংজ্ঞায়িত করে যা অ্যাপ্লিকেশনগুলিকে শেষ ব্যবহারকারীর কাছে এক বা একাধিক "লাইভ ওয়ালপেপার" প্রকাশ করতে দেয় [ সম্পদ, 31 ]৷ লাইভ ওয়ালপেপার হল অ্যানিমেশন, প্যাটার্ন বা সীমিত ইনপুট ক্ষমতা সহ অনুরূপ ছবি যা অন্যান্য অ্যাপ্লিকেশনের পিছনে ওয়ালপেপার হিসাবে প্রদর্শিত হয়।

হার্ডওয়্যার নির্ভরযোগ্যভাবে লাইভ ওয়ালপেপার চালাতে সক্ষম বলে বিবেচিত হয় যদি এটি সমস্ত লাইভ ওয়ালপেপার চালাতে পারে, কার্যকারিতার কোন সীমাবদ্ধতা ছাড়াই, যুক্তিসঙ্গত ফ্রেম হারে অন্যান্য অ্যাপ্লিকেশনের উপর কোন বিরূপ প্রভাব ছাড়াই। যদি হার্ডওয়্যারের সীমাবদ্ধতার কারণে ওয়ালপেপার এবং/অথবা অ্যাপ্লিকেশনগুলি ক্র্যাশ, ত্রুটিপূর্ণ, অত্যধিক CPU বা ব্যাটারি শক্তি খরচ করে, বা অগ্রহণযোগ্যভাবে কম ফ্রেম রেট চালায়, তাহলে হার্ডওয়্যারটি লাইভ ওয়ালপেপার চালানোর জন্য অক্ষম বলে বিবেচিত হয়। উদাহরণ হিসেবে, কিছু লাইভ ওয়ালপেপার তাদের বিষয়বস্তু রেন্ডার করতে OpenGL 2.0 বা 3.x প্রসঙ্গ ব্যবহার করতে পারে। লাইভ ওয়ালপেপার এমন হার্ডওয়্যারে নির্ভরযোগ্যভাবে চলবে না যা একাধিক OpenGL প্রসঙ্গ সমর্থন করে না কারণ একটি OpenGL প্রসঙ্গের লাইভ ওয়ালপেপার ব্যবহার অন্য অ্যাপ্লিকেশনগুলির সাথে বিরোধ করতে পারে যেগুলি একটি OpenGL প্রসঙ্গ ব্যবহার করে।

উপরে বর্ণিত হিসাবে নির্ভরযোগ্যভাবে লাইভ ওয়ালপেপার চালাতে সক্ষম ডিভাইস বাস্তবায়ন লাইভ ওয়ালপেপার প্রয়োগ করা উচিত এবং যখন প্রয়োগ করা হয় তখন প্ল্যাটফর্ম বৈশিষ্ট্য android.software.live_wallpaper-এর রিপোর্ট করতে হবে।

3.8.8। কার্যকলাপ স্যুইচিং

আপস্ট্রিম অ্যান্ড্রয়েড সোর্স কোডের মধ্যে রয়েছে ওভারভিউ স্ক্রিন [ রিসোর্স, 32 ], টাস্ক স্যুইচ করার জন্য একটি সিস্টেম-লেভেল ইউজার ইন্টারফেস এবং সম্প্রতি অ্যাক্সেস করা ক্রিয়াকলাপ এবং কাজগুলি প্রদর্শন করার জন্য অ্যাপ্লিকেশনটির গ্রাফিকাল অবস্থার একটি থাম্বনেইল ইমেজ ব্যবহার করে যে মুহূর্তে ব্যবহারকারী অ্যাপ্লিকেশনটি ছেড়েছে। সাম্প্রতিক ফাংশন নেভিগেশন কী সহ ডিভাইস বাস্তবায়ন বিভাগ 7.2.3 এ বিশদ বিবরণ দেওয়া হয়েছে, ইন্টারফেস পরিবর্তন করতে পারে তবে নিম্নলিখিত প্রয়োজনীয়তাগুলি অবশ্যই পূরণ করতে হবে:

• সংযুক্ত সাম্প্রতিকগুলিকে একটি গোষ্ঠী হিসাবে প্রদর্শন করতে হবে যা একসাথে চলে
• কমপক্ষে 20টি পর্যন্ত প্রদর্শিত কার্যকলাপ সমর্থন করতে হবে
• কমপক্ষে একবারে 4টি কার্যকলাপের শিরোনাম প্রদর্শন করা উচিত
• সাম্প্রতিক সময়ে হাইলাইট রঙ, আইকন, স্ক্রীন শিরোনাম প্রদর্শন করা উচিত
• স্ক্রিন পিনিং আচরণ [ সম্পদ, 33 ] বাস্তবায়ন করতে হবে এবং বৈশিষ্ট্যটি টগল করতে ব্যবহারকারীকে একটি সেটিংস মেনু প্রদান করতে হবে
• একটি ক্লোজিং অ্যাফোরডেন্স ("x") প্রদর্শন করা উচিত তবে ব্যবহারকারী স্ক্রীনের সাথে ইন্টারঅ্যাক্ট না করা পর্যন্ত এটি বিলম্বিত করতে পারে

ওভারভিউ স্ক্রিনের জন্য আপস্ট্রিম অ্যান্ড্রয়েড ইউজার ইন্টারফেস (বা অনুরূপ থাম্বনেইল-ভিত্তিক ইন্টারফেস) ব্যবহার করতে ডিভাইস বাস্তবায়নকে দৃঢ়ভাবে উত্সাহিত করা হয়।

3.8.9। ইনপুট ম্যানেজমেন্ট

অ্যান্ড্রয়েড ইনপুট ম্যানেজমেন্টের জন্য সমর্থন এবং তৃতীয় পক্ষের ইনপুট পদ্ধতি সম্পাদকদের জন্য সমর্থন অন্তর্ভুক্ত করে [ সম্পদ, 34 ]। ডিভাইস বাস্তবায়ন যা ব্যবহারকারীদের ডিভাইসে তৃতীয় পক্ষের ইনপুট পদ্ধতি ব্যবহার করতে দেয় সেগুলিকে অবশ্যই প্ল্যাটফর্ম বৈশিষ্ট্য android.software.input_methods ঘোষণা করতে হবে এবং Android SDK ডকুমেন্টেশনে সংজ্ঞায়িত IME API সমর্থন করতে হবে।

ডিভাইস বাস্তবায়ন যা android.software.input_methods বৈশিষ্ট্য ঘোষণা করে তাদের অবশ্যই তৃতীয়-পক্ষের ইনপুট পদ্ধতি যোগ এবং কনফিগার করার জন্য একটি ব্যবহারকারী-অ্যাক্সেসযোগ্য প্রক্রিয়া প্রদান করতে হবে। ডিভাইস বাস্তবায়ন অবশ্যই android.settings.INPUT_METHOD_SETTINGS উদ্দেশ্যের প্রতিক্রিয়া হিসাবে সেটিংস ইন্টারফেস প্রদর্শন করবে।

3.8.10। লক স্ক্রীন মিডিয়া কন্ট্রোল

রিমোট কন্ট্রোল ক্লায়েন্ট API মিডিয়া নোটিফিকেশন টেমপ্লেটের পক্ষে Android 5.0 থেকে বাতিল করা হয়েছে যা মিডিয়া অ্যাপ্লিকেশনগুলিকে লক স্ক্রিনে প্রদর্শিত প্লেব্যাক নিয়ন্ত্রণগুলির সাথে একীভূত করার অনুমতি দেয় [ সম্পদ, 35 ]৷ ডিভাইস বাস্তবায়ন যেগুলি ডিভাইসে একটি লক স্ক্রীন সমর্থন করে সেগুলি অবশ্যই অন্যান্য বিজ্ঞপ্তিগুলির সাথে মিডিয়া বিজ্ঞপ্তি টেমপ্লেট সমর্থন করে৷

3.8.11। স্বপ্ন

অ্যান্ড্রয়েড ড্রিমস [ রিসোর্সেস, 36 ] নামে ইন্টারেক্টিভ স্ক্রিনসেভারের জন্য সমর্থন অন্তর্ভুক্ত করে। ড্রিমস ব্যবহারকারীদের অ্যাপ্লিকেশনগুলির সাথে ইন্টারঅ্যাক্ট করার অনুমতি দেয় যখন একটি পাওয়ার উত্সের সাথে সংযুক্ত একটি ডিভাইস নিষ্ক্রিয় থাকে বা একটি ডেস্ক ডকে ডক থাকে৷ অ্যান্ড্রয়েড ওয়াচ ডিভাইসগুলি স্বপ্ন বাস্তবায়ন করতে পারে, তবে অন্যান্য ধরণের ডিভাইস বাস্তবায়নে Dreams-এর জন্য সমর্থন অন্তর্ভুক্ত করা উচিত এবং ব্যবহারকারীদের android.settings.DREAM_SETTINGS উদ্দেশ্যের প্রতিক্রিয়া হিসাবে Dreams কনফিগার করার জন্য একটি সেটিংস বিকল্প প্রদান করা উচিত।

3.8.12। অবস্থান

যখন একটি ডিভাইসে একটি হার্ডওয়্যার সেন্সর (যেমন জিপিএস) থাকে যা অবস্থান স্থানাঙ্ক প্রদান করতে সক্ষম হয়, অবস্থান মোডগুলি অবশ্যই সেটিংস [ সম্পদ, 37 ] এর মধ্যে অবস্থান মেনুতে প্রদর্শিত হবে৷

3.8.13। ইউনিকোড এবং ফন্ট

অ্যান্ড্রয়েড রঙ ইমোজি অক্ষরের জন্য সমর্থন অন্তর্ভুক্ত করে। যখন অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নে একটি IME অন্তর্ভুক্ত থাকে, তখন ডিভাইসগুলি অবশ্যই ইউনিকোড 6.1 [ সম্পদ, 38 ] এ সংজ্ঞায়িত ইমোজি অক্ষরের জন্য ব্যবহারকারীকে একটি ইনপুট পদ্ধতি প্রদান করে। সমস্ত ডিভাইস অবশ্যই এই ইমোজি অক্ষরগুলিকে রঙিন গ্লাইফে রেন্ডার করতে সক্ষম হবে।

Android 5.0-এ Roboto 2 ফন্টের জন্য বিভিন্ন ওজনের সমর্থন রয়েছে—sans-serif-thin, sans-serif-light, sans-serif-medium, sans-serif-black, sans-serif-condensed, sans-serif-condensed-light— যা অবশ্যই ডিভাইসে উপলব্ধ ভাষার জন্য এবং ল্যাটিন, গ্রীক, এবং সিরিলিক এর সম্পূর্ণ ইউনিকোড 7.0 কভারেজ, ল্যাটিন এক্সটেন্ডেড A, B, C, এবং D রেঞ্জ এবং ইউনিকোড 7.0-এর মুদ্রা প্রতীক ব্লকের সমস্ত গ্লিফের জন্য অন্তর্ভুক্ত করা আবশ্যক। .

3.9। ডিভাইস প্রশাসন

Android-এ এমন বৈশিষ্ট্য রয়েছে যা নিরাপত্তা-সচেতন অ্যাপ্লিকেশনগুলিকে সিস্টেম স্তরে ডিভাইস প্রশাসনের কার্য সম্পাদন করতে দেয়, যেমন পাসওয়ার্ড নীতি প্রয়োগ করা বা রিমোট ওয়াইপ করা, অ্যান্ড্রয়েড ডিভাইস অ্যাডমিনিস্ট্রেশন API [ সম্পদ, 39 ] এর মাধ্যমে। ডিভাইস বাস্তবায়ন অবশ্যই DevicePolicyManager ক্লাসের একটি বাস্তবায়ন প্রদান করবে [ সম্পদ, 40 ]। লক স্ক্রীনের জন্য সমর্থন অন্তর্ভুক্ত ডিভাইস বাস্তবায়নগুলি অবশ্যই Android SDK ডকুমেন্টেশন [ সম্পদ, 39 ]-এ সংজ্ঞায়িত ডিভাইস প্রশাসন নীতিগুলির সম্পূর্ণ পরিসীমা সমর্থন করে এবং প্ল্যাটফর্ম বৈশিষ্ট্য android.software.device_admin রিপোর্ট করতে হবে৷

ডিভাইস ইমপ্লিমেন্টেশনে ডিভাইস অ্যাডমিনিস্ট্রেশন ফাংশন সঞ্চালন করার জন্য একটি পূর্ব-ইন্সটল করা অ্যাপ্লিকেশন থাকতে পারে কিন্তু এই অ্যাপ্লিকেশনটিকে ডিফল্ট ডিভাইস মালিক অ্যাপ হিসাবে বক্সের বাইরে সেট করা উচিত নয় [ সম্পদ, 41 ]৷

3.10। অ্যাক্সেসযোগ্যতা

অ্যান্ড্রয়েড একটি অ্যাক্সেসিবিলিটি স্তর সরবরাহ করে যা প্রতিবন্ধী ব্যবহারকারীদের তাদের ডিভাইসগুলিকে আরও সহজে নেভিগেট করতে সহায়তা করে৷ উপরন্তু, অ্যান্ড্রয়েড প্ল্যাটফর্ম API সরবরাহ করে যা ব্যবহারকারী এবং সিস্টেম ইভেন্টের জন্য কলব্যাক গ্রহণ করতে অ্যাক্সেসযোগ্যতা পরিষেবা বাস্তবায়নকে সক্ষম করে এবং বিকল্প প্রতিক্রিয়া প্রক্রিয়া তৈরি করে, যেমন টেক্সট-টু-স্পীচ, হ্যাপটিক ফিডব্যাক এবং ট্র্যাকবল/ডি-প্যাড নেভিগেশন [ সম্পদ, 42 ]। ডিভাইস বাস্তবায়ন অবশ্যই ডিফল্ট Android বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণ Android অ্যাক্সেসিবিলিটি ফ্রেমওয়ার্কের একটি বাস্তবায়ন প্রদান করবে। ডিভাইস বাস্তবায়ন নিম্নলিখিত প্রয়োজনীয়তা পূরণ করা আবশ্যক:

• android.accessibilityservice API-এর মাধ্যমে তৃতীয় পক্ষের অ্যাক্সেসিবিলিটি পরিষেবা বাস্তবায়নকে সমর্থন করতে হবে [ সম্পদ, 43 ]
• অ্যাক্সেসিবিলিটি ইভেন্টগুলি তৈরি করতে হবে এবং ডিফল্ট অ্যান্ড্রয়েড বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণভাবে সমস্ত নিবন্ধিত অ্যাক্সেসিবিলিটি সার্ভিস বাস্তবায়নে এই ইভেন্টগুলি সরবরাহ করতে হবে
• কোন অডিও আউটপুট ছাড়া একটি Android ওয়াচ ডিভাইস না হলে, ডিভাইস বাস্তবায়ন অবশ্যই অ্যাক্সেসযোগ্যতা পরিষেবাগুলি সক্ষম এবং অক্ষম করার জন্য একটি ব্যবহারকারী-অ্যাক্সেসযোগ্য প্রক্রিয়া প্রদান করবে এবং android.provider.Settings.ACTION_ACCESSIBILITY_SETTINGS অভিপ্রায়ের প্রতিক্রিয়া হিসাবে এই ইন্টারফেসটি অবশ্যই প্রদর্শন করবে৷

উপরন্তু, ডিভাইস বাস্তবায়ন ডিভাইসে একটি অ্যাক্সেসিবিলিটি পরিষেবার বাস্তবায়ন প্রদান করা উচিত এবং ডিভাইস সেটআপের সময় ব্যবহারকারীদের অ্যাক্সেসিবিলিটি পরিষেবা সক্ষম করার জন্য একটি ব্যবস্থা প্রদান করা উচিত। একটি অ্যাক্সেসিবিলিটি পরিষেবার একটি ওপেন সোর্স বাস্তবায়ন আইস ফ্রি প্রজেক্ট থেকে পাওয়া যায় [ সম্পদ, 44 ]।

3.11। টেক্সট-টু-স্পিচ

অ্যান্ড্রয়েডের মধ্যে এমন API রয়েছে যা অ্যাপ্লিকেশনগুলিকে টেক্সট-টু-স্পীচ (TTS) পরিষেবাগুলি ব্যবহার করার অনুমতি দেয় এবং পরিষেবা প্রদানকারীদের টিটিএস পরিষেবাগুলির বাস্তবায়ন প্রদানের অনুমতি দেয় [ সম্পদ, 45 ]। android.hardware.audio.output বৈশিষ্ট্যের প্রতিবেদনকারী ডিভাইস বাস্তবায়নকে অবশ্যই Android TTS ফ্রেমওয়ার্কের সাথে সম্পর্কিত এই প্রয়োজনীয়তাগুলি পূরণ করতে হবে।

ডিভাইস বাস্তবায়ন:

• অ্যান্ড্রয়েড টিটিএস ফ্রেমওয়ার্ক এপিআই সমর্থন করতে হবে এবং ডিভাইসে উপলব্ধ ভাষাগুলিকে সমর্থন করে এমন একটি টিটিএস ইঞ্জিন অন্তর্ভুক্ত করা উচিত। উল্লেখ্য যে আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স সফ্টওয়্যারটিতে একটি সম্পূর্ণ বৈশিষ্ট্যযুক্ত TTS ইঞ্জিন বাস্তবায়ন অন্তর্ভুক্ত রয়েছে।
• তৃতীয় পক্ষের TTS ইঞ্জিন ইনস্টলেশন সমর্থন করতে হবে
• একটি ব্যবহারকারী-অভিগম্য ইন্টারফেস প্রদান করতে হবে যা ব্যবহারকারীদের সিস্টেম স্তরে ব্যবহারের জন্য একটি TTS ইঞ্জিন নির্বাচন করতে দেয়

3.12। টিভি ইনপুট ফ্রেমওয়ার্ক

অ্যান্ড্রয়েড টেলিভিশন ইনপুট ফ্রেমওয়ার্ক (টিআইএফ) অ্যান্ড্রয়েড টেলিভিশন ডিভাইসে লাইভ কন্টেন্ট বিতরণকে সহজ করে। টিআইএফ ইনপুট মডিউল তৈরি করতে একটি আদর্শ API প্রদান করে যা অ্যান্ড্রয়েড টেলিভিশন ডিভাইসগুলিকে নিয়ন্ত্রণ করে। অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়ন অবশ্যই টেলিভিশন ইনপুট ফ্রেমওয়ার্ক সমর্থন করবে [ সম্পদ, 46 ]।

টিআইএফ সমর্থন করে এমন ডিভাইস বাস্তবায়নকে অবশ্যই প্ল্যাটফর্ম বৈশিষ্ট্য android.software.live_tv ঘোষণা করতে হবে।

4. অ্যাপ্লিকেশন প্যাকেজিং সামঞ্জস্য

ডিভাইস বাস্তবায়নের জন্য অবশ্যই Android ".apk" ফাইলগুলিকে ইনস্টল এবং চালাতে হবে যেমনটি অফিসিয়াল অ্যান্ড্রয়েড SDK [ সম্পদ, 47 ]-এ অন্তর্ভুক্ত "aapt" টুল দ্বারা তৈরি করা হয়েছে৷

ডিভাইস বাস্তবায়ন .apk [ সম্পদ, 48 ], Android ম্যানিফেস্ট [ রিসোর্সেস, 49 ], ডালভিক বাইটকোড [ রিসোর্সেস, 20 ], বা রেন্ডারস্ক্রিপ্ট বাইটকোড ফর্ম্যাটগুলিকে এমনভাবে প্রসারিত করা উচিত নয় যা এই ফাইলগুলিকে সঠিকভাবে ইনস্টল করা এবং চালানো থেকে বাধা দেবে অন্যান্য সামঞ্জস্যপূর্ণ ডিভাইস

5. মাল্টিমিডিয়া সামঞ্জস্য

5.1। মিডিয়া কোডেক

ডিভাইস বাস্তবায়ন অবশ্যই Android SDK ডকুমেন্টেশন [ সম্পদ, 50 ]-এ নির্দিষ্ট করা মূল মিডিয়া ফর্ম্যাটগুলিকে সমর্থন করবে যেখানে এই নথিতে স্পষ্টভাবে অনুমতি দেওয়া হয়েছে। বিশেষভাবে, ডিভাইস বাস্তবায়ন অবশ্যই মিডিয়া ফরম্যাট, এনকোডার, ডিকোডার, ফাইলের ধরন, এবং নীচের টেবিলে সংজ্ঞায়িত কন্টেইনার ফর্ম্যাট সমর্থন করে। এই সমস্ত কোডেকগুলি Android ওপেন সোর্স প্রকল্প থেকে পছন্দের Android বাস্তবায়নে সফ্টওয়্যার বাস্তবায়ন হিসাবে সরবরাহ করা হয়েছে৷

অনুগ্রহ করে মনে রাখবেন যে Google বা ওপেন হ্যান্ডসেট অ্যালায়েন্স কোন প্রতিনিধিত্ব করে না যে এই কোডেকগুলি তৃতীয় পক্ষের পেটেন্ট থেকে মুক্ত৷ যারা হার্ডওয়্যার বা সফ্টওয়্যার পণ্যগুলিতে এই উত্স কোডটি ব্যবহার করতে ইচ্ছুক তাদের পরামর্শ দেওয়া হয় যে ওপেন সোর্স সফ্টওয়্যার বা শেয়ারওয়্যার সহ এই কোডের বাস্তবায়নের জন্য প্রাসঙ্গিক পেটেন্ট ধারকদের কাছ থেকে পেটেন্ট লাইসেন্সের প্রয়োজন হতে পারে৷

5.1.1। অডিও কোডেক

1 ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয় যা android.hardware.microphone সংজ্ঞায়িত করে কিন্তু Android Watch ডিভাইস বাস্তবায়নের জন্য ঐচ্ছিক।

2 শুধুমাত্র 5.0/5.1 সামগ্রীর ডাউনমিক্স প্রয়োজন; 2টির বেশি চ্যানেল রেকর্ডিং বা রেন্ডার করা ঐচ্ছিক।

3 অ্যান্ড্রয়েড হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

4 ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয় যা android.hardware.microphone সংজ্ঞায়িত করে, Android Watch ডিভাইস বাস্তবায়ন সহ।

5.1.2। ইমেজ কোডেক

5.1.3। ভিডিও কোডেক

1 ক্যামেরা হার্ডওয়্যার অন্তর্ভুক্ত এবং android.hardware.camera বা android.hardware.camera.front সংজ্ঞায়িত ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

2 অ্যান্ড্রয়েড ওয়াচ ডিভাইস ছাড়া ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

3 ওয়েব ভিডিও স্ট্রিমিং এবং ভিডিও-কনফারেন্স পরিষেবার গ্রহণযোগ্য মানের জন্য, ডিভাইস বাস্তবায়নে একটি হার্ডওয়্যার VP8 কোডেক ব্যবহার করা উচিত যা [ সম্পদ, 51 ] এর প্রয়োজনীয়তা পূরণ করে।

4 ডিভাইস বাস্তবায়ন ম্যাট্রোস্কা ওয়েবএম ফাইল লেখা সমর্থন করা উচিত।

5.2। ভিডিও এনকোডিং

H.264 কোডেক সমর্থন সহ অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন, বেসলাইন প্রোফাইল লেভেল 3 এবং নিম্নলিখিত SD (স্ট্যান্ডার্ড ডেফিনিশন) ভিডিও এনকোডিং প্রোফাইলগুলিকে সমর্থন করতে হবে এবং প্রধান প্রোফাইল স্তর 4 এবং নিম্নলিখিত HD (হাই ডেফিনিশন) ভিডিও এনকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷ Android টেলিভিশন ডিভাইসগুলিকে 30 fps এ HD 1080p ভিডিও এনকোড করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।

1 যখন হার্ডওয়্যার দ্বারা সমর্থিত, কিন্তু দৃঢ়ভাবে Android টেলিভিশন ডিভাইসের জন্য সুপারিশ করা হয়।

VP8 কোডেক সমর্থন সহ Android ডিভাইস বাস্তবায়ন অবশ্যই SD ভিডিও এনকোডিং প্রোফাইল সমর্থন করে এবং নিম্নলিখিত HD (হাই ডেফিনিশন) ভিডিও এনকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷

1 যখন হার্ডওয়্যার দ্বারা সমর্থিত.

5.3। ভিডিও ডিকোডিং

ডিভাইস বাস্তবায়ন অবশ্যই VP8, VP9, ​​H.264, এবং H.265 কোডেকগুলির জন্য একই স্ট্রিমের মধ্যে গতিশীল ভিডিও রেজোলিউশন স্যুইচিং সমর্থন করবে৷

H.264 ডিকোডার সহ অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন, বেসলাইন প্রোফাইল লেভেল 3 এবং নিম্নলিখিত SD ভিডিও ডিকোডিং প্রোফাইলগুলিকে সমর্থন করতে হবে এবং HD ডিকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷ অ্যান্ড্রয়েড টেলিভিশন ডিভাইসগুলি অবশ্যই হাই প্রোফাইল লেভেল 4.2 এবং HD 1080p ডিকোডিং প্রোফাইল সমর্থন করবে৷

1 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়, কিন্তু হার্ডওয়্যার দ্বারা সমর্থিত শুধুমাত্র অন্যান্য ডিভাইসের জন্য।

2 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

5.1.3 বিভাগে বর্ণিত VP8 কোডেক সমর্থন করার সময় Android ডিভাইস বাস্তবায়ন, নিম্নলিখিত SD ডিকোডিং প্রোফাইলগুলিকে সমর্থন করতে হবে এবং HD ডিকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷ অ্যান্ড্রয়েড টেলিভিশন ডিভাইসগুলি অবশ্যই HD 1080p ডিকোডিং প্রোফাইল সমর্থন করে৷

1 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়, কিন্তু হার্ডওয়্যার দ্বারা সমর্থিত শুধুমাত্র অন্যান্য ধরনের ডিভাইসের জন্য।

2 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন, যখন 5.1.3 বিভাগে বর্ণিত VP9 কোডেক সমর্থন করে, নিম্নলিখিত SD ভিডিও ডিকোডিং প্রোফাইলগুলিকে অবশ্যই সমর্থন করতে হবে এবং HD ডিকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷ Android টেলিভিশন ডিভাইসগুলিকে HD 1080p ডিকোডিং প্রোফাইল সমর্থন করার জন্য দৃঢ়ভাবে সুপারিশ করা হয় এবং UHD ডিকোডিং প্রোফাইল সমর্থন করা উচিত৷ যখন UHD ভিডিও ডিকোডিং প্রোফাইল সমর্থিত হয়, তখন এটি অবশ্যই 8 বিট রঙের গভীরতা সমর্থন করে।

1 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়, কিন্তু হার্ডওয়্যার দ্বারা সমর্থিত শুধুমাত্র অন্যান্য ধরনের ডিভাইসের জন্য।

হার্ডওয়্যার দ্বারা সমর্থিত হলে Android টেলিভিশন ডিভাইস বাস্তবায়নের জন্য 2 দৃঢ়ভাবে প্রস্তাবিত৷

অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন, যখন সেকশন 5.1.3 এ বর্ণিত H.265 কোডেক সমর্থন করে, অবশ্যই প্রধান প্রোফাইল স্তর 3 প্রধান স্তর এবং নিম্নলিখিত SD ভিডিও ডিকোডিং প্রোফাইলগুলিকে সমর্থন করতে হবে এবং HD ডিকোডিং প্রোফাইলগুলিকে সমর্থন করা উচিত৷ অ্যান্ড্রয়েড টেলিভিশন ডিভাইসগুলি অবশ্যই প্রধান প্রোফাইল স্তর 4.1 প্রধান স্তর এবং HD 1080p ডিকোডিং প্রোফাইল সমর্থন করবে এবং মেইন 10 স্তর 5 প্রধান স্তর প্রোফাইল এবং UHD ডিকোডিং প্রোফাইল সমর্থন করবে৷

1 অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়, কিন্তু হার্ডওয়্যার দ্বারা সমর্থিত শুধুমাত্র অন্যান্য ধরনের ডিভাইসের জন্য।

2 হার্ডওয়্যার দ্বারা সমর্থিত যখন Android টেলিভিশন ডিভাইস বাস্তবায়নের জন্য প্রয়োজনীয়।

5.4। অডিও রেকর্ডিং

যদিও এই বিভাগে উল্লিখিত কিছু প্রয়োজনীয়তা Android 4.3 থেকে হওয়া উচিত হিসাবে বলা হয়েছে, ভবিষ্যতের সংস্করণের জন্য সামঞ্জস্যের সংজ্ঞা এগুলিকে অবশ্যই পরিবর্তন করার পরিকল্পনা করা হয়েছে৷ বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলিকে এই প্রয়োজনীয়তাগুলি পূরণ করার জন্য খুব জোরালোভাবে উত্সাহিত করা হয়, অথবা ভবিষ্যতের সংস্করণে আপগ্রেড করার সময় তারা Android সামঞ্জস্য অর্জন করতে সক্ষম হবে না৷

5.4.1। কাঁচা অডিও ক্যাপচার

android.hardware.microphone ঘোষণা করে এমন ডিভাইস বাস্তবায়নে নিম্নোক্ত বৈশিষ্ট্যের সাথে কাঁচা অডিও বিষয়বস্তু ক্যাপচার করার অনুমতি দিতে হবে:

• বিন্যাস : লিনিয়ার PCM, 16-বিট
• নমুনার হার : 8000, 11025, 16000, 44100
• চ্যানেল : মনো

android.hardware.microphone ঘোষণা করে এমন ডিভাইস বাস্তবায়নে নিম্নোক্ত বৈশিষ্ট্যের সাথে কাঁচা অডিও সামগ্রী ক্যাপচার করার অনুমতি দেওয়া উচিত:

• বিন্যাস : লিনিয়ার PCM, 16-বিট
• নমুনার হার : 22050, 48000
• চ্যানেল : স্টেরিও

5.4.2। ভয়েস রিকগনিশনের জন্য ক্যাপচার করুন

উপরের রেকর্ডিং স্পেসিফিকেশনগুলি ছাড়াও, যখন একটি অ্যাপ্লিকেশন android.media.MediaRecorder.AudioSource.VOICE_RECOGNITION অডিও উত্স ব্যবহার করে একটি অডিও স্ট্রিম রেকর্ড করা শুরু করে:

• ডিভাইসটি প্রায় সমতল প্রশস্ততা বনাম ফ্রিকোয়েন্সি বৈশিষ্ট্য প্রদর্শন করা উচিত: বিশেষভাবে, ±3 dB, 100 Hz থেকে 4000 Hz পর্যন্ত।
• অডিও ইনপুট সংবেদনশীলতা এমনভাবে সেট করা উচিত যাতে 1000 Hz-এ একটি 90 dB সাউন্ড পাওয়ার লেভেল (SPL) উৎস 16-বিট নমুনার জন্য 2500 এর RMS প্রদান করে।
• PCM প্রশস্ততা স্তরগুলি মাইক্রোফোনে -18 dB থেকে +12 dB থেকে 90 dB SPL পর্যন্ত কমপক্ষে একটি 30 dB পরিসরে ইনপুট SPL পরিবর্তনগুলিকে রৈখিকভাবে ট্র্যাক করা উচিত৷
• মাইক্রোফোনে 90 dB SPL ইনপুট স্তরে 1Khz-এর জন্য মোট হারমোনিক বিকৃতি 1% এর কম হওয়া উচিত।
• শব্দ হ্রাস প্রক্রিয়াকরণ, উপস্থিত থাকলে, অক্ষম করা আবশ্যক।
• স্বয়ংক্রিয় লাভ নিয়ন্ত্রণ, উপস্থিত থাকলে, অক্ষম করা আবশ্যক

যদি প্ল্যাটফর্মটি শব্দ শনাক্তকরণের জন্য টিউন করা শব্দ দমন প্রযুক্তি সমর্থন করে, তাহলে প্রভাবটি অবশ্যই android.media.audiofx.NoiseSuppressor API থেকে নিয়ন্ত্রণযোগ্য হতে হবে। অধিকন্তু, শব্দ দমনকারীর প্রভাব বর্ণনাকারীর জন্য UUID ক্ষেত্রটি অবশ্যই শব্দ দমন প্রযুক্তির প্রতিটি বাস্তবায়নকে স্বতন্ত্রভাবে সনাক্ত করতে হবে।

5.4.3। প্লেব্যাকের পুনরায় রাউটিংয়ের জন্য ক্যাপচার করুন

android.media.MediaRecorder.AudioSource ক্লাসে REMOTE_SUBMIX অডিও উৎস রয়েছে। যে ডিভাইসগুলি android.hardware.audio.output ঘোষণা করে সেগুলিকে অবশ্যই REMOTE_SUBMIX অডিও উত্সটি যথাযথভাবে প্রয়োগ করতে হবে যাতে কোনও অ্যাপ্লিকেশন যখন এই অডিও উত্স থেকে রেকর্ড করার জন্য android.media.AudioRecord API ব্যবহার করে, তখন এটি নিম্নলিখিতগুলি ব্যতীত সমস্ত অডিও স্ট্রিমের মিশ্রণ ক্যাপচার করতে পারে :

• স্ট্রিম_রিং
• STREAM_ALARM
• STREAM_NOTIFICATION

5.5। অডিও প্লেব্যাক

ডিভাইস বাস্তবায়ন যা android.hardware.audio.output ঘোষণা করে এই বিভাগে প্রয়োজনীয়তা মেনে চলতে হবে।

5.5.1। কাঁচা অডিও প্লেব্যাক

ডিভাইসটিকে অবশ্যই নিম্নোক্ত বৈশিষ্ট্য সহ কাঁচা অডিও সামগ্রী প্লেব্যাকের অনুমতি দিতে হবে:

• বিন্যাস : লিনিয়ার PCM, 16-বিট
• নমুনার হার : 8000, 11025, 16000, 22050, 32000, 44100
• চ্যানেল : মনো, স্টেরিও

ডিভাইসটিকে নিম্নোক্ত বৈশিষ্ট্য সহ কাঁচা অডিও সামগ্রী প্লেব্যাকের অনুমতি দেওয়া উচিত:

• নমুনার হার : 24000, 48000

5.5.2। অডিও প্রভাব

অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নের জন্য অডিও প্রভাবের জন্য একটি API প্রদান করে [ সম্পদ, 52 ]। ডিভাইস বাস্তবায়ন যা android.hardware.audio.output বৈশিষ্ট্য ঘোষণা করে:

• EFFECT_TYPE_EQUALIZER এবং EFFECT_TYPE_LOUDNESS_ENHANCER বাস্তবায়নকে অডিও ইফেক্ট সাবক্লাস ইকুয়ালাইজার, লাউডনেস এনহ্যান্সারের মাধ্যমে নিয়ন্ত্রণযোগ্য সমর্থন করতে হবে
• ভিজ্যুয়ালাইজার এপিআই বাস্তবায়নকে সমর্থন করতে হবে, ভিজ্যুয়ালাইজার ক্লাসের মাধ্যমে নিয়ন্ত্রণযোগ্য
• অডিও ইফেক্ট সাব-ক্লাসের মাধ্যমে নিয়ন্ত্রণযোগ্য EFFECT_TYPE_BASS_BOOST, EFFECT_TYPE_ENV_REVERB, EFFECT_TYPE_PRESET_REVERB, এবং EFFECT_TYPE_VIRTUALIZER বাস্তবায়নকে সমর্থন করা উচিত BassBoost, এনভাইজার, প্রি-এভার, এনভাইজার

5.5.3। অডিও আউটপুট ভলিউম

অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নে অবশ্যই সিস্টেম মাস্টার ভলিউম এবং সমর্থিত আউটপুটগুলিতে ডিজিটাল অডিও আউটপুট ভলিউম অ্যাটেন্যুয়েশনের জন্য সমর্থন অন্তর্ভুক্ত থাকতে হবে, সংকুচিত অডিও পাসথ্রু আউটপুট ছাড়া (যেখানে ডিভাইসে কোনও অডিও ডিকোডিং করা হয় না)।

5.6। অডিও লেটেন্সি

অডিও লেটেন্সি হল একটি অডিও সিগন্যাল একটি সিস্টেমের মধ্য দিয়ে যাওয়ার সময় বিলম্ব। অনেক শ্রেণীর অ্যাপ্লিকেশন রিয়েল-টাইম সাউন্ড ইফেক্ট অর্জন করতে স্বল্প বিলম্বের উপর নির্ভর করে।

এই বিভাগের উদ্দেশ্যে, নিম্নলিখিত সংজ্ঞাগুলি ব্যবহার করুন:

• আউটপুট ল্যাটেন্সি -যখন কোনও অ্যাপ্লিকেশন পিসিএম-কোডেড ডেটার একটি ফ্রেম লেখেন এবং যখন সংশ্লিষ্ট শব্দটি কোনও বাহ্যিক শ্রোতার দ্বারা শোনা যায় বা ট্রান্সডুসার দ্বারা পর্যবেক্ষণ করা যায় তখন এর মধ্যে ব্যবধান।
• কোল্ড আউটপুট লেটেন্সি - প্রথম ফ্রেমের জন্য আউটপুট ল্যাটেন্সি, যখন অডিও আউটপুট সিস্টেমটি অনুরোধের আগে নিষ্ক্রিয় এবং চালিত হয়।
• অবিচ্ছিন্ন আউটপুট ল্যাটেন্সি - ডিভাইসটি অডিও খেলার পরে পরবর্তী ফ্রেমগুলির জন্য আউটপুট ল্যাটেন্সি।
• ইনপুট ল্যাটেন্সি -যখন কোনও বাহ্যিক শব্দ ডিভাইসে উপস্থাপন করা হয় এবং যখন কোনও অ্যাপ্লিকেশন পিসিএম-কোডেড ডেটার সংশ্লিষ্ট ফ্রেমটি পড়ে তখন বিরতি।
• কোল্ড ইনপুট লেটেন্সি - হারানো ইনপুট সময় এবং প্রথম ফ্রেমের জন্য ইনপুট ল্যাটেন্সির যোগফল, যখন অডিও ইনপুট সিস্টেমটি অনুরোধের আগে অলস এবং চালিত হয়ে থাকে।
• অবিচ্ছিন্ন ইনপুট লেটেন্সি - পরবর্তী ফ্রেমগুলির জন্য ইনপুট ল্যাটেন্সি, যখন ডিভাইসটি অডিও ক্যাপচার করছে।
• কোল্ড আউটপুট জিটার - ঠান্ডা আউটপুট ল্যাটেন্সি মানগুলির পৃথক পরিমাপের মধ্যে বৈকল্পিকতা।
• কোল্ড ইনপুট জিটার - ঠান্ডা ইনপুট ল্যাটেন্সি মানগুলির পৃথক পরিমাপের মধ্যে বৈকল্পিকতা।
• অবিচ্ছিন্ন রাউন্ড-ট্রিপ ল্যাটেন্সি -অবিচ্ছিন্ন ইনপুট লেটেন্সি প্লাস অবিচ্ছিন্ন আউটপুট ল্যাটেন্সি প্লাস 5 মিলিসেকেন্ডের যোগফল।
• ওপেনসএল ইএস পিসিএম বাফার সারি এপিআই -অ্যান্ড্রয়েড এনডিকে-র মধ্যে পিসিএম-সম্পর্কিত ওপেনএসএল এস এপিআইগুলির সেট; ndk_root/ডকস/ওপেনসেলস/সূচক html দেখুন।

ডিভাইস বাস্তবায়ন যা android.hardware.audio.output ঘোষণা করে এই অডিও আউটপুট প্রয়োজনীয়তা পূরণ বা অতিক্রম করা উচিত:

• 100 মিলিসেকেন্ড বা তার কম কোল্ড আউটপুট লেটেন্সি
• একটানা আউটপুট লেটেন্সি 45 মিলিসেকেন্ড বা তার কম
• ঠান্ডা আউটপুট জিটার হ্রাস করুন

অবিচ্ছিন্ন আউটপুট লেটেন্সি এবং কোল্ড আউটপুট ল্যাটেন্সির জন্য কমপক্ষে একটি সমর্থিত অডিও আউটপুট ডিভাইসের জন্য যদি কোনও ডিভাইস বাস্তবায়ন ওপেনসএল ইএস পিসিএম বাফার ক্যু এপিআই ব্যবহার করার সময় কোনও প্রাথমিক ক্রমাঙ্কনের পরে এই বিভাগের প্রয়োজনীয়তা পূরণ করে তবে এটি কম-লেটেন্সি অডিওর জন্য সমর্থন প্রতিবেদন করতে পারে , android.content.pm.packagemanager শ্রেণীর [ সংস্থান, 53 ] এর মাধ্যমে অ্যান্ড্রয়েড.এইউইও.লো_ল্যাটিেন্সি বৈশিষ্ট্যটি প্রতিবেদন করে। বিপরীতে, যদি ডিভাইস বাস্তবায়ন এই প্রয়োজনীয়তাগুলি পূরণ না করে তবে এটি অবশ্যই কম-ল্যাটেন্সি অডিওর জন্য সমর্থন রিপোর্ট করবে না।

অ্যান্ড্রয়েড.হার্ডওয়্যার অন্তর্ভুক্ত ডিভাইস বাস্তবায়নগুলিতে এই ইনপুট অডিও প্রয়োজনীয়তাগুলি পূরণ করা উচিত:

• 100 মিলিসেকেন্ড বা তার কম কোল্ড ইনপুট লেটেন্সি
• 30 মিলিসেকেন্ড বা তারও কম অবিচ্ছিন্ন ইনপুট লেটেন্সি
• 50 মিলিসেকেন্ড বা তার চেয়ে কম অবিচ্ছিন্ন রাউন্ড-ট্রিপ বিলম্ব
• ঠান্ডা ইনপুট জিটারটি হ্রাস করুন

৫.৭। নেটওয়ার্ক প্রোটোকল

ডিভাইসগুলি অবশ্যই অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন [ সংস্থানসমূহ, 50 ] এ উল্লিখিত অডিও এবং ভিডিও প্লেব্যাকের জন্য মিডিয়া নেটওয়ার্ক প্রোটোকলগুলিকে সমর্থন করতে হবে। বিশেষত, ডিভাইসগুলি অবশ্যই নিম্নলিখিত মিডিয়া নেটওয়ার্ক প্রোটোকলগুলিকে সমর্থন করবে:

• RTSP (RTP, SDP)
• HTTP(S) প্রগতিশীল স্ট্রিমিং
• HTTP (গুলি) লাইভ স্ট্রিমিং খসড়া প্রোটোকল, সংস্করণ 3 [ সংস্থানসমূহ, 54 ]

৫.৮। নিরাপদ মিডিয়া

ডিভাইস বাস্তবায়নগুলি যা সুরক্ষিত ভিডিও আউটপুট সমর্থন করে এবং সুরক্ষিত পৃষ্ঠগুলিকে সমর্থন করতে সক্ষম তাদের অবশ্যই ডিসপ্লে.ফ্ল্যাগ_সেকিউরের জন্য সমর্থন ঘোষণা করতে হবে। ডিভাইস বাস্তবায়নগুলি যা ডিসপ্লে.ফ্ল্যাগ_সেকিউর এর জন্য সমর্থন ঘোষণা করে, যদি তারা কোনও ওয়্যারলেস ডিসপ্লে প্রোটোকলকে সমর্থন করে তবে অবশ্যই এইচডিসিপি 2.x বা উচ্চতর মিরাকাস্ট ওয়্যারলেস ডিসপ্লেগুলির জন্য ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী প্রক্রিয়া সহ লিঙ্কটি সুরক্ষিত করতে হবে। একইভাবে যদি তারা তারযুক্ত বাহ্যিক প্রদর্শনকে সমর্থন করে তবে ডিভাইস বাস্তবায়নগুলি অবশ্যই এইচডিসিপি 1.2 বা তার বেশি সমর্থন করবে। অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নগুলি 4 কে রেজোলিউশন এবং এইচডিসিপি 1.4 বা তার বেশি নিম্ন রেজোলিউশনের জন্য সমর্থনকারী ডিভাইসগুলির জন্য এইচডিসিপি 2.2 সমর্থন করতে হবে। উজানের অ্যান্ড্রয়েড ওপেন সোর্স বাস্তবায়নে ওয়্যারলেস (মিরাকাস্ট) এবং তারযুক্ত (এইচডিএমআই) প্রদর্শনগুলির জন্য সমর্থন অন্তর্ভুক্ত রয়েছে যা এই প্রয়োজনীয়তাটি পূরণ করে।

6. বিকাশকারীর সরঞ্জাম এবং বিকল্পগুলির সামঞ্জস্য

6.1। ডেভেলপার টুলস

ডিভাইস বাস্তবায়ন অবশ্যই Android SDK-এ প্রদত্ত Android বিকাশকারী সরঞ্জামগুলিকে সমর্থন করবে৷ অ্যান্ড্রয়েড সামঞ্জস্যপূর্ণ ডিভাইসগুলির সাথে অবশ্যই সামঞ্জস্যপূর্ণ হতে হবে:

• অ্যান্ড্রয়েড ডিবাগ ব্রিজ (এডিবি) [ সংস্থানসমূহ, 55 ]

ডিভাইস বাস্তবায়নগুলি অবশ্যই ডাম্পসিস [ সংস্থানসমূহ, 56 ] সহ অ্যান্ড্রয়েড এসডিকে নথিভুক্ত সমস্ত এডিবি ফাংশনগুলিকে সমর্থন করতে হবে। ডিভাইস-সাইড এডিবি ডেমন অবশ্যই ডিফল্টরূপে নিষ্ক্রিয় হতে হবে এবং অ্যান্ড্রয়েড ডিবাগ ব্রিজটি চালু করার জন্য অবশ্যই একটি ব্যবহারকারী-অ্যাক্সেসযোগ্য প্রক্রিয়া থাকতে হবে। যদি কোনও ডিভাইস বাস্তবায়ন ইউএসবি পেরিফেরাল মোড বাদ দেয় তবে এটি অবশ্যই স্থানীয়-অঞ্চল নেটওয়ার্কের মাধ্যমে অ্যান্ড্রয়েড ডিবাগ ব্রিজটি প্রয়োগ করতে হবে (যেমন ইথারনেট বা 802.11)।

অ্যান্ড্রয়েডে সুরক্ষিত এডিবির জন্য সমর্থন অন্তর্ভুক্ত রয়েছে। সুরক্ষিত এডিবি পরিচিত অনুমোদিত হোস্টগুলিতে এডিবি সক্ষম করে। ডিভাইস বাস্তবায়নগুলি অবশ্যই সুরক্ষিত এডিবি সমর্থন করবে।

• ডালভিক ডিবাগ মনিটর পরিষেবা (ডিডিএমএস) [ সংস্থানসমূহ, 57 ]

ডিভাইস বাস্তবায়ন অবশ্যই Android SDK-তে নথিভুক্ত সমস্ত ddms বৈশিষ্ট্য সমর্থন করবে। যেহেতু ডিডিএমএস এডিবি ব্যবহার করে, ডিডিএমএসের জন্য সমর্থন ডিফল্টরূপে নিষ্ক্রিয় হওয়া উচিত, তবে যখনই ব্যবহারকারী উপরের মতো অ্যান্ড্রয়েড ডিবাগ ব্রিজটি সক্রিয় করে রাখেন তখন অবশ্যই এটি সমর্থন করা উচিত।

• বানর [ সংস্থানসমূহ, 58 ]

ডিভাইস বাস্তবায়নে অবশ্যই মাঙ্কি ফ্রেমওয়ার্ক অন্তর্ভুক্ত করা উচিত এবং এটিকে অ্যাপ্লিকেশন ব্যবহারের জন্য উপলব্ধ করা উচিত।

• Systrace [ সংস্থানসমূহ, 59 ]

ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড এসডিকে নথিভুক্ত হিসাবে সিস্ট্রেস সরঞ্জাম সমর্থন করবে। সিরস্ট্রেস অবশ্যই ডিফল্টরূপে নিষ্ক্রিয় হওয়া উচিত এবং সিস্টেমটি চালু করার জন্য অবশ্যই একটি ব্যবহারকারী-অ্যাক্সেসযোগ্য প্রক্রিয়া থাকতে হবে।

বেশিরভাগ লিনাক্স-ভিত্তিক সিস্টেম এবং অ্যাপল ম্যাকিনটোশ সিস্টেমগুলি অতিরিক্ত সমর্থন ছাড়াই স্ট্যান্ডার্ড অ্যান্ড্রয়েড এসডিকে টুল ব্যবহার করে অ্যান্ড্রয়েড ডিভাইসগুলিকে চিনতে পারে; তবে মাইক্রোসফট উইন্ডোজ সিস্টেমে সাধারণত নতুন অ্যান্ড্রয়েড ডিভাইসের জন্য ড্রাইভারের প্রয়োজন হয়। (উদাহরণস্বরূপ, নতুন বিক্রেতা আইডি এবং কখনও কখনও নতুন ডিভাইস আইডিগুলির জন্য উইন্ডোজ সিস্টেমের জন্য কাস্টম USB ড্রাইভারের প্রয়োজন হয়।) যদি একটি ডিভাইস বাস্তবায়ন adb টুল দ্বারা স্বীকৃত না হয় যেমনটি স্ট্যান্ডার্ড অ্যান্ড্রয়েড SDK-তে দেওয়া হয়েছে, ডিভাইস বাস্তবায়নকারীদের অবশ্যই উইন্ডোজ ড্রাইভার প্রদান করতে হবে যা বিকাশকারীদের সাথে সংযোগ করতে দেয় adb প্রোটোকল ব্যবহার করে ডিভাইস। এই ড্রাইভারগুলি 32-বিট এবং 64-বিট উভয় সংস্করণে উইন্ডোজ এক্সপি, উইন্ডোজ ভিস্তা, উইন্ডোজ 7, ​​উইন্ডোজ 8, এবং উইন্ডোজ 9 এর জন্য সরবরাহ করতে হবে।

6.2। বিকাশকারী বিকল্প

অ্যান্ড্রয়েডে অ্যাপ্লিকেশন বিকাশ-সম্পর্কিত সেটিংস কনফিগার করার জন্য বিকাশকারীদের সমর্থন অন্তর্ভুক্ত রয়েছে। ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড.সেটেটিংসকে সম্মান করতে হবে app অ্যাপ্লিকেশন বিকাশ-সম্পর্কিত সেটিংস [ সংস্থানসমূহ, 60 ] দেখানোর উদ্দেশ্যে অ্যাপ্লিকেশন_ডভেলপমেন্ট_সেটেটিংয়ের উদ্দেশ্যে। উজানের অ্যান্ড্রয়েড বাস্তবায়ন ডিফল্টরূপে বিকাশকারী বিকল্প মেনুটি লুকিয়ে রাখে এবং ডিভাইস সম্পর্কে সেটিংস > ডিভাইস> বিল্ড নম্বর মেনু আইটেমটি তৈরি করে সেটিংসে সাত (7) বার টিপানোর পরে বিকাশকারী বিকল্পগুলি চালু করতে সক্ষম করে। ডিভাইস বাস্তবায়নগুলি অবশ্যই বিকাশকারী বিকল্পগুলির জন্য একটি ধারাবাহিক অভিজ্ঞতা সরবরাহ করতে হবে। বিশেষত, ডিভাইস বাস্তবায়নগুলি অবশ্যই ডিফল্টরূপে বিকাশকারী বিকল্পগুলি আড়াল করতে হবে এবং বিকাশকারী বিকল্পগুলি সক্ষম করার জন্য একটি প্রক্রিয়া সরবরাহ করতে হবে যা উজানের অ্যান্ড্রয়েড বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণ।

7. হার্ডওয়্যার সামঞ্জস্য

যদি কোনো ডিভাইসে একটি নির্দিষ্ট হার্ডওয়্যার উপাদান থাকে যার থার্ড-পার্টি ডেভেলপারদের জন্য সংশ্লিষ্ট API থাকে, তাহলে ডিভাইস বাস্তবায়নকে অবশ্যই সেই API প্রয়োগ করতে হবে যেমনটি Android SDK ডকুমেন্টেশনে বর্ণিত হয়েছে। যদি SDK-এ একটি API একটি হার্ডওয়্যার উপাদানের সাথে ইন্টারঅ্যাক্ট করে যা ঐচ্ছিক বলে উল্লেখ করা হয় এবং ডিভাইস বাস্তবায়নে সেই উপাদানটি না থাকে:

• সম্পূর্ণ শ্রেণীর সংজ্ঞা (এসডিকে দ্বারা নথিভুক্ত হিসাবে) উপাদানটির এপিআইগুলির জন্য এখনও উপস্থাপন করতে হবে।
• এপিআইয়ের আচরণগুলি অবশ্যই কিছু যুক্তিসঙ্গত ফ্যাশনে নো-অপ হিসাবে প্রয়োগ করা উচিত।
• এসডিকে ডকুমেন্টেশন দ্বারা অনুমোদিত যেখানে এপিআই পদ্ধতিগুলি অবশ্যই নাল মানগুলি ফিরিয়ে দিতে হবে।
• এপিআই পদ্ধতিগুলি অবশ্যই ক্লাসগুলির নো-ওপি বাস্তবায়নগুলি ফেরত দিতে হবে যেখানে এসডিকে ডকুমেন্টেশন দ্বারা নাল মানগুলি অনুমোদিত নয়।
• এপিআই পদ্ধতিগুলি অবশ্যই এসডিকে ডকুমেন্টেশন দ্বারা নথিভুক্ত না করে ব্যতিক্রমগুলি ছুঁড়ে দেবে না।

একটি দৃশ্যের একটি সাধারণ উদাহরণ যেখানে এই প্রয়োজনীয়তাগুলি প্রযোজ্য তা হল টেলিফোনি API: এমনকি নন-ফোন ডিভাইসগুলিতে, এই APIগুলি অবশ্যই যুক্তিসঙ্গত নো-অপস হিসাবে প্রয়োগ করা উচিত।

ডিভাইস বাস্তবায়নগুলি অবশ্যই একই বিল্ড ফিঙ্গারপ্রিন্টের জন্য অ্যান্ড্রয়েড.কন্টেন্ট.পিএম.প্যাকেজ ম্যানেজার ক্লাসে getSystemaveableablefeatures () এবং Hasystystemfeature (স্ট্রিং) পদ্ধতিগুলির মাধ্যমে সঠিক হার্ডওয়্যার কনফিগারেশন সম্পর্কিত তথ্যের ধারাবাহিকভাবে প্রতিবেদন করতে হবে। [ সংস্থানসমূহ, 53]

7.1। ডিসপ্লে এবং গ্রাফিক্স

অ্যান্ড্রয়েডে এমন সুবিধাগুলি অন্তর্ভুক্ত রয়েছে যা ডিভাইসের জন্য যথাযথভাবে অ্যাপ্লিকেশন সম্পদ এবং ইউআই লেআউটগুলি সামঞ্জস্য করে, যাতে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি বিভিন্ন হার্ডওয়্যার কনফিগারেশনে [ সংস্থানসমূহ, 61 ] ভালভাবে চালিত হয় তা নিশ্চিত করতে। ডিভাইসগুলিকে অবশ্যই এই এপিআই এবং আচরণগুলি যথাযথভাবে প্রয়োগ করতে হবে, যেমনটি এই বিভাগে বিশদভাবে বলা হয়েছে।

এই বিভাগে প্রয়োজনীয়তা দ্বারা উল্লিখিত ইউনিটগুলি নিম্নলিখিত হিসাবে সংজ্ঞায়িত করা হয়েছে:

• শারীরিক তির্যক আকার - প্রদর্শনের আলোকিত অংশের দুটি বিরোধী কোণার মধ্যে ইঞ্চি দূরত্ব।
• প্রতি ইঞ্চি বিন্দু (ডিপিআই) - 1 "এর লিনিয়ার অনুভূমিক বা উল্লম্ব স্প্যান দ্বারা অন্তর্ভুক্ত পিক্সেলের সংখ্যা যেখানে ডিপিআই মানগুলি তালিকাভুক্ত করা হয়, উভয় অনুভূমিক এবং উল্লম্ব ডিপিআই অবশ্যই পরিসরের মধ্যে পড়তে হবে।
• দিক অনুপাত - সংক্ষিপ্ত মাত্রায় স্ক্রিনের দীর্ঘ মাত্রার অনুপাত। উদাহরণস্বরূপ, 480x854 পিক্সেলের একটি ডিসপ্লে হবে 854 / 480 = 1.779, বা মোটামুটি "16:9"।
• ঘনত্ব-স্বতন্ত্র পিক্সেল (ডিপি) -ভার্চুয়াল পিক্সেল ইউনিট 160 ডিপিআই স্ক্রিনে স্বাভাবিক করা হয়েছে, হিসাবে গণনা করা হয়েছে: পিক্সেল = ডিপিএস * (ঘনত্ব / 160)।

7.1.1। স্ক্রিন কনফিগারেশন

7.1.1.1। পর্দার আকার

অ্যান্ড্রয়েড ইউআই ফ্রেমওয়ার্ক বিভিন্ন স্ক্রিন আকারকে বিভিন্ন ধরণের সমর্থন করে এবং অ্যাপ্লিকেশনগুলিকে ডিভাইস স্ক্রিনের আকার (ওরফে "স্ক্রিন লেআউট") এর মাধ্যমে অ্যান্ড্রয়েড.কন্টেন্ট.আরইএস.কনফিগারেশন.স্ক্রিনলয়আউট স্ক্রিনলআউট_সাইজ_মাস্কের সাথে জিজ্ঞাসা করতে দেয়। ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন [ সংস্থানসমূহ, 61 ] এ সংজ্ঞায়িত হিসাবে সঠিক স্ক্রিনের আকারটি রিপোর্ট করতে হবে এবং উজানের অ্যান্ড্রয়েড প্ল্যাটফর্ম দ্বারা নির্ধারিত হতে হবে। বিশেষত, ডিভাইস বাস্তবায়নগুলি অবশ্যই নিম্নলিখিত লজিকাল ঘনত্ব-স্বতন্ত্র পিক্সেল (ডিপি) স্ক্রিনের মাত্রা অনুসারে সঠিক স্ক্রিনের আকারটি রিপোর্ট করতে হবে।

• ডিভাইসগুলির অবশ্যই কমপক্ষে 426 ডিপি এক্স 320 ডিপি ('ছোট') এর স্ক্রিন আকার থাকতে হবে, যদি না এটি অ্যান্ড্রয়েড ঘড়ির ডিভাইস হয়।
• স্ক্রিনের আকার 'সাধারণ' প্রতিবেদন করে এমন ডিভাইসগুলিতে অবশ্যই কমপক্ষে 480 ডিপি এক্স 320 ডিপি স্ক্রিন আকার থাকতে হবে।
• স্ক্রিনের আকার 'বড়' প্রতিবেদন করে এমন ডিভাইসগুলিতে অবশ্যই কমপক্ষে 640 ডিপি এক্স 480 ডিপি স্ক্রিন আকার থাকতে হবে।
• স্ক্রিনের আকার 'xlarge' রিপোর্ট করে এমন ডিভাইসগুলি অবশ্যই কমপক্ষে 960 ডিপি এক্স 720 ডিপি এর স্ক্রিন আকার থাকতে হবে।

এছাড়াও,

• অ্যান্ড্রয়েড ঘড়ির ডিভাইসগুলির অবশ্যই 1.1 থেকে 2.5 ইঞ্চি পর্যন্ত দৈহিক তির্যক আকারের সাথে একটি স্ক্রিন থাকতে হবে
• শারীরিকভাবে সংহত স্ক্রিন সহ অন্যান্য ধরণের অ্যান্ড্রয়েড ডিভাইস বাস্তবায়ন, শারীরিক তির্যক আকারে কমপক্ষে 2.5 ইঞ্চি একটি স্ক্রিন থাকতে হবে।

ডিভাইসগুলিকে তাদের রিপোর্ট করা স্ক্রিনের আকার যেকোন সময় পরিবর্তন করা উচিত নয়।

অ্যাপ্লিকেশনগুলি option চ্ছিকভাবে নির্দেশ করে যে তারা কোন স্ক্রিনের আকারগুলি সমর্থন করে অ্যান্ড্রয়েডম্যানিফেস্ট.এক্সএমএল ফাইলে বৈশিষ্ট্য। Android SDK ডকুমেন্টেশনে বর্ণিত ছোট, স্বাভাবিক, বড় এবং x বৃহৎ স্ক্রীনের জন্য ডিভাইস বাস্তবায়নকে অবশ্যই অ্যাপ্লিকেশনের বিবৃত সমর্থনকে সঠিকভাবে সম্মান করতে হবে।

7.1.1.2। স্ক্রীন অ্যাসপেক্ট রেশিও

স্ক্রিনের দিক অনুপাতটি অবশ্যই 1.333 (4: 3) থেকে 1.86 (প্রায় 16: 9) পর্যন্ত একটি মান হতে হবে, তবে অ্যান্ড্রয়েড ঘড়ির ডিভাইসগুলির 1.0 (1: 1) এর দিক অনুপাত থাকতে পারে কারণ এই জাতীয় ডিভাইস বাস্তবায়ন একটি ui_mode_type_watch হিসাবে ব্যবহার করবে android.content.res.configration.uimode।

7.1.1.3। পর্দার ঘনত্ব

অ্যান্ড্রয়েড UI ফ্রেমওয়ার্ক অ্যাপ্লিকেশান ডেভেলপারদের অ্যাপ্লিকেশন সংস্থানগুলিকে লক্ষ্য করতে সহায়তা করার জন্য মানক যৌক্তিক ঘনত্বের একটি সেট সংজ্ঞায়িত করে৷ ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড.উটিল.ডিসপ্লেমেট্রিক্স এপিআইগুলির মাধ্যমে নিম্নলিখিত লজিকাল অ্যান্ড্রয়েড ফ্রেমওয়ার্কের ঘনত্বগুলির মধ্যে একটিতে অবশ্যই রিপোর্ট করতে হবে এবং অবশ্যই এই স্ট্যান্ডার্ড ঘনত্বের অ্যাপ্লিকেশনগুলি সম্পাদন করতে হবে এবং ডিফল্ট প্রদর্শনের জন্য কোনও সময়ে মানটি পরিবর্তন করতে হবে না।

• 120 dpi (ldpi)
• 160 dpi (mdpi)
• 213 dpi (tvdpi)
• 240 ডিপিআই (এইচডিপিআই)
• 320 dpi (xhdpi)
• 400 dpi (400 dpi)
• 480 dpi (xxhdpi)
• 560 dpi (560dpi)
• 640 dpi (xxxhdpi)

ডিভাইস বাস্তবায়নে স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্কের ঘনত্ব সংজ্ঞায়িত করা উচিত যা সংখ্যাগতভাবে স্ক্রিনের শারীরিক ঘনত্বের সবচেয়ে কাছাকাছি, যদি না সেই যৌক্তিক ঘনত্ব রিপোর্ট করা স্ক্রীনের আকারকে ন্যূনতম সমর্থিত থেকে নিচে ঠেলে দেয়। যদি স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্কের ঘনত্ব যা সংখ্যাগতভাবে শারীরিক ঘনত্বের সবচেয়ে কাছাকাছি হয় তার ফলে একটি স্ক্রীনের আকার হয় যা ক্ষুদ্রতম সমর্থিত সামঞ্জস্যপূর্ণ স্ক্রীনের আকারের (320 dp প্রস্থ) থেকে ছোট হয়, তাহলে ডিভাইস বাস্তবায়নগুলিকে পরবর্তী সর্বনিম্ন স্ট্যান্ডার্ড Android ফ্রেমওয়ার্ক ঘনত্বের রিপোর্ট করা উচিত।

7.1.2। ডিসপ্লে মেট্রিক্স

ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড.উটিল.ডিসপ্লেমেট্রিক্স [ সংস্থানসমূহ, 62 ] এ সংজ্ঞায়িত সমস্ত ডিসপ্লে মেট্রিকগুলির জন্য সঠিক মানগুলির প্রতিবেদন করতে হবে এবং এম্বেড থাকা বা বাহ্যিক স্ক্রিনটি ডিফল্ট ডিসপ্লে হিসাবে ব্যবহৃত হয়েছে কিনা তা নির্বিশেষে একই মানগুলি প্রতিবেদন করতে হবে।

7.1.3। স্ক্রিন ওরিয়েন্টেশন

ডিভাইসগুলি অবশ্যই তারা কোন স্ক্রিন ওরিয়েন্টেশনগুলিকে সমর্থন করে তা রিপোর্ট করতে হবে (android.hardware.screen.portrait এবং/অথবা android.hardware.screen.landscape) এবং কমপক্ষে একটি সমর্থিত ওরিয়েন্টেশন রিপোর্ট করতে হবে। উদাহরণস্বরূপ, একটি নির্দিষ্ট ওরিয়েন্টেশন ল্যান্ডস্কেপ স্ক্রিন সহ একটি ডিভাইস যেমন একটি টেলিভিশন বা ল্যাপটপের কেবলমাত্র অ্যান্ড্রয়েড.হার্ডওয়্যার.স্ক্রিন.ল্যান্ডস্কেপ রিপোর্ট করা উচিত।

উভয় স্ক্রিন ওরিয়েন্টেশনের প্রতিবেদনকারী ডিভাইসগুলি অবশ্যই প্রতিকৃতি বা ল্যান্ডস্কেপ স্ক্রিন ওরিয়েন্টেশনে অ্যাপ্লিকেশন দ্বারা গতিশীল ওরিয়েন্টেশনকে সমর্থন করতে হবে। অর্থাৎ, ডিভাইসটিকে অবশ্যই একটি নির্দিষ্ট স্ক্রিন ওরিয়েন্টেশনের জন্য অ্যাপ্লিকেশনের অনুরোধকে সম্মান করতে হবে। ডিভাইস বাস্তবায়ন ডিফল্ট হিসাবে প্রতিকৃতি বা ল্যান্ডস্কেপ অভিযোজন নির্বাচন করতে পারে।

যখনই android.content.res.Configuration.orientation, android.view.Display.getOrientation(), বা অন্যান্য API-এর মাধ্যমে জিজ্ঞাসা করা হয় তখন ডিভাইসগুলিকে ডিভাইসের বর্তমান ওরিয়েন্টেশনের জন্য সঠিক মান রিপোর্ট করতে হবে।

অভিযোজন পরিবর্তন করার সময় ডিভাইসগুলির রিপোর্ট করা পর্দার আকার বা ঘনত্ব পরিবর্তন করা উচিত নয়৷

7.1.4। 2D এবং 3D গ্রাফিক্স ত্বরণ

ডিভাইস বাস্তবায়ন অবশ্যই OpenGL ES 1.0 এবং 2.0 উভয়কেই সমর্থন করবে, যেমনটি Android SDK ডকুমেন্টেশনে মূর্ত এবং বিশদভাবে বর্ণনা করা হয়েছে। ডিভাইস বাস্তবায়নগুলি এটিকে সমর্থন করতে সক্ষম ডিভাইসগুলিতে ওপেনজিএল ইএস 3.0 বা 3.1 সমর্থন করা উচিত। অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন [ রিসোর্স, 63 ] এ বিশদ হিসাবে ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড রেন্ডারস্ক্রিপ্ট সমর্থন করতে হবে।

ডিভাইস বাস্তবায়নগুলি অবশ্যই ওপেনজিএল ইএস 1.0, ওপেনজিএল ইএস 2.0, ওপেনজিএল ইএস 3.0 বা ওপেনজিএল 3.1 সমর্থনকারী হিসাবে নিজেকে সঠিকভাবে সনাক্ত করতে হবে। এটাই:

• পরিচালিত এপিআই (যেমন GLES10.GETSTRING () পদ্ধতির মাধ্যমে ওপেনজিএল ইএস 1.0 এবং ওপেনজিএল ইএস 2.0 এর জন্য সমর্থন রিপোর্ট করতে হবে।
• নেটিভ সি/সি ++ ওপেনজিএল এপিআই (এপিআইগুলি libgles_v1cm.so, libgles_v2.so, বা libegl.so এর মাধ্যমে অ্যাপ্লিকেশনগুলিতে উপলব্ধ) অবশ্যই ওপেনজিএল ইএস 1.0 এবং ওপেনজিএল ইএস 2.0 এর জন্য সমর্থন রিপোর্ট করতে হবে।
• ওপেনজিএল ইএস 3.0 বা 3.1 এর জন্য সমর্থন ঘোষণা করে এমন ডিভাইস বাস্তবায়নগুলি অবশ্যই সংশ্লিষ্ট পরিচালিত এপিআইগুলিকে সমর্থন করবে এবং নেটিভ সি/সি ++ এপিআইয়ের জন্য সমর্থন অন্তর্ভুক্ত করবে। ওপেনজিএল ইএস 3.0 বা 3.1 এর জন্য সমর্থন ঘোষণা করে এমন ডিভাইস বাস্তবায়নে, libglesv2.so অবশ্যই ওপেনজিএল ইএস 2.0 ফাংশন প্রতীক ছাড়াও সংশ্লিষ্ট ফাংশন প্রতীকগুলি রফতানি করতে হবে।

ওপেনজিএল ইএস 3.1 ছাড়াও, অ্যান্ড্রয়েড জাভা ইন্টারফেস [ সংস্থানসমূহ, 64 ] সহ একটি এক্সটেনশন প্যাক সরবরাহ করে এবং অ্যাডভান্সড গ্রাফিক্স কার্যকারিতা যেমন টেসেলেশন এবং এএসটিসি টেক্সচার সংক্ষেপণ বিন্যাসের জন্য দেশীয় সমর্থন। অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নগুলি এই এক্সটেনশন প্যাকটিকে সমর্থন করতে পারে এবং - কেবলমাত্র সম্পূর্ণরূপে প্রয়োগ করা হলে and

এছাড়াও, ডিভাইস বাস্তবায়নগুলি যে কোনও পছন্দসই ওপেনগেল এস এক্সটেনশনগুলি প্রয়োগ করতে পারে। যাইহোক, ডিভাইস বাস্তবায়ন অবশ্যই OpenGL ES পরিচালিত এবং নেটিভ API-এর মাধ্যমে রিপোর্ট করতে হবে যে সমস্ত এক্সটেনশন স্ট্রিং তারা সমর্থন করে, এবং বিপরীতভাবে এক্সটেনশন স্ট্রিংগুলিকে রিপোর্ট করা উচিত নয় যা তারা সমর্থন করে না।

নোট করুন যে অ্যান্ড্রয়েডের মধ্যে অ্যাপ্লিকেশনগুলির জন্য সমর্থন অন্তর্ভুক্ত রয়েছে ally চ্ছিকভাবে নির্দিষ্ট করে যে তাদের নির্দিষ্ট ওপেনজিএল টেক্সচার সংক্ষেপণ ফর্ম্যাটগুলির প্রয়োজন। এই ফর্ম্যাটগুলি সাধারণত বিক্রেতা-নির্দিষ্ট। কোনও নির্দিষ্ট টেক্সচার সংক্ষেপণ বিন্যাস বাস্তবায়নের জন্য অ্যান্ড্রয়েড দ্বারা ডিভাইস বাস্তবায়নগুলির প্রয়োজন হয় না। যাইহোক, ওপেনজিএল এপিআই-এ getString() পদ্ধতির মাধ্যমে তারা যেকোন টেক্সচার কম্প্রেশন ফরম্যাটকে সঠিকভাবে রিপোর্ট করতে হবে যা তারা সমর্থন করে।

অ্যান্ড্রয়েডে অ্যাপ্লিকেশনগুলির জন্য একটি প্রক্রিয়া অন্তর্ভুক্ত রয়েছে যে তারা অ্যাপ্লিকেশন, ক্রিয়াকলাপ, উইন্ডো, বা একটি ম্যানিফেস্ট ট্যাগ অ্যান্ড্রয়েড ব্যবহারের মাধ্যমে স্তরটি দেখুন 2D গ্রাফিক্সের জন্য হার্ডওয়্যার ত্বরণ সক্ষম করতে চান: হার্ডওয়ারিয়াসিলারেটেড বা ডাইরেক্ট এপিআই কল [ সংস্থানসমূহ, 65 ]।

ডিভাইস বাস্তবায়নগুলি অবশ্যই ডিফল্টরূপে হার্ডওয়্যার ত্বরণ সক্ষম করতে হবে এবং বিকাশকারী অ্যান্ড্রয়েড সেট করে অনুরোধ করে যদি হার্ডওয়্যার ত্বরণ অক্ষম করতে হবে: হার্ডওয়ারিয়াকসিলেটেড = "মিথ্যা" বা অ্যান্ড্রয়েড ভিউ এপিআইয়ের মাধ্যমে সরাসরি হার্ডওয়্যার ত্বরণ অক্ষম করে।

তদতিরিক্ত, ডিভাইস বাস্তবায়নগুলি অবশ্যই হার্ডওয়্যার ত্বরণ [ সংস্থানসমূহ, 65 ] এ অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশনের সাথে সামঞ্জস্যপূর্ণ আচরণ প্রদর্শন করতে হবে।

অ্যান্ড্রয়েডে একটি টেক্সচারভিউ অবজেক্ট অন্তর্ভুক্ত রয়েছে যা বিকাশকারীদের সরাসরি ইউআই হায়ারার্কিতে রেন্ডারিং লক্ষ্য হিসাবে হার্ডওয়্যার-এক্সিলারেটেড ওপেনজিএল ইএস টেক্সচারগুলিকে সংহত করতে দেয়। ডিভাইস বাস্তবায়ন অবশ্যই TextureView API সমর্থন করবে এবং আপস্ট্রিম অ্যান্ড্রয়েড বাস্তবায়নের সাথে সামঞ্জস্যপূর্ণ আচরণ প্রদর্শন করবে।

অ্যান্ড্রয়েডে EGL_ANDROID_RECORDABLE এর জন্য সমর্থন অন্তর্ভুক্ত রয়েছে, একটি এগলকনফিগ অ্যাট্রিবিউট যা ইগলকনফিগ কোনও ভিডিওতে চিত্রগুলি রেকর্ড করে এমন একটি অ্যান্টিভাইন্ডোতে রেন্ডারিং সমর্থন করে কিনা তা নির্দেশ করে। ডিভাইস বাস্তবায়নগুলি অবশ্যই EGL_ANDROID_RECORDABLE এক্সটেনশন [ সংস্থানসমূহ, 66 ] সমর্থন করবে।

7.1.5। লিগ্যাসি অ্যাপ্লিকেশন সামঞ্জস্য মোড

অ্যান্ড্রয়েড একটি "সামঞ্জস্যতা মোড" নির্দিষ্ট করে যেখানে ফ্রেমওয়ার্কটি একটি 'সাধারণ' স্ক্রিন আকারের সমতুল্য (320 ডিপি প্রস্থ) মোডে পরিচালনা করে লিগ্যাসি অ্যাপ্লিকেশনগুলির সুবিধার জন্য অ্যান্ড্রয়েডের পুরানো সংস্করণগুলির জন্য তৈরি করা হয়নি যা প্রাক-তারিখের স্ক্রিন-আকারের স্বাধীনতার জন্য বিকশিত হয় না। ডিভাইস বাস্তবায়নে অবশ্যই উজানের অ্যান্ড্রয়েড ওপেন সোর্স কোড দ্বারা প্রয়োগ করা হিসাবে লিগ্যাসি অ্যাপ্লিকেশন সামঞ্জস্যতা মোডের জন্য সমর্থন অন্তর্ভুক্ত থাকতে হবে। অর্থাৎ, ডিভাইস বাস্তবায়নের ট্রিগার বা থ্রেশহোল্ডগুলিকে পরিবর্তন করা উচিত নয় যেখানে সামঞ্জস্য মোড সক্রিয় করা হয় এবং সামঞ্জস্য মোডের আচরণকে পরিবর্তন করা উচিত নয়।

7.1.6। স্ক্রিন প্রযুক্তি

অ্যান্ড্রয়েড প্ল্যাটফর্মে এপিআই অন্তর্ভুক্ত রয়েছে যা অ্যাপ্লিকেশনগুলিকে ডিসপ্লেতে সমৃদ্ধ গ্রাফিক্স রেন্ডার করতে দেয়। ডিভাইসগুলিকে অবশ্যই এই নথিতে বিশেষভাবে অনুমোদিত না হলে অ্যান্ড্রয়েড এসডিকে দ্বারা সংজ্ঞায়িত হিসাবে এই সমস্ত এপিআই সমর্থন করতে হবে।

• ডিভাইসগুলি অবশ্যই 16-বিট রঙের গ্রাফিক্স রেন্ডারিং করতে সক্ষম ডিসপ্লেগুলিকে সমর্থন করবে এবং 24-বিট রঙের গ্রাফিক্সের সক্ষম ডিসপ্লেগুলিকে সমর্থন করা উচিত।
• ডিভাইসগুলি অবশ্যই অ্যানিমেশনগুলি রেন্ডারিং করতে সক্ষম ডিসপ্লেগুলিকে সমর্থন করবে।
• ব্যবহৃত ডিসপ্লে প্রযুক্তিতে অবশ্যই 0.9 এবং 1.15 এর মধ্যে একটি পিক্সেল দিক অনুপাত (পিএআর) থাকতে হবে। অর্থাৎ, পিক্সেল দিক অনুপাতটি 10 ​​~ 15% সহনশীলতার সাথে বর্গক্ষেত্রের (1.0) কাছাকাছি হওয়া উচিত।

7.1.7। বাহ্যিক প্রদর্শন

অ্যান্ড্রয়েডে বাহ্যিক প্রদর্শন অ্যাক্সেসের জন্য মিডিয়া ভাগ করে নেওয়ার ক্ষমতা এবং বিকাশকারী এপিআই সক্ষম করতে মাধ্যমিক প্রদর্শনের জন্য সমর্থন অন্তর্ভুক্ত রয়েছে। যদি কোনও ডিভাইস তারযুক্ত, ওয়্যারলেস বা এম্বেড থাকা অতিরিক্ত প্রদর্শন সংযোগের মাধ্যমে কোনও বাহ্যিক প্রদর্শনকে সমর্থন করে তবে ডিভাইস বাস্তবায়ন অবশ্যই অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন [ সংস্থানসমূহ, 67 ] এ বর্ণিত হিসাবে ডিসপ্লে ম্যানেজার এপিআই প্রয়োগ করতে হবে।

7.2। ইনপুট ডিভাইস

7.2.1। কীবোর্ড

ডিভাইস বাস্তবায়ন:

• ইনপুট ম্যানেজমেন্ট ফ্রেমওয়ার্কের জন্য অবশ্যই সমর্থন অন্তর্ভুক্ত করা উচিত (যা তৃতীয় পক্ষের বিকাশকারীদের ইনপুট পদ্ধতি সম্পাদক তৈরি করতে দেয়-IY নরম কীবোর্ড) http://developer.android.com এ বিস্তারিত হিসাবে
• অ্যান্ড্রয়েড ঘড়ির ডিভাইসগুলি ব্যতীত যেখানে স্ক্রিনের আকারটি নরম কীবোর্ড থাকা কম যুক্তিসঙ্গত করে তোলে তবে কমপক্ষে একটি নরম কীবোর্ড বাস্তবায়ন (হার্ড কীবোর্ড উপস্থিত কিনা তা নির্বিশেষে) সরবরাহ করতে হবে
• অতিরিক্ত নরম কীবোর্ড বাস্তবায়ন অন্তর্ভুক্ত থাকতে পারে
• একটি হার্ডওয়্যার কীবোর্ড অন্তর্ভুক্ত থাকতে পারে
• অবশ্যই একটি হার্ডওয়্যার কীবোর্ড অন্তর্ভুক্ত করা উচিত নয় যা android.content.res.configration.keyboard [ সংস্থানসমূহ, 68 ] (কিউওয়ার্টি বা 12-কী) এ উল্লিখিত ফর্ম্যাটগুলির মধ্যে একটির সাথে মেলে না

7.2.2। নন-টাচ নেভিগেশন

ডিভাইস বাস্তবায়ন:

• ডিভাইস বাস্তবায়ন যদি অ্যান্ড্রয়েড টেলিভিশন ডিভাইস না হয় তবে একটি নন-টাচ নেভিগেশন বিকল্প (ট্র্যাকবল, ডি-প্যাড, বা চাকা) বাদ দিতে পারে
• Android.content.res.configration.navigion [ সংস্থানসমূহ, 68 ] এর জন্য সঠিক মানটি অবশ্যই প্রতিবেদন করতে হবে
• ইনপুট ম্যানেজমেন্ট ইঞ্জিনগুলির সাথে সামঞ্জস্যপূর্ণ পাঠ্য নির্বাচন এবং সম্পাদনার জন্য অবশ্যই একটি যুক্তিসঙ্গত বিকল্প ব্যবহারকারী ইন্টারফেস প্রক্রিয়া সরবরাহ করতে হবে। উজানের অ্যান্ড্রয়েড ওপেন সোর্স বাস্তবায়নে ডিভাইসগুলির সাথে ব্যবহারের জন্য উপযুক্ত একটি নির্বাচন প্রক্রিয়া অন্তর্ভুক্ত রয়েছে যা নন-টাচ নেভিগেশন ইনপুটগুলির অভাব রয়েছে।

7.2.3। নেভিগেশন কী

হোম, রিসেন্টস এবং ব্যাক ফাংশনগুলি (মূল ইভেন্টগুলিতে ম্যাপ করা কীকোড_হোম, কীকোড_এপ_সুইচ, যথাক্রমে কীকোড_ব্যাক) অ্যান্ড্রয়েড নেভিগেশন দৃষ্টান্তের জন্য প্রয়োজনীয় এবং অতএব;

• অ্যান্ড্রয়েড হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নগুলি অবশ্যই হোম, রিসেন্টস এবং ব্যাক ফাংশন সরবরাহ করতে হবে।
• অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নগুলি অবশ্যই হোম এবং ব্যাক ফাংশন সরবরাহ করতে হবে।
• অ্যান্ড্রয়েড ওয়াচ ডিভাইস বাস্তবায়নের অবশ্যই ব্যবহারকারীর কাছে হোম ফাংশনটি উপলব্ধ থাকতে হবে এবং এটি ইউআই_মোড_ টাইপ_ওয়াচে কখন থাকে তা ব্যতীত পিছনের ফাংশন।
• অন্যান্য সমস্ত ধরণের ডিভাইস বাস্তবায়ন অবশ্যই হোম এবং ব্যাক ফাংশন সরবরাহ করতে হবে।

এই ফাংশনগুলি ডেডিকেটেড ফিজিক্যাল বোতামগুলির মাধ্যমে প্রয়োগ করা যেতে পারে (যেমন যান্ত্রিক বা ক্যাপাসিটিভ টাচ বোতাম), বা স্ক্রিনের একটি স্বতন্ত্র অংশে ডেডিকেটেড সফ্টওয়্যার কীগুলি ব্যবহার করে প্রয়োগ করা যেতে পারে, অঙ্গভঙ্গি, টাচ প্যানেল ইত্যাদি অ্যান্ড্রয়েড উভয় বাস্তবায়ন সমর্থন করে। এই সমস্ত ফাংশনগুলি দৃশ্যমান হলে একটি একক ক্রিয়া (যেমন ট্যাপ, ডাবল-ক্লিক বা অঙ্গভঙ্গি) দিয়ে অ্যাক্সেসযোগ্য হতে হবে।

রিসেন্টস ফাংশন, যদি সরবরাহ করা হয় তবে অবশ্যই একটি দৃশ্যমান বোতাম বা আইকন থাকতে হবে যদি না পূর্ণ-স্ক্রিন মোডে অন্যান্য নেভিগেশন ফাংশনগুলির সাথে একসাথে লুকানো থাকে। এটি পূর্ববর্তী অ্যান্ড্রয়েড সংস্করণগুলি থেকে আপগ্রেড করা ডিভাইসগুলির ক্ষেত্রে প্রযোজ্য নয় যা নেভিগেশনের জন্য শারীরিক বোতাম রয়েছে এবং কোনও রিসেন্টস কী নেই।

হোম এবং ব্যাক ফাংশনগুলি, যদি সরবরাহ করা হয় তবে প্রত্যেকের অবশ্যই একটি দৃশ্যমান বোতাম বা আইকন থাকতে হবে যদি না পূর্ণ-স্ক্রিন মোডে অন্যান্য নেভিগেশন ফাংশনগুলির সাথে একসাথে লুকানো থাকে বা যখন ইউআইএমডি ইউআই_মোড_ টাইপ_মাস্ক ইউআই_মোড_ টাইপ_ওয়াচ সেট করা থাকে।

মেনু ফাংশনটি অ্যান্ড্রয়েড 4.0.০ এর পর থেকে অ্যাকশন বারের পক্ষে হ্রাস করা হয়। সুতরাং অ্যান্ড্রয়েড 5.0 এর সাথে নতুন ডিভাইস বাস্তবায়ন শিপিং অবশ্যই মেনু ফাংশনের জন্য একটি উত্সর্গীকৃত শারীরিক বোতাম প্রয়োগ করা উচিত নয়। পুরানো ডিভাইস বাস্তবায়নগুলি মেনু ফাংশনের জন্য একটি উত্সর্গীকৃত শারীরিক বোতাম প্রয়োগ করা উচিত নয়, তবে যদি শারীরিক মেনু বোতামটি প্রয়োগ করা হয় এবং ডিভাইসটি টার্গেটসডকভার্স> 10 সহ অ্যাপ্লিকেশনগুলি চালাচ্ছে তবে ডিভাইস বাস্তবায়ন:

• অ্যাকশন বারে অ্যাকশন ওভারফ্লো বোতামটি দৃশ্যমান হলে অবশ্যই প্রদর্শন করতে হবে এবং ফলস্বরূপ অ্যাকশন ওভারফ্লো মেনু পপআপ খালি নেই। অ্যান্ড্রয়েড ৪.৪ এর আগে চালু হওয়া ডিভাইস বাস্তবায়নের জন্য তবে অ্যান্ড্রয়েড 5.0 এ আপগ্রেড করে, এটি প্রস্তাবিত।
• অ্যাকশন বারে ওভারফ্লো বোতামটি নির্বাচন করে প্রদর্শিত অ্যাকশন ওভারফ্লো পপআপের অবস্থানটি পরিবর্তন করা উচিত নয়
• শারীরিক মেনু বোতামটি নির্বাচন করে প্রদর্শিত হলে স্ক্রিনের পরিবর্তিত অবস্থানে অ্যাকশনটি ওভারফ্লো পপআপ রেন্ডার করতে পারে

পিছনের সামঞ্জস্যের জন্য, ডিভাইস বাস্তবায়নগুলি অবশ্যই কোনও শারীরিক বোতাম, একটি সফ্টওয়্যার কী বা অঙ্গভঙ্গি দ্বারা টার্গেটসডকভার্স <= 10, যখন মেনু ফাংশনটি অ্যাপ্লিকেশনগুলিতে উপলব্ধ করতে হবে। অন্যান্য নেভিগেশন ফাংশনগুলির সাথে একসাথে লুকানো না হলে এই মেনু ফাংশনটি উপস্থাপন করা উচিত।

অ্যান্ড্রয়েড সহায়তা অ্যাকশন [ সংস্থানসমূহ, 69 ] সমর্থন করে। অ্যান্ড্রয়েড ডিভাইস বাস্তবায়নগুলি অ্যান্ড্রয়েড ওয়াচ ডিভাইসগুলি ব্যতীত অ্যাপ্লিকেশনগুলি চালানোর সময় সর্বদা ব্যবহারকারীর জন্য সহায়তা ক্রিয়াটি সরবরাহ করতে হবে। সহায়তা ক্রিয়াটি হোম বোতামে দীর্ঘ-প্রেস বা সফ্টওয়্যার হোম কীতে একটি সোয়াইপ-আপ অঙ্গভঙ্গি হিসাবে প্রয়োগ করা উচিত। এই ফাংশনটি অন্য শারীরিক বোতাম, সফ্টওয়্যার কী বা অঙ্গভঙ্গির মাধ্যমে প্রয়োগ করা যেতে পারে তবে অন্য নেভিগেশন কীগুলি দৃশ্যমান হলে একটি একক ক্রিয়া (যেমন ট্যাপ, ডাবল-ক্লিক বা অঙ্গভঙ্গি) দিয়ে অ্যাক্সেসযোগ্য হতে হবে।

ডিভাইস বাস্তবায়নগুলি নেভিগেশন কীগুলি প্রদর্শন করতে স্ক্রিনের একটি স্বতন্ত্র অংশ ব্যবহার করতে পারে তবে যদি তা হয় তবে অবশ্যই এই প্রয়োজনীয়তাগুলি পূরণ করতে হবে:

• ডিভাইস বাস্তবায়ন নেভিগেশন কীগুলি অবশ্যই স্ক্রিনের একটি স্বতন্ত্র অংশ ব্যবহার করতে হবে, অ্যাপ্লিকেশনগুলিতে উপলভ্য নয় এবং এটি অবশ্যই অস্পষ্ট বা অন্যথায় অ্যাপ্লিকেশনগুলিতে উপলব্ধ স্ক্রিনের অংশে হস্তক্ষেপ করতে হবে না।
• ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যাপ্লিকেশনগুলিতে প্রদর্শনের একটি অংশ সরবরাহ করতে হবে যা বিভাগ 7.1.1 এ সংজ্ঞায়িত প্রয়োজনীয়তাগুলি পূরণ করে।
• ডিভাইস বাস্তবায়নগুলি অবশ্যই নেভিগেশন কীগুলি প্রদর্শন করতে হবে যখন অ্যাপ্লিকেশনগুলি কোনও সিস্টেম ইউআই মোড নির্দিষ্ট না করে বা সিস্টেম_ইউআই_ফ্ল্যাগ_ভিজিবল নির্দিষ্ট করে না।
• ডিভাইস বাস্তবায়নগুলি অবশ্যই একটি অবিস্মরণীয় "লো প্রোফাইল" (যেমন। ডিমেড) মোডে নেভিগেশন কীগুলি উপস্থাপন করতে হবে যখন অ্যাপ্লিকেশনগুলি সিস্টেম_ইউআই_ফ্ল্যাগ_লো_প্রোফাইল নির্দিষ্ট করে।
• ডিভাইস বাস্তবায়নগুলি অবশ্যই নেভিগেশন কীগুলি লুকিয়ে রাখতে হবে যখন অ্যাপ্লিকেশনগুলি সিস্টেম_ইউআই_ফ্ল্যাগ_হাইড_নভিগেশন নির্দিষ্ট করে।

7.2.4। টাচস্ক্রিন ইনপুট

ডিভাইস বাস্তবায়নের কোনও ধরণের পয়েন্টার ইনপুট সিস্টেম থাকতে হবে (হয় মাউস-জাতীয় বা স্পর্শ)। তবে, যদি কোনও ডিভাইস বাস্তবায়ন কোনও পয়েন্টার ইনপুট সিস্টেমকে সমর্থন না করে তবে এটি অবশ্যই অ্যান্ড্রয়েড.হার্ডওয়্যার.টচস্ক্রিন বা অ্যান্ড্রয়েড.হার্ডওয়ার.ফেকটচ বৈশিষ্ট্যটি ধ্রুবকটি রিপোর্ট করবে না। ডিভাইস বাস্তবায়ন যা একটি পয়েন্টার ইনপুট সিস্টেম অন্তর্ভুক্ত করে:

• যদি ডিভাইস ইনপুট সিস্টেম একাধিক পয়েন্টার সমর্থন করে তবে সম্পূর্ণ স্বাধীনভাবে ট্র্যাক করা পয়েন্টারগুলিকে সমর্থন করা উচিত
• ডিভাইসে নির্দিষ্ট টাচস্ক্রিনের ধরণের সাথে সম্পর্কিত অ্যান্ড্রয়েড.কন্টেন্ট.আরস.কনফিগারেশন.আচস্ক্রিন [ রিসোর্স, 68 ] এর মানটি অবশ্যই প্রতিবেদন করতে হবে

অ্যান্ড্রয়েডে বিভিন্ন টাচস্ক্রিন, টাচ প্যাড এবং জাল টাচ ইনপুট ডিভাইসের জন্য সমর্থন অন্তর্ভুক্ত। টাচস্ক্রিন ভিত্তিক ডিভাইস বাস্তবায়নগুলি একটি ডিসপ্লে [ রিসোর্স, 70 ] এর সাথে সম্পর্কিত যেমন ব্যবহারকারীর স্ক্রিনে সরাসরি আইটেমগুলি পরিচালনা করার ছাপ রয়েছে। যেহেতু ব্যবহারকারী সরাসরি স্ক্রিনটি স্পর্শ করছে, তাই সিস্টেমগুলি হেরফের করা অবজেক্টগুলি নির্দেশ করার জন্য কোনও অতিরিক্ত সাশ্রয়ী প্রয়োজন হয় না। বিপরীতে, একটি জাল টাচ ইন্টারফেস একটি ব্যবহারকারী ইনপুট সিস্টেম সরবরাহ করে যা টাচস্ক্রিন সক্ষমতার একটি উপসেটকে প্রায় সমান করে। উদাহরণস্বরূপ, একটি মাউস বা রিমোট কন্ট্রোল যা একটি অন-স্ক্রিন কার্সারকে চালিত করে তা স্পর্শের কাছাকাছি থাকে তবে ব্যবহারকারীকে প্রথমে পয়েন্ট বা ফোকাস করতে হবে তারপরে ক্লিক করুন। মাউস, ট্র্যাকপ্যাড, গাইরো-ভিত্তিক এয়ার মাউস, গাইরো-পয়েন্টার, জয়স্টিক এবং মাল্টি-টাচ ট্র্যাকপ্যাডের মতো অসংখ্য ইনপুট ডিভাইস জাল স্পর্শ ইন্টারঅ্যাকশনগুলিকে সমর্থন করতে পারে। অ্যান্ড্রয়েড 5.0 এর মধ্যে বৈশিষ্ট্যটি ধ্রুবক অ্যান্ড্রয়েড.হার্ডওয়্যার.ফেকট্যাচ অন্তর্ভুক্ত রয়েছে, যা একটি উচ্চ-বিশ্বস্ততা নন-টাচ (পয়েন্টার-ভিত্তিক) ইনপুট ডিভাইসের সাথে সম্পর্কিত যেমন মাউস বা ট্র্যাকপ্যাড যা স্পর্শ-ভিত্তিক ইনপুট (বেসিক অঙ্গভঙ্গি সমর্থন সহ) পর্যাপ্তভাবে অনুকরণ করতে পারে, এবং ইঙ্গিত দেয় যে ডিভাইসটি টাচস্ক্রিন কার্যকারিতার একটি অনুকরণীয় সাবসেটকে সমর্থন করে। ডিভাইস বাস্তবায়নগুলি যা জাল স্পর্শ বৈশিষ্ট্যটি ঘোষণা করে তা অবশ্যই বিভাগ 7.2.5 এ জাল স্পর্শের প্রয়োজনীয়তাগুলি পূরণ করতে হবে।

ডিভাইস বাস্তবায়নগুলি অবশ্যই ব্যবহৃত ইনপুটটির ধরণের সাথে সম্পর্কিত সঠিক বৈশিষ্ট্যটি রিপোর্ট করতে হবে। একটি টাচস্ক্রিন (একক-স্পর্শ বা আরও ভাল) অন্তর্ভুক্ত ডিভাইস বাস্তবায়নগুলি অবশ্যই প্ল্যাটফর্মের বৈশিষ্ট্যটি ধ্রুবক অ্যান্ড্রয়েড.হার্ডওয়্যার.টচস্ক্রিন বৈশিষ্ট্যটি রিপোর্ট করতে হবে। ডিভাইস বাস্তবায়ন যা প্ল্যাটফর্মের প্রতিবেদন করে ধ্রুবক অ্যান্ড্রয়েড.হার্ডওয়্যার.টচস্ক্রিনকে অবশ্যই প্ল্যাটফর্ম বৈশিষ্ট্যটি কনস্ট্যান্ট অ্যান্ড্রয়েড.হার্ডওয়্যার.ফেকেটচচ বৈশিষ্ট্যটি রিপোর্ট করতে হবে। ডিভাইস বাস্তবায়নগুলি যা কোনও টাচস্ক্রিন অন্তর্ভুক্ত করে না (এবং কেবলমাত্র একটি পয়েন্টার ডিভাইসের উপর নির্ভর করে) অবশ্যই কোনও টাচস্ক্রিন বৈশিষ্ট্যটি রিপোর্ট করতে হবে না এবং কেবলমাত্র অ্যান্ড্রয়েড.হার্ডওয়্যার.ফেকেটচ যদি তারা বিভাগ 7.2.5 -এ জাল স্পর্শের প্রয়োজনীয়তা পূরণ করে তবে অবশ্যই রিপোর্ট করতে হবে।

7.2.5। জাল স্পর্শ ইনপুট

ডিভাইস বাস্তবায়নগুলি যা অ্যান্ড্রয়েড.হার্ডওয়্যার.ফেকটুচের জন্য সমর্থন ঘোষণা করে:

• অবশ্যই পয়েন্টার অবস্থানের পরম এক্স এবং ওয়াই স্ক্রিন পজিশনের প্রতিবেদন করতে হবে এবং স্ক্রিনে একটি ভিজ্যুয়াল পয়েন্টার প্রদর্শন করতে হবে [ সংস্থানসমূহ, 71 ]
• অবশ্যই অ্যাকশন কোডের সাথে স্পর্শ ইভেন্টের প্রতিবেদন করতে হবে যা পয়েন্টারটিতে ঘটে যাওয়া এবং স্ক্রিনে নামার ক্ষেত্রে ঘটে এমন রাষ্ট্রীয় পরিবর্তন নির্দিষ্ট করে [ সংস্থানসমূহ, 71 ]
• স্ক্রিনে কোনও অবজেক্টে পয়েন্টারকে নীচে এবং উপরে সমর্থন করতে হবে, যা ব্যবহারকারীদের স্ক্রিনের কোনও বস্তুর উপর ট্যাপ অনুকরণ করতে দেয়
• অবশ্যই পয়েন্টার ডাউন, পয়েন্টার আপ, পয়েন্টার ডাউনকে সমর্থন করতে হবে এবং তারপরে স্ক্রিনে কোনও অবজেক্টে একই জায়গায় পয়েন্টার আপ করুন যা একটি সময় প্রান্তিকের মধ্যে, যা ব্যবহারকারীদের স্ক্রিনের কোনও বস্তুর উপর ডাবল ট্যাপ অনুকরণ করতে দেয় [ সংস্থানসমূহ,] ১ ]
• স্ক্রিনের একটি স্বেচ্ছাসেবী পয়েন্টে পয়েন্টারকে অবশ্যই সমর্থন করতে হবে, পয়েন্টারটি স্ক্রিনের অন্য কোনও স্বেচ্ছাসেবী পয়েন্টে সরানো হবে, তারপরে একটি পয়েন্টার আপ রয়েছে, যা ব্যবহারকারীদের একটি টাচ ড্র্যাগ অনুকরণ করতে দেয়
• অবশ্যই পয়েন্টারকে সমর্থন করতে হবে তারপরে ব্যবহারকারীদের দ্রুত স্ক্রিনে একটি ভিন্ন অবস্থানে এবং তারপরে স্ক্রিনে পয়েন্টার আপারটি দ্রুত সরিয়ে দেওয়ার অনুমতি দিন, যা ব্যবহারকারীদের স্ক্রিনে কোনও বস্তুকে ঝাঁপিয়ে পড়তে দেয়

ডিভাইসগুলি যা অ্যান্ড্রয়েড.হার্ডওয়্যার.ফেকট্যাচ.মুলটিটিউচ.ডিস্টিন্টিন্টের জন্য সমর্থন ঘোষণা করে সেগুলি অবশ্যই উপরের ফেকটাচের প্রয়োজনীয়তাগুলি পূরণ করতে হবে এবং অবশ্যই দুটি বা ততোধিক স্বতন্ত্র পয়েন্টার ইনপুটগুলির স্বতন্ত্র ট্র্যাকিং সমর্থন করতে হবে।

7.2.6। গেম কন্ট্রোলার সাপোর্ট

অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নগুলি নীচে তালিকাভুক্ত হিসাবে গেম কন্ট্রোলারদের জন্য বোতাম ম্যাপিংগুলিকে সমর্থন করতে হবে। উজানের অ্যান্ড্রয়েড বাস্তবায়নে গেম কন্ট্রোলারদের জন্য বাস্তবায়ন অন্তর্ভুক্ত রয়েছে যা এই প্রয়োজনীয়তাটি পূরণ করে।

7.2.6.1। বোতাম ম্যাপিং

অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নগুলি অবশ্যই নিম্নলিখিত কী ম্যাপিংগুলিকে সমর্থন করবে:

1 [ সংস্থানসমূহ, 72 ]

2 উপরের এইচআইডি ব্যবহারগুলি অবশ্যই একটি গেম প্যাড সিএ (0x01 0x0005) এর মধ্যে ঘোষণা করতে হবে।

3 এই ব্যবহারের অবশ্যই একটি যৌক্তিক সর্বনিম্ন 0, একটি যৌক্তিক সর্বোচ্চ 7, একটি শারীরিক সর্বনিম্ন 0, একটি শারীরিক সর্বোচ্চ 315, ডিগ্রিতে ইউনিট এবং 4 এর একটি প্রতিবেদনের আকার থাকতে হবে। উল্লম্ব অক্ষ থেকে দূরে; উদাহরণস্বরূপ, 0 এর একটি যৌক্তিক মান কোনও ঘূর্ণন এবং আপ বোতামটি চাপানো প্রতিনিধিত্ব করে না, যখন 1 এর একটি যৌক্তিক মান 45 ডিগ্রি এবং উপরের এবং বাম উভয় কীগুলি চাপানো হচ্ছে তার ঘূর্ণনকে উপস্থাপন করে।

4 [ সংস্থানসমূহ, 71 ]

1 [ সংস্থানসমূহ, 71 ]

7.2.7। দূরবর্তী নিয়ন্ত্রণ

অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের ব্যবহারকারীদের টিভি ইন্টারফেস অ্যাক্সেস করার অনুমতি দেওয়ার জন্য একটি রিমোট কন্ট্রোল সরবরাহ করা উচিত। রিমোট কন্ট্রোলটি কোনও শারীরিক দূরবর্তী হতে পারে বা কোনও সফ্টওয়্যার-ভিত্তিক দূরবর্তী হতে পারে যা কোনও মোবাইল ফোন বা ট্যাবলেট থেকে অ্যাক্সেসযোগ্য। রিমোট কন্ট্রোল অবশ্যই নীচে সংজ্ঞায়িত প্রয়োজনীয়তাগুলি পূরণ করতে হবে।

• অনুসন্ধান সাশ্রয়ী -ডেভিস বাস্তবায়নগুলি অবশ্যই কীকোড_স অনুসন্ধান চালাতে হবে যখন ব্যবহারকারী শারীরিক বা সফ্টওয়্যার-ভিত্তিক রিমোটে ভয়েস অনুসন্ধানকে অনুরোধ করে।
• নেভিগেশন -সমস্ত অ্যান্ড্রয়েড টেলিভিশন রিমোটগুলিতে অবশ্যই পিছনে, বাড়ি এবং ডি-প্যাড ইভেন্টগুলির জন্য বোতাম এবং সমর্থন নির্বাচন করতে হবে [ সংস্থানসমূহ, 72 ]।

7.3। সেন্সর

অ্যান্ড্রয়েডে বিভিন্ন সেন্সর প্রকারে অ্যাক্সেসের জন্য এপিআই অন্তর্ভুক্ত রয়েছে। ডিভাইসগুলি বাস্তবায়নগুলি সাধারণত এই সেন্সরগুলি বাদ দিতে পারে, যেমন নিম্নলিখিত সাবসেকশনগুলিতে সরবরাহ করা হয়। যদি কোনও ডিভাইসে কোনও নির্দিষ্ট সেন্সর টাইপ অন্তর্ভুক্ত থাকে যা তৃতীয় পক্ষের বিকাশকারীদের জন্য সংশ্লিষ্ট এপিআই থাকে তবে ডিভাইস বাস্তবায়ন অবশ্যই অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন এবং সেন্সরগুলিতে অ্যান্ড্রয়েড ওপেন সোর্স ডকুমেন্টেশন [ সংস্থানসমূহ, 73 ] এ বর্ণিত হিসাবে সেই এপিআই বাস্তবায়ন করতে হবে। উদাহরণস্বরূপ, ডিভাইস বাস্তবায়ন:

• অ্যান্ড্রয়েড.কন্টেন্ট.পিএম.প্যাকেজ ম্যানেজার শ্রেণীর প্রতি সেন্সরগুলির উপস্থিতি বা অনুপস্থিতি সঠিকভাবে প্রতিবেদন করতে হবে [ সংস্থানসমূহ, ৫৩]
• সেন্সরম্যানেজার.জেটসেন্সারলিস্ট () এবং অনুরূপ পদ্ধতির মাধ্যমে সমর্থিত সেন্সরগুলির একটি সঠিক তালিকা অবশ্যই ফিরিয়ে দিতে হবে
• অন্যান্য সমস্ত সেন্সর এপিআইয়ের জন্য যুক্তিসঙ্গত আচরণ করতে হবে (উদাহরণস্বরূপ, যখন অ্যাপ্লিকেশন শ্রোতাদের নিবন্ধ করার চেষ্টা করার সময় যথাযথ বা মিথ্যা হিসাবে যথাযথভাবে ফিরে আসে, সংশ্লিষ্ট সেন্সর উপস্থিত না থাকাকালীন সেন্সর শ্রোতাদের কল না করে; ইত্যাদি)
• অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশনে সংজ্ঞায়িত প্রতিটি সেন্সর প্রকারের জন্য প্রাসঙ্গিক আন্তর্জাতিক সিস্টেম (মেট্রিক) মানগুলি ব্যবহার করে সমস্ত সেন্সর পরিমাপের প্রতিবেদন করতে হবে [ সংস্থানসমূহ,] ৪ ]
• অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশনে সংজ্ঞায়িত হিসাবে ন্যানোসেকেন্ডগুলিতে ইভেন্টের সময়টি রিপোর্ট করা উচিত, ইভেন্টটি হওয়ার সময়টি উপস্থাপন করে এবং সিস্টেমক্লক.ইল্যাপসড্রিয়ালটাইমেনানো () ঘড়ির সাথে সিঙ্ক্রোনাইজ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি এই প্রয়োজনীয়তাগুলি পূরণ করতে খুব দৃ strongly ়ভাবে উত্সাহিত করা হয়েছে যাতে তারা ভবিষ্যতের প্ল্যাটফর্ম রিলিজগুলিতে আপগ্রেড করতে সক্ষম হবে যেখানে এটি প্রয়োজনীয় উপাদান হয়ে উঠতে পারে। সিঙ্ক্রোনাইজেশন ত্রুটিটি 100 মিলিসেকেন্ডের নীচে হওয়া উচিত [ সংস্থানসমূহ, 75 ]।

উপরের তালিকাটি ব্যাপক নয়; অ্যান্ড্রয়েড এসডিকে এবং সেন্সরগুলিতে অ্যান্ড্রয়েড ওপেন সোর্স ডকুমেন্টেশনগুলির নথিভুক্ত আচরণ [ সংস্থানসমূহ, 73 ] প্রামাণিক হিসাবে বিবেচিত হবে।

কিছু সেন্সর প্রকারগুলি যৌগিক, যার অর্থ তারা এক বা একাধিক সেন্সর দ্বারা সরবরাহিত ডেটা থেকে প্রাপ্ত হতে পারে। (উদাহরণগুলির মধ্যে ওরিয়েন্টেশন সেন্সর এবং লিনিয়ার এক্সিলারেশন সেন্সর অন্তর্ভুক্ত রয়েছে)) ডিভাইস বাস্তবায়নগুলি এই সেন্সর প্রকারগুলি প্রয়োগ করা উচিত, যখন তারা [ সংস্থানসমূহ, 76 ] এ বর্ণিত পূর্বশর্ত শারীরিক সেন্সরগুলি অন্তর্ভুক্ত করে। যদি কোনও ডিভাইস বাস্তবায়নে একটি যৌগিক সেন্সর অন্তর্ভুক্ত থাকে তবে এটি অবশ্যই সংমিশ্রণ সেন্সরগুলিতে অ্যান্ড্রয়েড ওপেন সোর্স ডকুমেন্টেশনে বর্ণিত হিসাবে সেন্সরটি প্রয়োগ করতে হবে [ সংস্থানসমূহ,] 76 ]।

কিছু অ্যান্ড্রয়েড সেন্সর একটি "অবিচ্ছিন্ন" ট্রিগার মোড সমর্থন করে, যা অবিচ্ছিন্নভাবে ডেটা ফেরত দেয় [ সংস্থানসমূহ, 77 ]। অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশন দ্বারা একটি অবিচ্ছিন্ন সেন্সর হিসাবে নির্দেশিত যে কোনও এপিআইয়ের জন্য, ডিভাইস বাস্তবায়নগুলি অবশ্যই অবিচ্ছিন্নভাবে পর্যায়ক্রমিক ডেটা নমুনাগুলি সরবরাহ করতে হবে যা 3%এর নীচে একটি জিটার থাকা উচিত, যেখানে জিটারকে একটানা টাইমস্ট্যাম্প মানগুলির পার্থক্যের স্ট্যান্ডার্ড বিচ্যুতি হিসাবে সংজ্ঞায়িত করা হয় ঘটনা

নোট করুন যে ডিভাইস বাস্তবায়নগুলি অবশ্যই নিশ্চিত করতে হবে যে সেন্সর ইভেন্ট স্ট্রিমটি অবশ্যই ডিভাইস সিপিইউকে স্থগিত অবস্থায় প্রবেশ করা বা স্থগিত রাষ্ট্র থেকে জেগে উঠতে বাধা দেবে না।

অবশেষে, যখন বেশ কয়েকটি সেন্সর সক্রিয় করা হয়, তখন বিদ্যুৎ খরচ পৃথক সেন্সরের প্রতিবেদনিত বিদ্যুৎ ব্যবহারের যোগফলের চেয়ে বেশি হওয়া উচিত নয়।

7.3.1। অ্যাক্সিলোমিটার

ডিভাইস বাস্তবায়নে একটি 3-অক্ষ অ্যাক্সিলোমিটার অন্তর্ভুক্ত করা উচিত। অ্যান্ড্রয়েড হ্যান্ডহেল্ড ডিভাইস এবং অ্যান্ড্রয়েড ওয়াচ ডিভাইসগুলি এই সেন্সরটি অন্তর্ভুক্ত করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়। যদি কোনও ডিভাইস বাস্তবায়নে 3-অক্ষের অ্যাক্সিলোমিটার অন্তর্ভুক্ত থাকে তবে এটি:

• টাইপ_একেলোমিটার সেন্সর প্রয়োগ এবং প্রতিবেদন করতে হবে [ সংস্থানসমূহ, 78 ]
• কমপক্ষে 100 হার্জেডের ফ্রিকোয়েন্সি পর্যন্ত ইভেন্টগুলি রিপোর্ট করতে সক্ষম হতে হবে এবং কমপক্ষে 200 হার্জেড পর্যন্ত ইভেন্টগুলি রিপোর্ট করা উচিত
• অ্যান্ড্রয়েড এপিআইগুলিতে বিশদ হিসাবে অ্যান্ড্রয়েড সেন্সর সমন্বয় ব্যবস্থা মেনে চলতে হবে [ সংস্থানসমূহ, 74 ]
• কোনও অক্ষের উপর গ্র্যাভিটি (4 জি) বা আরও চারগুণ পর্যন্ত ফ্রিফল থেকে পরিমাপ করতে সক্ষম হতে হবে
• কমপক্ষে 8-বিটের একটি রেজোলিউশন থাকতে হবে এবং কমপক্ষে 16-বিটের একটি রেজোলিউশন থাকতে হবে
• যদি জীবনচক্রের উপর বৈশিষ্ট্যগুলি পরিবর্তিত হয় এবং ক্ষতিপূরণ হয় এবং ডিভাইস রিবুটগুলির মধ্যে ক্ষতিপূরণ পরামিতিগুলি সংরক্ষণ করে তবে ব্যবহারের সময় ক্যালিব্রেট করা উচিত
• তাপমাত্রা ক্ষতিপূরণ দেওয়া উচিত
• অবশ্যই একটি স্ট্যান্ডার্ড বিচ্যুতি থাকতে হবে 0.05 মি/সেকেন্ডের চেয়ে বেশি নয়, যেখানে দ্রুততম নমুনা হারে কমপক্ষে 3 সেকেন্ডের সময়কালে সংগৃহীত নমুনাগুলিতে প্রতি অক্ষ ভিত্তিতে স্ট্যান্ডার্ড বিচ্যুতি গণনা করা উচিত
• অ্যান্ড্রয়েড এসডিকে ডকুমেন্টে বর্ণিত হিসাবে টাইপ_সাইনফিক্যান্ট_মোশন, টাইপ_স্টিল_ডেটেক্টর, টাইপ_স্টেপ_ডেটেক্টর, টাইপ_স্টেপ_কন্টার কমপোজিট সেন্সরগুলি প্রয়োগ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি টাইপ_সাইনিফ্যান্ট_মোশন কমপোজিট সেন্সরটি প্রয়োগ করতে খুব দৃ strongly ়ভাবে উত্সাহিত করা হয়। যদি এই সেন্সরগুলির কোনওটি প্রয়োগ করা হয় তবে ডিভাইসটি গতিশীল বা স্থিতিশীল অবস্থায় থাকলে তাদের বিদ্যুতের ব্যবহারের যোগফল সর্বদা 4 মেগাওয়াটের চেয়ে কম হওয়া উচিত এবং প্রতিটি 2 মেগাওয়াট এবং 0.5 মেগাওয়াটের নীচে হওয়া উচিত।
• যদি কোনও জাইরোস্কোপ সেন্সর অন্তর্ভুক্ত থাকে তবে অবশ্যই টাইপ_গ্র্যাভিটি এবং টাইপ_লাইনার_সিলেশন সংমিশ্রণ সেন্সরগুলি প্রয়োগ করতে হবে এবং টাইপ_গেম_রোটেশন_ভেক্টর সংমিশ্রণ সেন্সরটি প্রয়োগ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি টাইপ_গেম_রোটেশন_ভেক্টর সেন্সরটি প্রয়োগ করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়।
• যদি কোনও জাইরোস্কোপ সেন্সর এবং চৌম্বকীয় সেন্সরও অন্তর্ভুক্ত থাকে তবে একটি টাইপ_রোটেশন_ভেক্টর যৌগিক সেন্সর প্রয়োগ করা উচিত

7.3.2। ম্যাগনেটোমিটার

ডিভাইস বাস্তবায়নে একটি 3-অক্ষের চৌম্বকীয় (কম্পাস) অন্তর্ভুক্ত করা উচিত। যদি কোনও ডিভাইসে 3-অক্ষের চৌম্বকীয় অন্তর্ভুক্ত থাকে তবে এটি:

• টাইপ_ম্যাগনেটিক_ফিল্ড সেন্সরটি অবশ্যই প্রয়োগ করতে হবে এবং টাইপ_ম্যাগনেটিক_ফিল্ড_উঙ্কালিব্রেটেড সেন্সরটিও প্রয়োগ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি টাইপ_ম্যাগনেটিক_ফিল্ড_উঙ্কালিব্রেটেড সেন্সরটি প্রয়োগ করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়।
• কমপক্ষে 10 হার্জেডের ফ্রিকোয়েন্সি পর্যন্ত ইভেন্টগুলি রিপোর্ট করতে সক্ষম হতে হবে এবং কমপক্ষে 50 হার্জেড পর্যন্ত ইভেন্টগুলি রিপোর্ট করা উচিত
• অ্যান্ড্রয়েড এপিআইগুলিতে বিশদ হিসাবে অ্যান্ড্রয়েড সেন্সর সমন্বয় ব্যবস্থা মেনে চলতে হবে [ সংস্থানসমূহ, 74 ]
• স্যাচুরেটিংয়ের আগে প্রতিটি অক্ষের উপর -900 μT এবং +900 μT এর মধ্যে পরিমাপ করতে সক্ষম হতে হবে
• ডায়নামিক (বর্তমান-প্ররোচিত) এবং স্ট্যাটিক (চৌম্বক-প্ররোচিত) চৌম্বকীয় ক্ষেত্রগুলি থেকে দূরে রেখে চৌম্বকীয় (চৌম্বক-প্ররোচিত) থেকে দূরে রেখে একটি হার্ড লোহার অফসেট মান থাকতে হবে এবং 200 μT এর নীচে একটি মান থাকতে হবে
• 0.6 μT এর চেয়ে সমান বা কম রেজোলিউশন থাকতে হবে এবং 0.2 μT এর চেয়ে সমান বা ডেনসার থাকতে হবে
• তাপমাত্রা ক্ষতিপূরণ দেওয়া উচিত
• হার্ড আয়রন পক্ষপাতের অনলাইন ক্রমাঙ্কন এবং ক্ষতিপূরণ সমর্থন করতে হবে এবং ডিভাইস রিবুটগুলির মধ্যে ক্ষতিপূরণ পরামিতিগুলি সংরক্ষণ করতে হবে
• নরম লোহার ক্ষতিপূরণ প্রয়োগ করতে হবে - ডিভাইস ব্যবহারের সময় বা উত্পাদনের সময় ক্রমাঙ্কনটি করা যেতে পারে
• একটি স্ট্যান্ডার্ড বিচ্যুতি থাকা উচিত, দ্রুততম নমুনা হারে কমপক্ষে 3 সেকেন্ডের সময়কালে সংগৃহীত নমুনাগুলিতে প্রতি অক্ষ ভিত্তিতে গণনা করা উচিত, 0.5 μT এর চেয়ে বেশি নয়
• যদি কোনও অ্যাকসিলোমিটার সেন্সর এবং জাইরোস্কোপ সেন্সরও অন্তর্ভুক্ত থাকে তবে একটি টাইপ_রোটেশন_ভেক্টর যৌগিক সেন্সর প্রয়োগ করা উচিত
• কোনও অ্যাক্সিলোমিটার সেন্সরটিও প্রয়োগ করা হলে টাইপ_জিওম্যাগনেটিক_রোটেশন_ভেক্টর সেন্সরটি প্রয়োগ করতে পারে। তবে যদি প্রয়োগ করা হয় তবে এটি অবশ্যই 10 মেগাওয়াটেরও কম গ্রাস করতে হবে এবং সেন্সরটি 10 ​​হার্জেডে ব্যাচ মোডের জন্য নিবন্ধিত হলে 3 মেগাওয়াটেরও কম গ্রাস করা উচিত।

7.3.3। জিপিএস

ডিভাইস বাস্তবায়নে একটি জিপিএস রিসিভার অন্তর্ভুক্ত করা উচিত। যদি কোনও ডিভাইস বাস্তবায়নে কোনও জিপিএস রিসিভার অন্তর্ভুক্ত থাকে তবে এতে জিপিএস লক-অন সময়কে হ্রাস করার জন্য "অ্যাসিস্টড জিপিএস" কৌশলটির কিছু ফর্ম অন্তর্ভুক্ত করা উচিত।

7.3.4। জাইরোস্কোপ

ডিভাইস বাস্তবায়নে একটি জাইরোস্কোপ (কৌণিক পরিবর্তন সেন্সর) অন্তর্ভুক্ত করা উচিত। ডিভাইসগুলিতে 3-অক্ষের অ্যাক্সিলোমিটারও অন্তর্ভুক্ত না থাকলে কোনও জাইরোস্কোপ সেন্সর অন্তর্ভুক্ত করা উচিত নয়। যদি কোনও ডিভাইস বাস্তবায়নে একটি জাইরোস্কোপ অন্তর্ভুক্ত থাকে তবে এটি:

• টাইপ_গাইরোস্কোপ সেন্সরটি প্রয়োগ করতে হবে এবং টাইপ_গাইরোস্কোপ_উক্যালিব্রেটেড সেন্সরটিও প্রয়োগ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি সেন্সর_ টাইপ_গাইরোস্কোপ_অনক্যালিব্রেটেড সেন্সরটি প্রয়োগ করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়।
• ওরিয়েন্টেশন পরিমাপ করতে সক্ষম হতে হবে প্রতি সেকেন্ডে 1000 ডিগ্রি পর্যন্ত পরিবর্তন
• কমপক্ষে 100 হার্জেডের ফ্রিকোয়েন্সি পর্যন্ত ইভেন্টগুলি রিপোর্ট করতে সক্ষম হতে হবে এবং কমপক্ষে 200 হার্জেড পর্যন্ত ইভেন্টগুলি রিপোর্ট করা উচিত
• অবশ্যই 12-বিট বা তারও বেশি রেজোলিউশন থাকতে হবে এবং 16-বিট বা তারও বেশি রেজোলিউশন থাকতে হবে
• তাপমাত্রা ক্ষতিপূরণ দিতে হবে
• ব্যবহারের সময় অবশ্যই ক্যালিব্রেটেড এবং ক্ষতিপূরণ দেওয়া উচিত এবং ডিভাইস রিবুটগুলির মধ্যে ক্ষতিপূরণ পরামিতিগুলি সংরক্ষণ করুন
• প্রতি হার্জজ প্রতি 1E-7 র‌্যাড^2 / s^2 এর চেয়ে বড় কোনও বৈকল্পিক থাকতে হবে (হার্জ প্রতি বৈকল্পিক, বা র‌্যাড^2 / s)। স্যাম্পলিং হারের সাথে বৈকল্পিকটি পরিবর্তিত হওয়ার অনুমতি দেওয়া হয়, তবে অবশ্যই এই মান দ্বারা সীমাবদ্ধ থাকতে হবে। অন্য কথায়, আপনি যদি 1 হার্জেড স্যাম্পলিং হারে Gyro এর বৈকল্পিকতা পরিমাপ করেন তবে এটি 1E-7 RAD^2/s^2 এর চেয়ে বড় হওয়া উচিত নয়।
• যদি কোনও অ্যাকসিলোমিটার সেন্সর এবং চৌম্বকীয় সেন্সরও অন্তর্ভুক্ত থাকে তবে একটি টাইপ_রোটেশন_ভেক্টর যৌগিক সেন্সর প্রয়োগ করা উচিত
• যদি কোনও অ্যাক্সিলোমিটার সেন্সর অন্তর্ভুক্ত থাকে তবে অবশ্যই টাইপ_গ্র্যাভিটি এবং টাইপ_লাইনার_সিলেশন সংমিশ্রণ সেন্সরগুলি প্রয়োগ করতে হবে এবং টাইপ_গেম_রোটেশন_ভেক্টর সংমিশ্রণ সেন্সরটি প্রয়োগ করা উচিত। বিদ্যমান এবং নতুন অ্যান্ড্রয়েড ডিভাইসগুলি টাইপ_গেম_রোটেশন_ভেক্টর সেন্সরটি প্রয়োগ করতে দৃ strongly ়ভাবে উত্সাহিত করা হয়।

7.3.5। ব্যারোমিটার

ডিভাইস বাস্তবায়নে একটি ব্যারোমিটার (পরিবেষ্টিত বায়ুচাপ সেন্সর) অন্তর্ভুক্ত করা উচিত। যদি কোনও ডিভাইস বাস্তবায়নে একটি ব্যারোমিটার অন্তর্ভুক্ত থাকে তবে এটি:

• টাইপ_প্রেসার সেন্সরটি প্রয়োগ এবং প্রতিবেদন করতে হবে
• 5 হার্জেড বা তারও বেশি ইভেন্টে ইভেন্ট সরবরাহ করতে সক্ষম হতে হবে
• উচ্চতা অনুমান সক্ষম করতে অবশ্যই পর্যাপ্ত নির্ভুলতা থাকতে হবে
• তাপমাত্রা ক্ষতিপূরণ দিতে হবে

7.3.6। থার্মোমিটার

ডিভাইস বাস্তবায়নে একটি পরিবেষ্টিত থার্মোমিটার (তাপমাত্রা সেন্সর) অন্তর্ভুক্ত থাকতে পারে। If present, it MUST be defined as SENSOR_TYPE_AMBIENT_TEMPERATURE and it MUST measure the ambient (room) temperature in degrees Celsius.

Device implementations MAY but SHOULD NOT include a CPU temperature sensor. If present, it MUST be defined as SENSOR_TYPE_TEMPERATURE, it MUST measure the temperature of the device CPU, and it MUST NOT measure any other temperature. Note the SENSOR_TYPE_TEMPERATURE sensor type was deprecated in Android 4.0.

7.3.7। ফটোমিটার

Device implementations MAY include a photometer (ambient light sensor).

7.3.8। নৈকট্য সেন্সর

ডিভাইস বাস্তবায়নে একটি প্রক্সিমিটি সেন্সর অন্তর্ভুক্ত থাকতে পারে। Devices that can make a voice call and indicate any value other than PHONE_TYPE_NONE in getPhoneType SHOULD include a proximity sensor. If a device implementation does include a proximity sensor, it:

• MUST measure the proximity of an object in the same direction as the screen. এটি হ'ল, প্রক্সিমিটি সেন্সরটি অবশ্যই স্ক্রিনের কাছাকাছি অবজেক্টগুলি সনাক্ত করতে ওরিয়েন্টেড করতে হবে, কারণ এই সেন্সর ধরণের প্রাথমিক উদ্দেশ্যটি ব্যবহারকারীর দ্বারা ব্যবহৃত কোনও ফোন সনাক্ত করা। যদি কোনও ডিভাইস বাস্তবায়নে অন্য কোনও ওরিয়েন্টেশন সহ একটি প্রক্সিমিটি সেন্সর অন্তর্ভুক্ত থাকে তবে এটি অবশ্যই এই এপিআইয়ের মাধ্যমে অ্যাক্সেসযোগ্য হওয়া উচিত নয়।
• MUST have 1-bit of accuracy or more

7.4। ডেটা সংযোগ

7.4.1। টেলিফোনি

"Telephony" as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages via a GSM or CDMA network. While these voice calls may or may not be packet-switched, they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words, the Android "telephony" functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages MUST NOT report the android.hardware.telephony feature or any subfeatures, regardless of whether they use a cellular network for data connectivity.

Android MAY be used on devices that do not include telephony hardware. That is, Android is compatible with devices that are not phones. তবে, যদি কোনও ডিভাইস বাস্তবায়নে জিএসএম বা সিডিএমএ টেলিফোনি অন্তর্ভুক্ত থাকে তবে এটি অবশ্যই সেই প্রযুক্তির জন্য এপিআইয়ের জন্য সম্পূর্ণ সমর্থন প্রয়োগ করতে হবে। টেলিফোনি হার্ডওয়্যার অন্তর্ভুক্ত না করে ডিভাইস বাস্তবায়নগুলিতে অবশ্যই সম্পূর্ণ এপিআইগুলিকে নো-অপ হিসাবে প্রয়োগ করতে হবে।

7.4.2। IEEE 802.11 (ওয়াই-ফাই)

Android Television device implementations MUST include support for one or more forms of 802.11 (b/g/a/n, etc.) and other types of Android device implementation SHOULD include support for one or more forms of 802.11. If a device implementation does include support for 802.11 and exposes the functionality to a third-party application, it MUST implement the corresponding Android API and:

• MUST report the hardware feature flag android.hardware.wifi
• MUST implement the multicast API as described in the SDK documentation [ Resources, 79 ]
• MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets (224.0.0.251) at any time of operation including when the screen is not in an active state

7.4.2.1। ওয়াই - ফাই ডিরেক্ট

Device implementations SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer). If a device implementation does include support for Wi-Fi Direct, it MUST implement the corresponding Android API as described in the SDK documentation [ Resources, 80 ]. If a device implementation includes support for Wi-Fi Direct, then it:

• MUST report the hardware feature android.hardware.wifi.direct
• MUST support regular Wi-Fi operation
• SHOULD support concurrent Wi-Fi and Wi-Fi Direct operation

7.4.2.2। Wi-Fi টানেলযুক্ত ডাইরেক্ট লিঙ্ক সেটআপ

Android Television device implementations MUST include support for Wi-Fi Tunneled Direct Link Setup (TDLS) and other types of Android device implementations SHOULD include support for Wi-Fi TDLS as described in the Android SDK Documentation [ Resources, 81 ]. If a device implementation does include support for TDLS and TDLS is enabled by the WiFiManager API, the device:

• SHOULD use TDLS only when it is possible AND beneficial
• SHOULD have some heuristic and NOT use TDLS when its performance might be worse than going through the Wi-Fi access point

7.4.3। ব্লুটুথ

Android includes support for Bluetooth and Bluetooth Low Energy [ Resources, 82 ]. Device implementations that include support for Bluetooth and Bluetooth Low Energy MUST declare the relevant platform features (android.hardware.bluetooth and android.hardware.bluetooth_le respectively) and implement the platform APIs. Device implementations SHOULD implement relevant Bluetooth profiles such as A2DP, AVCP, OBEX, etc. as appropriate for the device. Android Television device implementations MUST support Bluetooth and Bluetooth LE.

Device implementations including support for Bluetooth Low Energy:

• MUST declare the hardware feature android.hardware.bluetooth_le
• MUST enable the GATT (generic attribute profile) based Bluetooth APIs as described in the SDK documentation and [ Resources, 82 ]
• SHOULD support offloading of the filtering logic to the bluetooth chipset when implementing the ScanFilter API [ Resources, 83 ], and MUST report the correct value of where the filtering logic is implemented whenever queried via the android.bluetooth.BluetoothAdapter.isOffloadedFilteringSupported() method
• SHOULD support offloading of the batched scanning to the bluetooth chipset, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapater.isOffloadedScanBatchingSupported() method.
• SHOULD support multi advertisement with at least 4 slots, but if not supported, MUST report 'false' whenever queried via the android.bluetooth.BluetoothAdapter.isMultipleAdvertisementSupported() method

7.4.4। নিয়ার-ফিল্ড কমিউনিকেশনস

ডিভাইস বাস্তবায়নে নিকট-ক্ষেত্র যোগাযোগের (এনএফসি) জন্য একটি ট্রান্সসিভার এবং সম্পর্কিত হার্ডওয়্যার অন্তর্ভুক্ত করা উচিত। If a device implementation does include NFC hardware and plans to make it available to third-party apps, then it:

• MUST report the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53 ]
• নিম্নলিখিত এনএফসি স্ট্যান্ডার্ডগুলির মাধ্যমে এনডিইএফ বার্তাগুলি পড়তে এবং লিখতে সক্ষম হতে হবে:
  • নিম্নলিখিত এনএফসি স্ট্যান্ডার্ডগুলির মাধ্যমে একটি এনএফসি ফোরামের পাঠক/লেখক (এনএফসি ফোরাম টেকনিক্যাল স্পেসিফিকেশন এনএফসিফোরাম-টিএস-ডিজিটালপ্রোটোকল -1.0 দ্বারা সংজ্ঞায়িত) হিসাবে অভিনয় করতে সক্ষম হতে হবে:
    • এনএফসিএ (আইএসও 14443-3 এ)
    • এনএফসিবি (আইএসও 14443-3 বি)
    • এনএফসিএফ (জেআইএস 6319-4)
    • আইসোডেপ (আইএসও 14443-4)
    • এনএফসি ফোরাম ট্যাগ প্রকার 1, 2, 3, 4 (এনএফসি ফোরাম দ্বারা সংজ্ঞায়িত)
  • নিম্নলিখিত এনএফসি স্ট্যান্ডার্ডগুলির মাধ্যমে এনডিইএফ বার্তাগুলি পড়তে এবং লিখতে সক্ষম হওয়া উচিত। Note that while the NFC standards below are stated as SHOULD, the Compatibility Definition for a future version is planned to change these to MUST. These standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
    • এনএফসিভি (আইএসও 15693)
  • নিম্নলিখিত পিয়ার-টু-পিয়ার স্ট্যান্ডার্ড এবং প্রোটোকলের মাধ্যমে ডেটা প্রেরণ এবং গ্রহণ করতে সক্ষম হতে হবে:
    • আইএসও 18092
    • এলএলসিপি 1.0 (এনএফসি ফোরাম দ্বারা সংজ্ঞায়িত)
    • এসডিপি 1.0 (এনএফসি ফোরাম দ্বারা সংজ্ঞায়িত)
    • NDEF Push Protocol [ Resources, 84 ]
    • এসএনইপি 1.0 (এনএফসি ফোরাম দ্বারা সংজ্ঞায়িত)
  • MUST include support for Android Beam [ Resources, 85 ]:
    • এসএনইপি ডিফল্ট সার্ভারটি প্রয়োগ করতে হবে। ডিফল্ট এসএনইপি সার্ভার দ্বারা প্রাপ্ত বৈধ এনডিইএফ বার্তাগুলি অবশ্যই android.nfc.action_ndef_discovered অভিপ্রায় ব্যবহার করে অ্যাপ্লিকেশনগুলিতে প্রেরণ করতে হবে। সেটিংসে অ্যান্ড্রয়েড মরীচি অক্ষম করা অবশ্যই আগত এনডিইএফ বার্তা প্রেরণ অক্ষম করবে না।
    • MUST honor the android.settings.NFCSHARING_SETTINGS intent to show NFC sharing settings [ Resources, 86 ]
    • অবশ্যই এনপিপি সার্ভারটি প্রয়োগ করতে হবে। এনপিপি সার্ভার দ্বারা প্রাপ্ত বার্তাগুলি অবশ্যই এসএনইপি ডিফল্ট সার্ভারের মতো একইভাবে প্রক্রিয়া করা উচিত।
    • অ্যান্ড্রয়েড বিম সক্ষম করা থাকাকালীন একটি এসএনইপি ক্লায়েন্ট বাস্তবায়ন করতে হবে এবং ডিফল্ট এসএনইপি সার্ভারে আউটবাউন্ড পি 2 পি এনডিইএফ প্রেরণের চেষ্টা করতে হবে। যদি কোনও ডিফল্ট এসএনইপি সার্ভার না পাওয়া যায় তবে ক্লায়েন্টকে অবশ্যই একটি এনপিপি সার্ভারে প্রেরণের চেষ্টা করতে হবে।
    • MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage, and android.nfc.NfcAdapter.setNdefPushMessageCallback, and android.nfc.NfcAdapter.enableForegroundNdefPush
    • SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages
    • SHOULD enable Android Beam by default and MUST be able to send and receive using Android Beam, even when another proprietary NFC P2p mode is turned on
    • MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile. Device implementations MUST support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris, by implementing the "Connection Handover version 1.2" [ Resources, 87 ] and "Bluetooth Secure Simple Pairing Using NFC version 1.0" [ Resources, 88 ] specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name "urn:nfc:sn:handover" for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
  • MUST poll for all supported technologies while in NFC discovery mode
  • SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked

(দ্রষ্টব্য যে সর্বজনীনভাবে উপলভ্য লিঙ্কগুলি জেআইএস, আইএসও এবং এনএফসি ফোরামের নির্দিষ্টকরণের জন্য উপরে উদ্ধৃত নয়))

Android 5.0 includes support for NFC Host Card Emulation (HCE) mode. If a device implementation does include an NFC controller capable of HCE and Application ID (AID) routing, then it:

• MUST report the android.hardware.nfc.hce feature constant
• MUST support NFC HCE APIs as defined in the Android SDK [ Resources, 10 ]

অতিরিক্তভাবে, ডিভাইস বাস্তবায়নে নিম্নলিখিত এমআইএফএআর প্রযুক্তির জন্য পাঠক/লেখক সমর্থন অন্তর্ভুক্ত থাকতে পারে।

• MIFARE ক্লাসিক
• MIFARE আল্ট্রালাইট
• NDEF on MIFARE Classic

Note that Android includes APIs for these MIFARE types. যদি কোনও ডিভাইস বাস্তবায়ন পাঠক/লেখকের ভূমিকায় মিফারে সমর্থন করে তবে এটি:

• অ্যান্ড্রয়েড এসডিকে নথিভুক্ত হিসাবে সংশ্লিষ্ট অ্যান্ড্রয়েড এপিআইগুলি প্রয়োগ করতে হবে
• MUST report the feature com.nxp.mifare from the android.content.pm.PackageManager.hasSystemFeature() meth od [Resources, 53] . Note that this is not a standard Android feature and as such does not appear as a constant on the PackageManager class.
• সংশ্লিষ্ট অ্যান্ড্রয়েড এপিআইগুলি প্রয়োগ করতে হবে না বা com.nxp.mifare বৈশিষ্ট্যটি রিপোর্ট করতে হবে না যদি না এটি এই বিভাগে বর্ণিত হিসাবে সাধারণ এনএফসি সমর্থনও প্রয়োগ করে

If a device implementation does not include NFC hardware, it MUST NOT declare the android.hardware.nfc feature from the android.content.pm.PackageManager.hasSystemFeature() method [ Resources, 53] , and MUST implement the Android NFC API as a no-op.

অ্যান্ড্রয়েড.এনএফসি.এনডিএফএমএসেজেজ এবং অ্যান্ড্রয়েড.এনএফসি.এনএফসি.এনএফসি.এনএফসি.এনএফসি.এনডিএফসিআরডি একটি প্রোটোকল-স্বতন্ত্র ডেটা উপস্থাপনা ফর্ম্যাট উপস্থাপন করে, ডিভাইস বাস্তবায়নগুলি অবশ্যই এই এপিআইগুলি প্রয়োগ করতে হবে এমনকি যদি তারা এনএফসির পক্ষে সমর্থন অন্তর্ভুক্ত না করে বা Android.hardware.nfc বৈশিষ্ট্যটি ঘোষণা করে না।

7.4.5। ন্যূনতম নেটওয়ার্ক ক্ষমতা

ডিভাইস বাস্তবায়নে অবশ্যই ডেটা নেটওয়ার্কিংয়ের এক বা একাধিক ফর্মের জন্য সমর্থন অন্তর্ভুক্ত থাকতে হবে। বিশেষত, ডিভাইস বাস্তবায়নে অবশ্যই 200 কিবিট/সেকেন্ড বা তার চেয়ে বেশি সক্ষম কমপক্ষে একটি ডেটা স্ট্যান্ডার্ডের জন্য সমর্থন অন্তর্ভুক্ত থাকতে হবে। Examples of technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 802.11g, Ethernet, Bluetooth PAN, etc.

Device implementations where a physical networking standard (such as Ethernet) is the primary data connection SHOULD also include support for at least one common wireless data standard, such as 802.11 (Wi-Fi).

ডিভাইসগুলি ডেটা সংযোগের একাধিক ফর্ম প্রয়োগ করতে পারে।

7.4.6। সিঙ্ক সেটিংস

Device implementations MUST have the master auto-sync setting on by default so that the method getMasterSyncAutomatically() returns "true" [ Resources, 89 ].

7.5। ক্যামেরা

Device implementations SHOULD include a rear-facing camera and MAY include a front-facing camera. একটি রিয়ার-ফেসিং ক্যামেরা হ'ল একটি ক্যামেরা যা প্রদর্শনের বিপরীতে ডিভাইসের পাশে অবস্থিত; এটি হ'ল এটি ডিভাইসের দূরবর্তী দিকে একটি traditional তিহ্যবাহী ক্যামেরার মতো দৃশ্যের চিত্র দেয়। একটি সামনের মুখী ক্যামেরা হ'ল একটি ক্যামেরা যা ডিভাইসের একই পাশে প্রদর্শিত হয়; এটি হ'ল, একটি ক্যামেরা সাধারণত ব্যবহারকারীকে চিত্রিত করতে ব্যবহৃত হয় যেমন ভিডিও কনফারেন্সিং এবং অনুরূপ অ্যাপ্লিকেশনগুলির জন্য।

If a device implementation includes at least one camera, it SHOULD be possible for an application to simultaneously allocate 3 bitmaps equal to the size of the images produced by the largest-resolution camera sensor on the device.

7.5.1। রিয়ার-ফেসিং ক্যামেরা

ডিভাইস বাস্তবায়নে একটি রিয়ার-ফেসিং ক্যামেরা অন্তর্ভুক্ত করা উচিত। If a device implementation includes at least one rear-facing camera, it:

• MUST report the feature flag android.hardware.camera and android.hardware.camera.any
• কমপক্ষে 2 মেগাপিক্সেলের একটি রেজোলিউশন থাকতে হবে
• SHOULD have either hardware auto-focus or software auto-focus implemented in the camera driver (transparent to application software)
• ফিক্স-ফোকাস বা ইডিএফ (ক্ষেত্রের বর্ধিত গভীরতা) হার্ডওয়্যার থাকতে পারে
• একটি ফ্ল্যাশ অন্তর্ভুক্ত থাকতে পারে। যদি ক্যামেরাটিতে একটি ফ্ল্যাশ অন্তর্ভুক্ত থাকে তবে Android.hardware.camera.previewcallback উদাহরণটি ক্যামেরা পূর্বরূপ পৃষ্ঠে নিবন্ধিত করা হয়েছে, যদি না অ্যাপ্লিকেশনটি স্পষ্টভাবে ফ্ল্যাশ_মোড_আউটো বা ফ্ল্যাশ_আউটো বা ফ্ল্যাশ_মোড_অন বৈশিষ্ট্যগুলি সক্ষম করে ফ্ল্যাশটি সক্ষম করে না থাকে তবে ফ্ল্যাশ ল্যাম্পটি আলোকিত করা উচিত নয় ক্যামেরা.প্যারামিটার অবজেক্ট। Note that this constraint does not apply to the device's built-in system camera application, but only to third-party applications using Camera.PreviewCallback.

7.5.2। ফ্রন্ট-ফেসিং ক্যামেরা

ডিভাইস বাস্তবায়নে একটি সামনের মুখোমুখি ক্যামেরা অন্তর্ভুক্ত থাকতে পারে। If a device implementation includes at least one front-facing camera, it:

• MUST report the feature flag android.hardware.camera.any and android.hardware.camera.front
• MUST have a resolution of at least VGA (640x480 pixels)
• ক্যামেরা এপিআইয়ের জন্য ডিফল্ট হিসাবে কোনও সামনের মুখোমুখি ক্যামেরা ব্যবহার করা উচিত নয়। The camera API in Android has specific support for front-facing cameras and device implementations MUST NOT configure the API to to treat a front-facing camera as the default rear-facing camera, even if it is the only camera on the device.
• MAY include features (such as auto-focus, flash, etc.) available to rear-facing cameras as described in section 7.5.1
• নিম্নলিখিত হিসাবে কোনও অ্যাপ দ্বারা প্রদর্শিত স্ট্রিমটি অনুভূমিকভাবে প্রতিফলিত করতে হবে (অর্থাত্ আয়না):
  • যদি ডিভাইস বাস্তবায়ন ব্যবহারকারী দ্বারা ঘোরানো সক্ষম হয় (যেমন স্বয়ংক্রিয়ভাবে একটি অ্যাক্সিলোমিটারের মাধ্যমে বা ম্যানুয়ালি ব্যবহারকারী ইনপুট মাধ্যমে), ক্যামেরার পূর্বরূপ অবশ্যই ডিভাইসের বর্তমান ওরিয়েন্টেশনের সাথে তুলনামূলকভাবে মিররযুক্ত হতে হবে।
  • If the current application has explicitly requested that the Camera display be rotated via a call to the android.hardware.Camera.setDisplayOrientation()[ Resources, 90 ] method, the camera preview MUST be mirrored horizontally relative to the orientation specified by the application.
  • অন্যথায়, পূর্বরূপটি অবশ্যই ডিভাইসের ডিফল্ট অনুভূমিক অক্ষের সাথে মিরর করা উচিত।
• পোস্টভিউ দ্বারা প্রদর্শিত চিত্রটি অবশ্যই ক্যামেরা পূর্বরূপ চিত্র স্ট্রিমের মতো একইভাবে মিরর করতে হবে। If the device implementation does not support postview, this requirement obviously does not apply.
• MUST NOT mirror the final captured still image or video streams returned to application callbacks or committed to media storage

7.5.3। বাহ্যিক ক্যামেরা

Device implementations with USB host mode MAY include support for an external camera that connects to the USB port. If a device includes support for an external camera, it:

• MUST declare the platform feature android.hardware.camera.external and android.hardware camera.any
• MUST support USB Video Class (UVC 1.0 or higher)
• MAY support multiple cameras

Video compression (such as MJPEG) support is RECOMMENDED to enable transfer of high-quality unencoded streams (ie raw or independently compressed picture streams). Camera-based video encoding MAY be supported. If so, a simultaneous unencoded/ MJPEG stream (QVGA or greater resolution) MUST be accessible to the device implementation.

7.5.4। ক্যামেরা API আচরণ

Android includes two API packages to access the camera, the newer android.hardware.camera2 API expose lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more.

The older API package, android.hardware.Camera, is marked as deprecated in Android 5.0 but as it should still be available for apps to use Android device implementations MUST ensure the continued support of the API as described in this section and in the Android SDK .

Device implementations MUST implement the following behaviors for the camera-related APIs, for all available cameras:

• If an application has never called android.hardware.Camera.Parameters.setPreviewFormat(int), then the device MUST use android.hardware.PixelFormat.YCbCr_420_SP for preview data provided to application callbacks.
• যদি কোনও অ্যাপ্লিকেশন একটি android.hardware.camera.previewcallback উদাহরণ নিবন্ধন করে এবং সিস্টেমটি অনপরিভিউফ্রেম () পদ্ধতিটি কল করে যখন পূর্বরূপ ফর্ম্যাটটি ycbcr_420_sp হয়, তবে বাইট [] এর ডেটা আরও এনভি 21 এনকোডিং ফর্ম্যাটে যেতে হবে। অর্থাৎ, এনভি 21 অবশ্যই ডিফল্ট হতে হবে।
• For android.hardware.Camera, device implementations MUST support the YV12 format (as denoted by the android.graphics.ImageFormat.YV12 constant) for camera previews for both front- and rear-facing cameras. (The hardware video encoder and camera may use any native pixel format, but the device implementation MUST support conversion to YV12.)
• For android.hardware.camera2, device implementations must support the android.hardware.ImageFormat.YUV_420_888 and android.hardware.ImageFormat.JPEG formats as outputs through the android.media.ImageReader API.

Device implementations MUST still implement the full Camera API included in the Android SDK documentation [ Resources, 91 ], regardless of whether the device includes hardware autofocus or other capabilities. উদাহরণস্বরূপ, অটোফোকাসের অভাবযুক্ত ক্যামেরাগুলি এখনও কোনও নিবন্ধিত android.hardware.camera.autofocuscallback উদাহরণ কল করতে হবে (যদিও এটি একটি অ-অটোফোকাস ক্যামেরার সাথে কোনও প্রাসঙ্গিকতা নেই)) নোট করুন যে এটি সামনের মুখী ক্যামেরায় প্রযোজ্য; উদাহরণস্বরূপ, যদিও বেশিরভাগ সামনের মুখোমুখি ক্যামেরা অটোফোকাসকে সমর্থন করে না, এপিআই কলব্যাকগুলি এখনও বর্ণিত হিসাবে "নকল" হতে হবে।

ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড.হার্ডওয়্যার.কামেরা.প্যারামিটার ক্লাসে ধ্রুবক হিসাবে সংজ্ঞায়িত প্রতিটি প্যারামিটারের নামটি স্বীকৃতি দিতে হবে এবং সম্মান করতে হবে, যদি অন্তর্নিহিত হার্ডওয়্যার বৈশিষ্ট্যটিকে সমর্থন করে। যদি ডিভাইস হার্ডওয়্যার কোনও বৈশিষ্ট্য সমর্থন না করে তবে এপিআই অবশ্যই নথিভুক্ত হিসাবে আচরণ করতে হবে। Conversely, device implementations MUST NOT honor or recognize string constants passed to the android.hardware.Camera.setParameters() method other than those documented as constants on the android.hardware.Camera.Parameters. এটি হ'ল, হার্ডওয়্যারটি অনুমতি দিলে ডিভাইস বাস্তবায়নগুলি অবশ্যই সমস্ত স্ট্যান্ডার্ড ক্যামেরা পরামিতিগুলিকে সমর্থন করবে এবং কাস্টম ক্যামেরা প্যারামিটারের প্রকারগুলি সমর্থন করবে না। For instance, device implementations that support image capture using high dynamic range (HDR) imaging techniques MUST support camera parameter Camera.SCENE_MODE_HDR [ Resources, 92 ].

Because not all device implementations can fully support all the features of the android.hardware.camera2 API, device implementations MUST report the proper level of support with the android.info.supportedHardwareLevel property as described in the Android SDK [ Resources, 93] and report the appropriate framework feature flags [ Resources, 94] .

Device implementations MUST also declare its Individual camera capabilities of android.hardware.camera2 via the android.request.availableCapabilities property and declare the appropriate feature flags [ Resources, 94] ; a device must define the feature flag if any of its attached camera devices supports the feature.

ডিভাইস বাস্তবায়নগুলি অবশ্যই ক্যামেরাটি সম্প্রচার করতে হবে action

ডিভাইস বাস্তবায়নগুলি অবশ্যই ক্যামেরাটি সম্প্রচার করতে হবে action

7.5.5। ক্যামেরা ওরিয়েন্টেশন

সামনের এবং পিছনের মুখী উভয় ক্যামেরা, যদি উপস্থিত থাকে তবে অবশ্যই ওরিয়েন্টেড করা উচিত যাতে ক্যামেরার দীর্ঘ মাত্রা পর্দার দীর্ঘ মাত্রার সাথে একত্রিত হয়। এটি হ'ল, যখন ডিভাইসটি ল্যান্ডস্কেপ ওরিয়েন্টেশনে রাখা হয়, ক্যামেরাগুলি অবশ্যই ল্যান্ডস্কেপ ওরিয়েন্টেশনে চিত্রগুলি ক্যাপচার করতে হবে। এটি ডিভাইসের প্রাকৃতিক দৃষ্টিভঙ্গি নির্বিশেষে প্রযোজ্য; এটি হ'ল এটি ল্যান্ডস্কেপ-প্রাথমিক ডিভাইসের পাশাপাশি প্রতিকৃতি-প্রাথমিক ডিভাইসগুলির ক্ষেত্রে প্রযোজ্য।

7.6। মেমরি এবং স্টোরেজ

7.6.1। ন্যূনতম মেমরি এবং স্টোরেজ

The memory available to the kernel and userspace on device implementations MUST be at least equal or larger than the minimum values specified by the following table. (See section 7.1.1 for screen size and density definitions.)

The minimum memory values MUST be in addition to any memory space already dedicated to hardware components such as radio, video, and so on that is not under the kernel's control.

Android Television devices MUST have at least 5GB and other device implementations MUST have at least 1.5GB of non-volatile storage available for application private data. That is, the /data partition MUST be at least 5GB for Android Television devices and at least 1.5GB for other device implementations. Device implementations that run Android are very strongly encouraged to have at least 3GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

The Android APIs include a Download Manager that applications MAY use to download data files [ Resources, 95 ]. ডাউনলোড ম্যানেজারের ডিভাইস বাস্তবায়ন অবশ্যই কমপক্ষে 100MB এর পৃথক ফাইলগুলি ডিফল্ট "ক্যাশে" অবস্থানে ডাউনলোড করতে সক্ষম হতে হবে।

7.6.2। অ্যাপ্লিকেশন শেয়ার্ড স্টোরেজ

Device implementations MUST offer shared storage for applications also often referred as “shared external storage”.

ডিভাইস বাস্তবায়নগুলি অবশ্যই "বাক্সের বাইরে" ডিফল্টরূপে মাউন্ট করা ভাগ করা স্টোরেজ দিয়ে কনফিগার করতে হবে। If the shared storage is not mounted on the Linux path /sdcard, then the device MUST include a Linux symbolic link from /sdcard to the actual mount point.

Device implementations MAY have hardware for user-accessible removable storage, such as a Secure Digital (SD) card slot. If this slot is used to satisfy the shared storage requirement, the device implementation:

• MUST implement a toast or pop-up user interface warning the user when there is no SD card
• MUST include a FAT-formatted SD card 1GB in size or larger OR show on the box and other material available at time of purchase that the SD card has to be separately purchased
• MUST mount the SD card by default

Alternatively, device implementations MAY allocate internal (non-removable) storage as shared storage for apps as included in the upstream Android Open Source Project; device implementations SHOULD use this configuration and software implementation. If a device implementation uses internal (non-removable) storage to satisfy the shared storage requirement, that storage MUST be 1GB in size or larger and mounted on /sdcard (or /sdcard MUST be a symbolic link to the physical location if it is mounted অন্যত্র)।

ডিভাইস বাস্তবায়নগুলি অবশ্যই এই ভাগ করা স্টোরেজটিতে অ্যান্ড্রয়েড.আরমিশন.আরাইট_এক্সটার্নাল_স্টোরেজের অনুমতি নথিভুক্ত হিসাবে কার্যকর করতে হবে। ভাগ করা স্টোরেজ অন্যথায় সেই অনুমতি প্রাপ্ত কোনও অ্যাপ্লিকেশন দ্বারা অবশ্যই লিখিত হতে হবে।

Device implementations that include multiple shared storage paths (such as both an SD card slot and shared internal storage) MUST allow only pre-installed & privileged Android applications with the WRITE_EXTERNAL_STORAGE permission to write to the secondary external storage, except for the package-specific directories on the secondary external storage, but SHOULD expose content from both storage paths transparently through Android's media scanner service and android.provider.MediaStore.

ব্যবহৃত ভাগ করা স্টোরেজের ফর্ম নির্বিশেষে, ডিভাইস বাস্তবায়নগুলি অবশ্যই ইউএসবি গণ স্টোরেজ (ইউএমএস) বা মিডিয়া ট্রান্সফার প্রোটোকল (এমটিপি) এর মতো হোস্ট কম্পিউটার থেকে ভাগ করা স্টোরেজের সামগ্রীগুলি অ্যাক্সেস করার জন্য কিছু প্রক্রিয়া সরবরাহ করতে হবে। ডিভাইস বাস্তবায়নগুলি ইউএসবি ভর স্টোরেজ ব্যবহার করতে পারে তবে মিডিয়া ট্রান্সফার প্রোটোকল ব্যবহার করা উচিত। If the device implementation supports Media Transfer Protocol, it:

• SHOULD be compatible with the reference Android MTP host, Android File Transfer [ Resources, 96 ]
• SHOULD report a USB device class of 0x00
• SHOULD report a USB interface name of 'MTP'

যদি ডিভাইস বাস্তবায়নের ইউএসবি পোর্টগুলির অভাব থাকে তবে এটি অবশ্যই একটি হোস্ট কম্পিউটার সরবরাহ করতে হবে অন্য কোনও উপায়ে যেমন একটি নেটওয়ার্ক ফাইল সিস্টেম দ্বারা ভাগ করা স্টোরেজের সামগ্রীতে অ্যাক্সেস সহ।

7.7। ইউএসবি

Device implementations SHOULD support USB peripheral mode and SHOULD support USB host mode.

If a device implementation includes a USB port supporting peripheral mode:

• The port MUST be connectable to a USB host that has a standard type-A or type -C USB port.
• The port SHOULD use micro-B, micro-AB or Type-C USB form factor. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• The port SHOULD either be located on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including home screen), so that the display draws correctly when the device is oriented with the port at bottom. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to future platform releases.
• It SHOULD implement the Android Open Accessory (AOA) API and specification as documented in the Android SDK documentation, and if it is an Android Handheld device it MUST implement the AOA API. Device implementations implementing the AOA specification:
  • MUST declare support for the hardware feature android.hardware.usb.accessory [ Resources, 97 ]
  • MUST implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• It SHOULD implement support to draw 1.5 A current during HS chirp and traffic as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ]. Existing and new Android devices are STRONGLY RECOMMENDED to meet these requirements so they will be able to upgrade to the future platform releases.
• The value of iSerialNumber in USB standard device descriptor MUST be equal to the value of android.os.Build.SERIAL.

If a device implementation includes a USB port supporting host mode, it:

• SHOULD use a type-C USB port, if the device implementation supports USB 3.1
• MAY use a non-standard port form factor, but if so MUST ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• MAY use a micro-AB USB port, but if so SHOULD ship with a cable or cables adapting the port to a standard type-A or type-C USB port
• is very strongly RECOMMENDED to implement the USB audio class as documented in the Android SDK documentation [ Resources, 98 ]
• MUST implement the Android USB host API as documented in the Android SDK, and MUST declare support for the hardware feature android.hardware.usb.host [ Resources, 100 ]
• SHOULD support the Charging Downstream Port output current range of 1.5 A ~ 5 A as specified in the USB Battery Charging Specification, Revision 1.2 [ Resources, 99 ].

7.8। শ্রুতি

7.8.1। মাইক্রোফোন

ডিভাইস বাস্তবায়ন একটি মাইক্রোফোন বাদ দিতে পারে। However, if a device implementation omits a microphone, it MUST NOT report the android.hardware.microphone feature constant, and MUST implement the audio recording API at least as no-ops, per section 7 . বিপরীতে, ডিভাইস বাস্তবায়ন যা একটি মাইক্রোফোনের অধিকারী:

• অ্যান্ড্রয়েড.হার্ডওয়্যার.মাইক্রোফোন বৈশিষ্ট্য ধ্রুবক অবশ্যই রিপোর্ট করতে হবে
• MUST meet the audio recording requirements in section 5.4
• MUST meet the audio latency requirements in section 5.6

7.8.2। অডিও আউটপুট

Device implementations including a speaker or with an audio/multimedia output port for an audio output peripheral as a headset or an external speaker:

• MUST report the android.hardware.audio.output feature constant
• MUST meet the audio playback requirements in section 5.5
• MUST meet the audio latency requirements in section 5.6

Conversely, if a device implementation does not include a speaker or audio output port, it MUST NOT report the android.hardware.audio output feature, and MUST implement the Audio Output related APIs as no-ops at least.

Android Watch device implementation MAY but SHOULD NOT have audio output, but other types of Android device implementations MUST have an audio output and declare android.hardware.audio.output.

7.8.2.1। এনালগ অডিও পোর্ট

In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem [ Resources, 101 ], if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:

• MUST support audio playback to stereo headphones and stereo headsets with a microphone, and SHOULD support audio recording from stereo headsets with a microphone
• MUST support TRRS audio plugs with the CTIA pin-out order, and SHOULD support audio plugs with the OMTP pin-out order
• MUST support the detection of microphone on the plugged in audio accessory, if the device implementation supports a microphone, and broadcast the android.intent.action.HEADSET_PLUG with the extra value microphone set as 1
• SHOULD support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 70 ohm or less : KEYCODE_HEADSETHOOK
  • 210–290 Ohm : KEYCODE_VOLUME_UP
  • 360–680 Ohm : KEYCODE_VOLUME_DOWN
• SHOULD support the detection and mapping to the keycode for the following range of equivalent impedance between the microphone and ground conductors on the audio plug:
  • 110–180 Ohm: KEYCODE_VOICE_ASSIST
• MUST trigger ACTION_HEADSET_PLUG upon a plug insert, but only after all contacts on plug are touching their relevant segments on the jack
• MUST be capable of driving at least 150mV +/- 10% of output voltage on a 32 Ohm speaker impedance
• MUST have a microphone bias voltage between 1.8V ~ 2.9V

8. কর্মক্ষমতা সামঞ্জস্য

Some minimum performance criterias are critical to the user experience and impacts the baseline assumptions developers would have when developing an app. Android Watch devices SHOULD and other type of device implementations MUST meet the following criteria:

8.1। ব্যবহারকারীর অভিজ্ঞতার ধারাবাহিকতা

Device implementations MUST provide a smooth user interface by ensuring a consistent frame rate and response times for applications and games. Device implementations MUST meet the following requirements:

• Consistent frame latency Inconsistent frame latency or a delay to render frames MUST NOT happen more often than 5 frames in a second, and SHOULD be below 1 frames in a second.
• User interface latency Device implementations MUST ensure low latency user experience by scrolling a list of 10K list entries as defined by the Android Compatibility Test Suite (CTS) in less than 36 secs.
• Task switching When multiple applications have been launched, re-launching an already-running application after it has been launched MUST take less than 1 second.

8.2। ফাইল I/O অ্যাক্সেস কর্মক্ষমতা

Device implementations MUST ensure file access performance consistency for read and write operations.

• Sequential write Device implementations MUST ensure a sequential write performance of 5MB/s for a 256MB file using 10MB write buffer.
• Random write Device implementations MUST ensure a random write performance of 0.5MB/s for a 256MB file using 4KB write buffer.
• Sequential read Device implementations MUST ensure a sequential read performance of 15MB/s for a 256MB file using 10MB write buffer.
• Random read Device implementations MUST ensure a random read performance of 3.5MB/s for a 256MB file using 4KB write buffer.

9. নিরাপত্তা মডেল সামঞ্জস্য

Device implementations MUST implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ] in the Android developer documentation. ডিভাইস বাস্তবায়নগুলি অবশ্যই কোনও তৃতীয় পক্ষ/কর্তৃপক্ষের কোনও অতিরিক্ত অনুমতি/শংসাপত্রের প্রয়োজন ছাড়াই স্ব-স্বাক্ষরিত অ্যাপ্লিকেশনগুলির ইনস্টলেশনকে সমর্থন করতে হবে। Specifically, compatible devices MUST support the security mechanisms described in the follow subsections.

9.1। অনুমতি

Device implementations MUST support the Android permissions model as defined in the Android developer documentation [ Resources, 102 ]. বিশেষত, বাস্তবায়নগুলি অবশ্যই এসডিকে ডকুমেন্টেশনে বর্ণিত হিসাবে সংজ্ঞায়িত প্রতিটি অনুমতি প্রয়োগ করতে হবে; কোনও অনুমতি বাদ দেওয়া, পরিবর্তিত বা উপেক্ষা করা যাবে না। Implementations MAY add additional permissions, provided the new permission ID strings are not in the android.* namespace.

9.2। ইউআইডি এবং প্রক্রিয়া বিচ্ছিন্নতা

Device implementations MUST support the Android application sandbox model, in which each application runs as a unique Unixstyle UID and in a separate process. Device implementations MUST support running multiple applications as the same Linux user ID, provided that the applications are properly signed and constructed, as defined in the Security and Permissions reference [ Resources, 102 ].

9.3। ফাইল সিস্টেম অনুমতি

Device implementations MUST support the Android file access permissions model as defined in the Security and Permissions reference [ Resources, 102 ].

9.4। বিকল্প মৃত্যুদন্ড পরিবেশন

Device implementations MAY include runtime environments that execute applications using some other software or technology than the Dalvik Executable Format or native code. However, such alternate execution environments MUST NOT compromise the Android security model or the security of installed Android applications, as described in this section.

Alternate runtimes MUST themselves be Android applications, and abide by the standard Android security model, as described elsewhere in section 9 .

Alternate runtimes MUST NOT be granted access to resources protected by permissions not requested in the runtime's AndroidManifest.xml file via the পদ্ধতি.

Alternate runtimes MUST NOT permit applications to make use of features protected by Android permissions restricted to system applications.

Alternate runtimes MUST abide by the Android sandbox model. Specifically, alternate runtimes:

• SHOULD install apps via the PackageManager into separate Android sandboxes ( Linux user IDs, etc.)
• MAY provide a single Android sandbox shared by all applications using the alternate runtime
• and installed applications using an alternate runtime, MUST NOT reuse the sandbox of any other app installed on the device, except through the standard Android mechanisms of shared user ID and signing certificate
• MUST NOT launch with, grant, or be granted access to the sandboxes corresponding to other Android applications
• MUST NOT be launched with, be granted, or grant to other applications any privileges of the superuser (root), or of any other user ID

The .apk files of alternate runtimes MAY be included in the system image of a device implementation, but MUST be signed with a key distinct from the key used to sign other applications included with the device implementation.

When installing applications, alternate runtimes MUST obtain user consent for the Android permissions used by the application. If an application needs to make use of a device resource for which there is a corresponding Android permission (such as Camera, GPS, etc.), the alternate runtime MUST inform the user that the application will be able to access that resource. If the runtime environment does not record application capabilities in this manner, the runtime environment MUST list all permissions held by the runtime itself when installing any application using that runtime.

9.5। মাল্টি-ইউজার সাপোর্ট

Android includes support for multiple users and provides support for full user isolation [ Resources, 103] . Device implementations MAY enable multiple users, but when enabled MUST meet the following requirements related to multi-user support [ Resources, 104 ]:

• Device implementations that do not declare the android.hardware.telephony feature flag MUST support restricted profiles, a feature that allows device owners to manage additional users and their capabilities on the device. With restricted profiles, device owners can quickly set up separate environments for additional users to work in, with the ability to manage finer-grained restrictions in the apps that are available in those environments.
• Conversely device implementations that declare the android.hardware.telephony feature flag MUST NOT support restricted profiles but MUST align with the AOSP implementation of controls to enable /disable other users from accessing the voice calls and SMS.
• Device implementations MUST, for each user, implement a security model consistent with the Android platform security model as defined in Security and Permissions reference document in the APIs [ Resources, 102 ]
• Device implementations MAY support creating users and managed profiles via the android.app.admin.DevicePolicyManager APIs, and if supported, MUST declare the platform feature flag android.software.managed_users.
• Device implementations that declare the feature flag android.software.managed_users MUST use the upstream AOSP icon badge to represent the managed applications and other badge UI elements like Recents & Notifications.
• Each user instance on an Android device MUST have separate and isolated external storage directories. Device implementations MAY store multiple users' data on the same volume or filesystem. However, the device implementation MUST ensure that applications owned by and running on behalf a given user cannot list, read, or write to data owned by any other user. Note that removable media, such as SD card slots, can allow one user to access another's data by means of a host PC. For this reason, device implementations that use removable media for the primary external storage APIs MUST encrypt the contents of the SD card if multiuser is enabled using a key stored only on non-removable media accessible only to the system. As this will make the media unreadable by a host PC, device implementations will be required to switch to MTP or a similar system to provide host PCs with access to the current user's data. Accordingly, device implementations MAY but SHOULD NOT enable multi-user if they use removable media [ Resources, 105 ] for primary external storage.

9.6। প্রিমিয়াম এসএমএস সতর্কতা

Android includes support for warning users of any outgoing premium SMS message [ Resources, 106 ] . Premium SMS messages are text messages sent to a service registered with a carrier that may incur a charge to the user. Device implementations that declare support for android.hardware.telephony MUST warn users before sending a SMS message to numbers identified by regular expressions defined in /data/misc/sms/codes.xml file in the device. The upstream Android Open Source Project provides an implementation that satisfies this requirement.

৯.৭। কার্নেল নিরাপত্তা বৈশিষ্ট্য

The Android Sandbox includes features that use the Security-Enhanced Linux (SELinux) mandatory access control (MAC) system and other security features in the Linux kernel. SELinux or any other security features implemented below the Android framework:

• MUST maintain compatibility with existing applications
• MUST NOT have a visible user interface when a security violation is detected and successfully blocked, but MAY have a visible user interface when an unblocked security violation occurs resulting in a successful exploit
• SHOULD NOT be user or developer configurable

If any API for configuration of policy is exposed to an application that can affect another application (such as a Device Administration API), the API MUST NOT allow configurations that break compatibility.

Devices MUST implement SELinux or, if using a kernel other than Linux, an equivalent mandatory access control system. Devices must also meet the following requirements, which are satisfied by the reference implementation in the upstream Android Open Source Project.

ডিভাইস বাস্তবায়ন:

• MUST set SELinux to global enforcing mode,
• MUST configure all domains in enforcing mode. No permissive mode domains are allowed, including domains specific to a device/vendor.
• MUST NOT modify, omit, or replace the neverallow rules present within the external/sepolicy folder provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present, for both AOSP SELinux domains as well as device/vendor specific domains.

Device implementations SHOULD retain the default SELinux policy provided in the external/sepolicy folder of the upstream Android Open Source Project and only further add to this policy for their own device-specific configuration. Device implementations MUST be compatible with the upstream Android Open Source Project.

৯.৮। গোপনীয়তা

If the device implements functionality in the system that captures the contents displayed on the screen and/or records the audio stream played on the device, it MUST continuously notify the user whenever this functionality is enabled and actively capturing/recording.

9.9। ফুল-ডিস্ক এনক্রিপশন

If the device implementation has a lock screen, the device MUST support full-disk encryption of the application private data, (/data partition) as well as the SD card partition if it is a permanent, non-removable part of the device [ Resources, 107 ]. For devices supporting full-disk encryption, the full-disk encryption SHOULD be enabled all the time after the user has completed the out-of-box experience. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. Encryption MUST use AES with a key of 128-bits (or greater) and a mode designed for storage (for example, AES-XTS, AES-CBC-ESSIV). The encryption key MUST NOT be written to storage at any time without being encrypted. Other than when in active use, the encryption key SHOULD be AES encrypted with the lockscreen passcode stretched using a slow stretching algorithm (eg PBKDF2 or scrypt). If the user has not specified a lockscreen passcode or has disabled use of the passcode for encryption, the system SHOULD use a default passcode to wrap the encryption key. If the device provides a hardware-backed keystore, the password stretching algorithm MUST be cryptographically bound to that keystore. The encryption key MUST NOT be sent off the device (even when wrapped with the user passcode and/or hardware bound key). The upstream Android Open Source project provides a preferred implementation of this feature based on the linux kernel feature dm-crypt.

9.10। যাচাইকৃত বুট

Device implementations SHOULD support verified boot for device integrity, and if the feature is supported it MUST declare the platform feature flag android.software.verified_boot. While this requirement is stated as SHOULD for this version of the Android platform, it is very strongly RECOMMENDED as we expect this to change to MUST in the future versions of Android. The upstream Android Open Source Project provides a preferred implementation of this feature based on the linux kernel feature dm-verity.

10. সফ্টওয়্যার সামঞ্জস্য পরীক্ষা

Device implementations MUST pass all tests described in this section.

However, note that no software test package is fully comprehensive. For this reason, device implementers are very strongly encouraged to make the minimum number of changes as possible to the reference and preferred implementation of Android available from the Android Open Source Project. This will minimize the risk of introducing bugs that create incompatibilities requiring rework and potential device updates.

10.1। সামঞ্জস্য পরীক্ষা স্যুট

Device implementations MUST pass the Android Compatibility Test Suite (CTS) [ Resources, 108 ] available from the Android Open Source Project, using the final shipping software on the device. Additionally, device implementers SHOULD use the reference implementation in the Android Open Source tree as much as possible, and MUST ensure compatibility in cases of ambiguity in CTS and for any reimplementations of parts of the reference source code.

The CTS is designed to be run on an actual device. Like any software, the CTS may itself contain bugs. The CTS will be versioned independently of this Compatibility Definition, and multiple revisions of the CTS may be released for Android 5.0. Device implementations MUST pass the latest CTS version available at the time the device software is completed.

10.2। CTS যাচাইকারী

Device implementations MUST correctly execute all applicable cases in the CTS Verifier. The CTS Verifier is included with the Compatibility Test Suite, and is intended to be run by a human operator to test functionality that cannot be tested by an automated system, such as correct functioning of a camera and sensors.

The CTS Verifier has tests for many kinds of hardware, including some hardware that is optional. Device implementations MUST pass all tests for hardware that they possess; for instance, if a device possesses an accelerometer, it MUST correctly execute the Accelerometer test case in the CTS Verifier. Test cases for features noted as optional by this Compatibility Definition Document MAY be skipped or omitted.

Every device and every build MUST correctly run the CTS Verifier, as noted above. However, since many builds are very similar, device implementers are not expected to explicitly run the CTS Verifier on builds that differ only in trivial ways. Specifically, device implementations that differ from an implementation that has passed the CTS Verifier only by the set of included locales, branding, etc. MAY omit the CTS Verifier test.

11. আপডেটযোগ্য সফটওয়্যার

Device implementations MUST include a mechanism to replace the entirety of the system software. The mechanism need not perform "live" upgrades—that is, a device restart MAY be required.

Any method can be used, provided that it can replace the entirety of the software preinstalled on the device. For instance, any of the following approaches will satisfy this requirement:

• Over-the-air (OTA) downloads with offline update via reboot
• "Tethered" updates over USB from a host PC
• "Offline" updates via a reboot and update from a file on removable storage

However, if the device implementation includes support for an unmetered data connection such as 802.11 or Bluetooth PAN (Personal Area Network) profile, the device MUST support Over-the-air download with offline update via reboot.

The update mechanism used MUST support updates without wiping user data. That is, the update mechanism MUST preserve application private data and application shared data. Note that the upstream Android software includes an update mechanism that satisfies this requirement.

For device implementations that are launching with Android 5.0 and later, the update mechanism SHOULD support verifying that the system image is binary identical to expected result following an OTA. The block-based OTA implementation in the upstream Android Open Source Project, added since Android 5.0, satisfies this requirement.

If an error is found in a device implementation after it has been released but within its reasonable product lifetime that is determined in consultation with the Android Compatibility Team to affect the compatibility of third-party applications, the device implementer MUST correct the error via a software update available that can be applied per the mechanism just described.

12. ডকুমেন্ট চেঞ্জলগ

The following table contains a summary of the changes to the Compatibility Definition in this release.

13. আমাদের সাথে যোগাযোগ করুন

You can join the android-compatibility forum [Resources, 109 ] and ask for clarifications or bring up any issues that you think the document does not cover.

14. Resources

1. IETF RFC2119 Requirement Levels: http://www.ietf.org/rfc/rfc2119.txt

2. Android Open Source Project: http://source.android.com/

3. Android Television features: http://developer.android.com/reference/android/content/pm/PackageManager.html#FEATURE_LEANBACK

4. Android Watch feature: http://developer.android.com/reference/android/content/res/Configuration.html#UI_MODE_TYPE_WATCH

5. API definitions and documentation: http://developer.android.com/reference/packages.html

6. Android Permissions reference: http://developer.android.com/reference/android/Manifest.permission.html

7. android.os.Build reference: http://developer.android.com/reference/android/os/Build.html

8. Android 5.0 allowed version strings: http://source.android.com//docs/compatibility/5.0/versions

9. Telephony Provider: http://developer.android.com/reference/android/provider/Telephony.html

10. Host-based Card Emulation: http://developer.android.com/guide/topics/connectivity/nfc/hce.html

11. Android Extension Pack: http://developer.android.com/guide/topics/graphics/opengl.html#aep

12. android.webkit.WebView class: http://developer.android.com/reference/android/webkit/WebView.html

13. WebView compatibility: http://www.chromium.org/

14. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/

15. HTML5 offline capabilities: http://dev.w3.org/html5/spec/Overview.html#offline

16. HTML5 video tag: http://dev.w3.org/html5/spec/Overview.html#video

17. HTML5/W3C geolocation API: http://www.w3.org/TR/geolocation-API/

18. HTML5/W3C webstorage API: http://www.w3.org/TR/webstorage/

19. HTML5/W3C IndexedDB API: http://www.w3.org/TR/IndexedDB/

20. Dalvik Executable Format and bytecode specification: available in the Android source code, at dalvik/docs

21. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html

22. Notifications: http://developer.android.com/guide/topics/ui/notifiers/notifications.html

23. Application Resources: https://developer.android.com/guide/topics/resources/available-resources.html

24. Status Bar icon style guide: http://developer.android.com/design/style/iconography.html

25. Notifications Resources: https://developer.android.com/design/patterns/notifications.html

26. Search Manager: http://developer.android.com/reference/android/app/SearchManager.html

27. Toasts: http://developer.android.com/reference/android/widget/Toast.html

28. Themes: http://developer.android.com/guide/topics/ui/themes.html

29. R.style class: http://developer.android.com/reference/android/R.style.html

30. Material design: http://developer.android.com/reference/android/R.style.html#Theme_Material

31. Live Wallpapers: http://developer.android.com/reference/android/service/wallpaper/WallpaperService.html

32. Overview screen resources: http://developer.android.com/guide/components/recents.html

33. Screen pinning: https://developer.android.com/about/versions/android-5.0.html#ScreenPinning

34. Input methods: http://developer.android.com/guide/topics/text/creating-input-method.html

35. Media Notification: https://developer.android.com/reference/android/app/Notification.MediaStyle.html

36. Dreams: http://developer.android.com/reference/android/service/dreams/DreamService.html

37. Settings.Secure LOCATION_MODE:

http://developer.android.com/reference/android/provider/Settings.Secure.html#LOCATION_MODE

38. Unicode 6.1.0: http://www.unicode.org/versions/Unicode6.1.0/

39. Android Device Administration: http://developer.android.com/guide/topics/admin/device-admin.html

40. DevicePolicyManager reference: http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html

41. Android Device Owner App:

http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#isDeviceOwnerApp(java.lang.String)

42. Android Accessibility Service APIs: http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

43. Android Accessibility APIs: http://developer.android.com/reference/android/view/accessibility/package-summary.html

44. Eyes Free project: http://code.google.com/p/eyes-free

45. Text-To-Speech APIs: http://developer.android.com/reference/android/speech/tts/package-summary.html

46. Television Input Framework: /devices/tv/index.html

47. Reference tool documentation (for adb, aapt, ddms, systrace): http://developer.android.com/guide/developing/tools/index.html

48. Android apk file description: http://developer.android.com/guide/components/fundamentals.html

49. Manifest files: http://developer.android.com/guide/topics/manifest/manifest-intro.html

50. Android Media Formats: http://developer.android.com/guide/appendix/media-formats.html

51. RTC Hardware Coding Requirements: http://www.webmproject.org/hardware/rtc-coding-requirements/

52. AudioEffect API: http://developer.android.com/reference/android/media/audiofx/AudioEffect.html

53. Android android.content.pm.PackageManager class and Hardware Features List:

http://developer.android.com/reference/android/content/pm/PackageManager.html

54. HTTP Live Streaming Draft Protocol: http://tools.ietf.org/html/draft-pantos-http-live-streaming-03

55. ADB: http://developer.android.com/tools/help/adb.html

56. Dumpsys: https://developer.android.com/studio/command-line/dumpsys.html

57. DDMS: http://developer.android.com/tools/debugging/ddms.html

58. Monkey testing tool: http://developer.android.com/tools/help/monkey.html

59. SysyTrace tool: http://developer.android.com/tools/help/systrace.html

60. Android Application Development-Related Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_APPLICATION_DEVELOPMENT_SETTINGS

61. Supporting Multiple Screens: http://developer.android.com/guide/practices/screens_support.html

62. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html

63. RenderScript: http://developer.android.com/guide/topics/renderscript/

64. Android extension pack for OpenGL ES: https://developer.android.com/reference/android/opengl/GLES31Ext.html

65. Hardware Acceleration: http://developer.android.com/guide/topics/graphics/hardware-accel.html

66. EGL Extension-EGL_ANDROID_RECORDABLE:

http://www.khronos.org/registry/egl/extensions/ANDROID/EGL_ANDROID_recordable.txt

67. Display Manager: http://developer.android.com/reference/android/hardware/display/DisplayManager.html

68. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html

69. Action Assist: http://developer.android.com/reference/android/content/Intent.html#ACTION_ASSIST

70. Touch Input Configuration: http://source.android.com/docs/core/interaction/input/touch-devices

71. Motion Event API: http://developer.android.com/reference/android/view/MotionEvent.html

72. Key Event API: http://developer.android.com/reference/android/view/KeyEvent.html

73. Android Open Source sensors: http://source.android.com/docs/core/interaction/sensors

74. android.hardware.SensorEvent: http://developer.android.com/reference/android/hardware/SensorEvent.html

75. Timestamp sensor event: http://developer.android.com/reference/android/hardware/SensorEvent.html#timestamp

76. Android Open Source composite sensors: http://source.android.com/devices/sensors/composite_sensors.html

77. Continuous trigger mode: http://source.android.com/devices/sensors/base_triggers.html#continuous

78. Accelerometer sensor: http://developer.android.com/reference/android/hardware/Sensor.html#TYPE_ACCELEROMETER

79. Wi-Fi Multicast API: http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html

80. Wi-Fi Direct (Wi-Fi P2P): http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html

81. WifiManager API: http://developer.android.com/reference/android/net/wifi/WifiManager.html

82. Bluetooth API: http://developer.android.com/reference/android/bluetooth/package-summary.html

83. Bluetooth ScanFilter API: https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html

84. NDEF Push Protocol: http://source.android.com/docs/compatibility/ndef-push-protocol.pdf

85. Android Beam: http://developer.android.com/guide/topics/connectivity/nfc/nfc.html

86. Android NFC Sharing Settings:

http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS

87. NFC Connection Handover: http://www.nfc-forum.org/specs/spec_list/#conn_handover

88. Bluetooth Secure Simple Pairing Using NFC: http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf

89. Content Resolver: http://developer.android.com/reference/android/content/ContentResolver.html

90. Camera orientation API: http://developer.android.com/reference/android/hardware/Camera.html#setDisplayOrientation(int)

91. Camera: http://developer.android.com/reference/android/hardware/Camera.html

92. Camera: http://developer.android.com/reference/android/hardware/Camera.Parameters.html

93. Camera hardware level: https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics.html#INFO_SUPPORTED_HARDWARE_LEVEL

94. Camera version support: http://source.android.com/docs/core/camera/versioning

95. Android DownloadManager: http://developer.android.com/reference/android/app/DownloadManager.html

96. Android File Transfer: http://www.android.com/filetransfer

97. Android Open Accessories: http://developer.android.com/guide/topics/usb/accessory.html

98. Android USB Audio: http://developer.android.com/reference/android/hardware/usb/UsbConstants.html#USB_CLASS_AUDIO

99. USB Battery Charging Specification, Revision 1.2: http://www.usb.org/developers/docs/devclass_docs/BCv1.2_070312.zip

100. USB Host API: http://developer.android.com/guide/topics/usb/host.html

101. Wired audio headset: http://source.android.com/docs/core/interaction/accessories/headset/plug-headset-spec

102. Android Security and Permissions reference: http://developer.android.com/guide/topics/security/permissions.html

103. UserManager reference: http://developer.android.com/reference/android/os/UserManager.html

104. External Storage reference: http://source.android.com/docs/core/storage

105. External Storage APIs: http://developer.android.com/reference/android/os/Environment.html

106. SMS Short Code: http://en.wikipedia.org/wiki/Short_code

107. Android Open Source Encryption: http://source.android.com/devices/tech/encryption/index.html

108. Android Compatibility Program Overview: http://source.android.com/docs/compatibility

109. Android Compatibility forum: https://groups.google.com/forum/#!forum/android-compatibility

110. WebM project: http://www.webmproject.org/

Many of these resources are derived directly or indirectly from the Android SDK, and will be functionally identical to the information in that SDK's documentation. যে কোনো ক্ষেত্রে যেখানে এই সামঞ্জস্যতা সংজ্ঞা বা সামঞ্জস্য পরীক্ষা স্যুট SDK ডকুমেন্টেশনের সাথে একমত নয়, SDK ডকুমেন্টেশনকে প্রামাণিক বলে মনে করা হয়। উপরে অন্তর্ভুক্ত রেফারেন্সে প্রদত্ত যেকোন প্রযুক্তিগত বিশদ এই সামঞ্জস্যতার সংজ্ঞার অংশ হিসাবে অন্তর্ভুক্তির দ্বারা বিবেচনা করা হয়।