অ্যান্ড্রয়েড 2.2 সামঞ্জস্যের সংজ্ঞা

সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।

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

সুচিপত্র

1। পরিচিতি

এই দস্তাবেজটি মোবাইল ফোনগুলিকে Android 2.2 এর সাথে সামঞ্জস্যপূর্ণ হওয়ার জন্য প্রয়োজনীয় প্রয়োজনীয়তাগুলিকে গণনা করে৷

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

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

Android 2.2 এর সাথে সামঞ্জস্যপূর্ণ বলে বিবেচিত হতে, ডিভাইস বাস্তবায়ন:

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

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

2. সম্পদ

1. IETF RFC2119 প্রয়োজনীয়তার স্তর: http://www.ietf.org/rfc/rfc2119.txt
2. অ্যান্ড্রয়েড সামঞ্জস্যতা প্রোগ্রাম ওভারভিউ: http://source.android.com/docs/compatibility/index.html
3. অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট: http://source.android.com/
4. API সংজ্ঞা এবং ডকুমেন্টেশন: http://developer.android.com/reference/packages.html
5. অ্যান্ড্রয়েড অনুমতির রেফারেন্স: http://developer.android.com/reference/android/Manifest.permission.html
6. android.os.Build রেফারেন্স: http://developer.android.com/reference/android/os/Build.html
7. Android 2.2 অনুমোদিত সংস্করণ স্ট্রিং: http://source.android.com/docs/compatibility/2.2/versions.html
8. android.webkit.WebView ক্লাস: http://developer.android.com/reference/android/webkit/WebView.html
9. HTML5: http://www.whatwg.org/specs/web-apps/current-work/multipage/
10. ডালভিক ভার্চুয়াল মেশিন স্পেসিফিকেশন: অ্যান্ড্রয়েড সোর্স কোডে, ডালভিক/ডক্সে উপলব্ধ
11. AppWidgets: http://developer.android.com/guide/practices/ui_guidelines/widget_design.html
12. বিজ্ঞপ্তি: http://developer.android.com/guide/topics/ui/notifiers/notifications.html
13. অ্যাপ্লিকেশন সংস্থান: http://code.google.com/android/reference/available-resources.html
14. স্ট্যাটাস বার আইকন শৈলী নির্দেশিকা: http://developer.android.com/guide/practices/ui_guideline /icon_design.html#statusbarstructure
15. অনুসন্ধান ম্যানেজার: http://developer.android.com/reference/android/app/SearchManager.html
16. টোস্ট: http://developer.android.com/reference/android/widget/Toast.html
17. লাইভ ওয়ালপেপার: https://android-developers.googleblog.com/2010/02/live-wallpapers.html
18. অ্যান্ড্রয়েডের জন্য অ্যাপস: http://code.google.com/p/apps-for-android
19. রেফারেন্স টুল ডকুমেন্টেশন (adb, aapt, ddms এর জন্য): http://developer.android.com/guide/developing/tools/index.html
20. Android apk ফাইলের বিবরণ: http://developer.android.com/guide/topics/fundamentals.html
21. ম্যানিফেস্ট ফাইল: http://developer.android.com/guide/topics/manifest/manifest-intro.html
22. বানর পরীক্ষার টুল: https://developer.android.com/studio/test/other-testing-tools/monkey
23. অ্যান্ড্রয়েড হার্ডওয়্যার বৈশিষ্ট্যের তালিকা: http://developer.android.com/reference/android/content/pm/PackageManager.html
24. একাধিক স্ক্রীন সমর্থন করে: http://developer.android.com/guide/practices/screens_support.html
25. android.content.res.Configuration: http://developer.android.com/reference/android/content/res/Configuration.html
26. android.util.DisplayMetrics: http://developer.android.com/reference/android/util/DisplayMetrics.html
27. android.hardware.Camera: http://developer.android.com/reference/android/hardware/Camera.html
28. সেন্সর স্থানাঙ্ক: http://developer.android.com/reference/android/hardware/SensorEvent.html
29. অ্যান্ড্রয়েড নিরাপত্তা এবং অনুমতির রেফারেন্স: http://developer.android.com/guide/topics/security/security.html
30. ব্লুটুথ API: http://developer.android.com/reference/android/bluetooth/package-summary.html

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

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

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

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

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

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

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

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

3.2.1। অনুমতি

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

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

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

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

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

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

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

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

নিম্নলিখিত অ্যাপ্লিকেশনগুলিকে মূল অ্যান্ড্রয়েড সিস্টেম অ্যাপ্লিকেশন হিসাবে বিবেচনা করা হয়:

• ডেস্ক ঘড়ি
• ব্রাউজার
• ক্যালেন্ডার
• ক্যালকুলেটর
• ক্যামেরা
• পরিচিতি
• ইমেইল
• গ্যালারি
• গ্লোবাল সার্চ
• লঞ্চার
• লাইভপিকার (অর্থাৎ, লাইভ ওয়ালপেপার পিকার অ্যাপ্লিকেশন; বিভাগ 3.8.5 অনুযায়ী ডিভাইসটি লাইভ ওয়ালপেপার সমর্থন না করলে বাদ দেওয়া যেতে পারে।)
• মেসেজিং (একেএ "Mms")
• সঙ্গীত
• ফোন
• সেটিংস
• শব্দ লিপিবদ্ধ কারী

মূল অ্যান্ড্রয়েড সিস্টেম অ্যাপ্লিকেশনগুলির মধ্যে রয়েছে বিভিন্ন কার্যকলাপ, বা পরিষেবা উপাদান যা "পাবলিক" হিসাবে বিবেচিত হয়। অর্থাৎ, অ্যাট্রিবিউট "android:exported" অনুপস্থিত হতে পারে, অথবা "true" মান থাকতে পারে।

মূল Android সিস্টেম অ্যাপগুলির মধ্যে একটিতে সংজ্ঞায়িত প্রতিটি অ্যাক্টিভিটি বা পরিষেবার জন্য যা একটি android:এক্সপোর্টেড অ্যাট্রিবিউটের মাধ্যমে "false" মান সহ অ-পাবলিক হিসাবে চিহ্নিত করা হয়নি, ডিভাইস বাস্তবায়নে একই ধরনের একটি উপাদান অন্তর্ভুক্ত করা আবশ্যক যাতে একই ইন্টেন্ট ফিল্টার প্রয়োগ করা হয় মূল অ্যান্ড্রয়েড সিস্টেম অ্যাপ হিসাবে নিদর্শন।

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

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

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

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

ডিভাইস ইমপ্লিমেন্টারদের এমন কোনো অ্যান্ড্রয়েড কম্পোনেন্ট অন্তর্ভুক্ত করা উচিত নয় যা অ্যান্ড্রয়েড।* নেমস্পেস-এ অ্যাকশন, ক্যাটাগরি, বা অন্যান্য কী স্ট্রিং ব্যবহার করে কোনও নতুন ইন্টেন্ট বা ব্রডকাস্ট ইন্টেন্ট প্যাটার্নকে সম্মান করে। ডিভাইস ইমপ্লিমেন্টারদের এমন কোনও Android উপাদান অন্তর্ভুক্ত করা উচিত নয় যা অন্য সংস্থার অন্তর্গত প্যাকেজ স্পেসে ACTION, CATEGORY, বা অন্যান্য কী স্ট্রিং ব্যবহার করে কোনও নতুন অভিপ্রায় বা সম্প্রচার অভিপ্রায় প্যাটার্নকে সম্মান করে৷ ডিভাইস বাস্তবায়নকারীরা অবশ্যই বিভাগ 3.2.3.1-এ তালিকাভুক্ত মূল অ্যাপগুলির দ্বারা ব্যবহৃত কোনো ইন্টেন্ট প্যাটার্ন পরিবর্তন বা প্রসারিত করবেন না।

এই নিষেধাজ্ঞাটি বিভাগ 3.6-এ জাভা ভাষার ক্লাসের জন্য নির্দিষ্ট করা অনুরূপ।

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

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

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

ডালভিকে চলমান পরিচালিত কোডটি অ্যাপ্লিকেশন .apk ফাইলে প্রদত্ত নেটিভ কোডে কল করতে পারে একটি ELF হিসাবে . তাই উপযুক্ত ডিভাইস হার্ডওয়্যার আর্কিটেকচারের জন্য সংকলিত ফাইল৷ ডিভাইস ইমপ্লিমেন্টেশনে অবশ্যই স্ট্যান্ডার্ড জাভা নেটিভ ইন্টারফেস (JNI) শব্দার্থবিদ্যা ব্যবহার করে নেটিভ কোডে কল করার জন্য পরিচালিত পরিবেশে চলমান কোডের সমর্থন অন্তর্ভুক্ত করতে হবে। নিম্নলিখিত APIগুলি অবশ্যই নেটিভ কোডে উপলব্ধ হতে হবে:

• libc (সি লাইব্রেরি)
• libm (গণিত গ্রন্থাগার)
• JNI ইন্টারফেস
• libz (Zlib কম্প্রেশন)
• liblog (Android লগিং)
• C++ এর জন্য ন্যূনতম সমর্থন
• OpenGL-এর জন্য সমর্থন, নীচে বর্ণিত হিসাবে

ডিভাইস বাস্তবায়ন অবশ্যই OpenGL ES 1.0 সমর্থন করবে। যে ডিভাইসগুলিতে হার্ডওয়্যার ত্বরণের অভাব রয়েছে সেগুলিকে অবশ্যই একটি সফ্টওয়্যার রেন্ডারার ব্যবহার করে OpenGL ES 1.0 প্রয়োগ করতে হবে। ডিভাইস বাস্তবায়নে OpenGL ES 1.1 যতটা ডিভাইস হার্ডওয়্যার সমর্থন করে ততটা বাস্তবায়ন করা উচিত। ডিভাইস বাস্তবায়নে OpenGL ES 2.0 এর জন্য একটি বাস্তবায়ন প্রদান করা উচিত, যদি হার্ডওয়্যারটি সেই APIগুলিতে যুক্তিসঙ্গত কার্য সম্পাদন করতে সক্ষম হয়।

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

ডিভাইস বাস্তবায়নকে অবশ্যই android.os.Build.CPU_ABI API এর মাধ্যমে ডিভাইস দ্বারা সমর্থিত নেটিভ অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI) সঠিকভাবে রিপোর্ট করতে হবে। ABI অবশ্যই docs/CPU-ARCH-ABIS.txt ফাইলে Android NDK-এর সর্বশেষ সংস্করণে নথিভুক্ত এন্ট্রিগুলির মধ্যে একটি হতে হবে। মনে রাখবেন যে Android NDK-এর অতিরিক্ত রিলিজ অতিরিক্ত ABI-এর জন্য সমর্থন প্রবর্তন করতে পারে।

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

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

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

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

Android ওপেন সোর্স বাস্তবায়ন android.webkit.WebView বাস্তবায়নের জন্য WebKit রেন্ডারিং ইঞ্জিন ব্যবহার করে। যেহেতু একটি ওয়েব রেন্ডারিং সিস্টেমের জন্য একটি বিস্তৃত পরীক্ষা স্যুট তৈরি করা সম্ভব নয়, তাই ডিভাইস বাস্তবায়নকারীদের অবশ্যই WebView বাস্তবায়নে WebKit-এর নির্দিষ্ট আপস্ট্রিম বিল্ড ব্যবহার করতে হবে। বিশেষভাবে:

• ডিভাইস বাস্তবায়নের android.webkit.WebView বাস্তবায়ন অবশ্যই Android 2.2 এর জন্য আপস্ট্রিম অ্যান্ড্রয়েড ওপেন সোর্স ট্রি থেকে 533.1 ওয়েবকিট বিল্ডের উপর ভিত্তি করে হওয়া উচিত। এই বিল্ডটিতে WebView-এর জন্য কার্যকারিতা এবং নিরাপত্তা ফিক্সের একটি নির্দিষ্ট সেট অন্তর্ভুক্ত রয়েছে। ডিভাইস বাস্তবায়নকারীরা WebKit বাস্তবায়নে কাস্টমাইজেশন অন্তর্ভুক্ত করতে পারে; যাইহোক, এই ধরনের কোনো কাস্টমাইজেশন অবশ্যই রেন্ডারিং আচরণ সহ WebView-এর আচরণকে পরিবর্তন করবে না।
• WebView দ্বারা রিপোর্ট করা ব্যবহারকারী এজেন্ট স্ট্রিং এই বিন্যাসে হওয়া আবশ্যক:
  Mozilla/5.0 (Linux; U; Android $(VERSION); $(LOCALE); $(MODEL) Build/$(BUILD)) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1
  • $(VERSION) স্ট্রিংটির মান অবশ্যই android.os.Build.VERSION.RELEASE এর মানের সমান হতে হবে
  • $(LOCALE) স্ট্রিংয়ের মানটি দেশের কোড এবং ভাষার জন্য ISO নিয়মগুলি অনুসরণ করা উচিত এবং ডিভাইসের বর্তমান কনফিগার করা লোকেলকে উল্লেখ করা উচিত
  • $(MODEL) স্ট্রিংয়ের মান অবশ্যই android.os.Build.MODEL এর মানের সমান হতে হবে
  • $(BUILD) স্ট্রিংটির মান অবশ্যই android.os.Build.ID এর মানের সমান হতে হবে

ওয়েবভিউ কনফিগারেশনে অবশ্যই HTML5 ডাটাবেস, অ্যাপ্লিকেশন ক্যাশে এবং জিওলোকেশন API [ সম্পদ, 9 ] এর জন্য সমর্থন অন্তর্ভুক্ত থাকতে হবে। WebView-এ HTML5 <video> ট্যাগের সমর্থন অন্তর্ভুক্ত করা আবশ্যক। HTML5 APIs, সমস্ত JavaScript API-এর মতো, একটি WebView-এ ডিফল্টরূপে অক্ষম করা আবশ্যক, যদি না বিকাশকারী স্বাভাবিক Android API-এর মাধ্যমে তাদের স্পষ্টভাবে সক্ষম করে।

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

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

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

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

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

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

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

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

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

3.6। API নামস্থান

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

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

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

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

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

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

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

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

3.7। ভার্চুয়াল মেশিন সামঞ্জস্য

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

মাঝারি- বা নিম্ন-ঘনত্ব হিসাবে শ্রেণীবদ্ধ স্ক্রিনগুলির সাথে ডিভাইস বাস্তবায়নের জন্য প্রতিটি অ্যাপ্লিকেশনে কমপক্ষে 16MB মেমরি বরাদ্দ করতে Dalvik কনফিগার করতে হবে। উচ্চ-ঘনত্ব হিসাবে শ্রেণীবদ্ধ স্ক্রিনগুলির সাথে ডিভাইস বাস্তবায়নগুলি অবশ্যই প্রতিটি অ্যাপ্লিকেশনে কমপক্ষে 24MB মেমরি বরাদ্দ করার জন্য ডালভিককে কনফিগার করতে হবে। মনে রাখবেন যে ডিভাইস বাস্তবায়ন এই পরিসংখ্যানের চেয়ে বেশি মেমরি বরাদ্দ করতে পারে।

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

অ্যান্ড্রয়েড প্ল্যাটফর্মে কিছু বিকাশকারী API অন্তর্ভুক্ত রয়েছে যা বিকাশকারীদের সিস্টেম ইউজার ইন্টারফেসে হুক করার অনুমতি দেয়। ডিভাইস ইমপ্লিমেন্টেশনগুলিকে অবশ্যই এই স্ট্যান্ডার্ড UI APIগুলিকে তাদের বিকাশ করা কাস্টম ইউজার ইন্টারফেসে অন্তর্ভুক্ত করতে হবে, যেমনটি নীচে ব্যাখ্যা করা হয়েছে।

3.8.1। উইজেট

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

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

3.8.2। বিজ্ঞপ্তি

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

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

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

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

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

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

3.8.4। টোস্ট

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

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

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

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

উপরে বর্ণিত হিসাবে নির্ভরযোগ্যভাবে লাইভ ওয়ালপেপার চালাতে সক্ষম ডিভাইস বাস্তবায়ন লাইভ ওয়ালপেপার প্রয়োগ করা উচিত। উপরে বর্ণিত লাইভ ওয়ালপেপারগুলি নির্ভরযোগ্যভাবে না চালানোর জন্য নির্ধারিত ডিভাইস বাস্তবায়নগুলি লাইভ ওয়ালপেপার প্রয়োগ করা উচিত নয়৷

4. রেফারেন্স সফ্টওয়্যার সামঞ্জস্য

ডিভাইস ইমপ্লিমেন্টারদের অবশ্যই নিম্নলিখিত ওপেন-সোর্স অ্যাপ্লিকেশনগুলি ব্যবহার করে বাস্তবায়ন সামঞ্জস্যতা পরীক্ষা করতে হবে:

• ক্যালকুলেটর (SDK-তে অন্তর্ভুক্ত)
• লুনার ল্যান্ডার (SDK-তে অন্তর্ভুক্ত)
• "অ্যান্ড্রয়েডের জন্য অ্যাপস" অ্যাপ্লিকেশনগুলি [ সম্পদ, 18 ]।
• রেপ্লিকা আইল্যান্ড (অ্যান্ড্রয়েড মার্কেটে উপলব্ধ; শুধুমাত্র ডিভাইস বাস্তবায়নের জন্য প্রয়োজন যা OpenGL ES 2.0 এর সাথে সমর্থন করে)

উপরোক্ত প্রতিটি অ্যাপ অবশ্যই লঞ্চ করতে হবে এবং বাস্তবায়নে সঠিকভাবে আচরণ করতে হবে, যাতে বাস্তবায়নকে সামঞ্জস্যপূর্ণ বলে বিবেচনা করা হয়।

অতিরিক্তভাবে, ডিভাইস বাস্তবায়নকে অবশ্যই এই স্মোক-টেস্ট অ্যাপ্লিকেশনগুলির প্রতিটি মেনু আইটেম (সমস্ত সাব-মেনু সহ) পরীক্ষা করতে হবে:

• ApiDemos (SDK-তে অন্তর্ভুক্ত)
• ম্যানুয়াল স্মোক টেস্ট (সিটিএস-এ অন্তর্ভুক্ত)

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

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

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

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

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

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

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

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

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

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

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

যখন কোনও অ্যাপ্লিকেশন অডিও স্ট্রিম রেকর্ডিং শুরু করতে android.media.AudioRecord API ব্যবহার করে, ডিভাইস বাস্তবায়নের এই প্রতিটি আচরণের সাথে অডিও নমুনা এবং রেকর্ড করা উচিত:

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

দ্রষ্টব্য: উপরে বর্ণিত প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েড ২.২ এর জন্য "উচিত" হিসাবে বর্ণিত হয়েছে, ভবিষ্যতের সংস্করণের জন্য সামঞ্জস্যতা সংজ্ঞাটি এগুলিকে "আবশ্যক" এ পরিবর্তন করার পরিকল্পনা করা হয়েছে। এটি হ'ল, এই প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েড ২.২ এ al চ্ছিক তবে ভবিষ্যতের সংস্করণ দ্বারা প্রয়োজনীয় হবে । অ্যান্ড্রয়েড ২.২ অ্যান্ড্রয়েড চালানো বিদ্যমান এবং নতুন ডিভাইসগুলি অ্যান্ড্রয়েড ২.২ -এ এই প্রয়োজনীয়তাগুলি পূরণ করতে খুব দৃ strongly ়ভাবে উত্সাহিত করা হয়, বা ভবিষ্যতের সংস্করণে আপগ্রেড করার সময় তারা অ্যান্ড্রয়েডের সামঞ্জস্যতা অর্জন করতে সক্ষম হবে না।

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

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

এই বিভাগের উদ্দেশ্যে:

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

উপরের সংজ্ঞাগুলি ব্যবহার করে, ডিভাইস বাস্তবায়নগুলি এই বৈশিষ্ট্যগুলির প্রতিটি প্রদর্শন করা উচিত:

• 100 মিলিসেকেন্ড বা তার চেয়ে কম শীতের আউটপুট বিলম্ব
• 10 মিলিসেকেন্ড বা তারও কমের উষ্ণ আউটপুট লেটেন্সি
• 45 মিলিসেকেন্ড বা তার চেয়ে কম অবিচ্ছিন্ন আউটপুট বিলম্ব
• 100 মিলিসেকেন্ড বা তারও কমের শীতল ইনপুট বিলম্ব
• 50 মিলিসেকেন্ড বা তারও কম অবিচ্ছিন্ন ইনপুট লেটেন্সি

দ্রষ্টব্য: উপরে বর্ণিত প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েড ২.২ এর জন্য "উচিত" হিসাবে বর্ণিত হয়েছে, ভবিষ্যতের সংস্করণের জন্য সামঞ্জস্যতা সংজ্ঞাটি এগুলিকে "আবশ্যক" এ পরিবর্তন করার পরিকল্পনা করা হয়েছে। এটি হ'ল, এই প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েড ২.২ এ al চ্ছিক তবে ভবিষ্যতের সংস্করণ দ্বারা প্রয়োজনীয় হবে । অ্যান্ড্রয়েড ২.২ অ্যান্ড্রয়েড চালানো বিদ্যমান এবং নতুন ডিভাইসগুলি অ্যান্ড্রয়েড ২.২ -এ এই প্রয়োজনীয়তাগুলি পূরণ করতে খুব দৃ strongly ়ভাবে উত্সাহিত করা হয়, বা ভবিষ্যতের সংস্করণে আপগ্রেড করার সময় তারা অ্যান্ড্রয়েডের সামঞ্জস্যতা অর্জন করতে সক্ষম হবে না।

7. বিকাশকারী সরঞ্জাম সামঞ্জস্যতা

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

• অ্যান্ড্রয়েড ডিবাগ ব্রিজ (এডিবি হিসাবে পরিচিত) [ সংস্থানসমূহ, ১৯ ]
  ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড এসডিকে নথিভুক্ত হিসাবে সমস্ত adb ফাংশনগুলিকে সমর্থন করবে। ডিভাইস-সাইড adb ডেমন ডিফল্টরূপে নিষ্ক্রিয় হওয়া উচিত, তবে অ্যান্ড্রয়েড ডিবাগ ব্রিজটি চালু করার জন্য অবশ্যই একটি ব্যবহারকারী-অ্যাক্সেসযোগ্য প্রক্রিয়া থাকতে হবে।
• ডালভিক ডিবাগ মনিটর পরিষেবা (ডিডিএমএস হিসাবে পরিচিত) [ সংস্থানসমূহ, ১৯ ]
  ডিভাইস বাস্তবায়নগুলি অবশ্যই অ্যান্ড্রয়েড এসডিকে নথিভুক্ত হিসাবে সমস্ত ddms বৈশিষ্ট্যগুলিকে সমর্থন করবে। যেহেতু ddms adb ব্যবহার করে, ddms জন্য সমর্থন ডিফল্টরূপে নিষ্ক্রিয় হওয়া উচিত, তবে যখনই ব্যবহারকারী উপরের মতো অ্যান্ড্রয়েড ডিবাগ ব্রিজটি সক্রিয় করে রাখেন তখন অবশ্যই এটি সমর্থন করা উচিত।
• বানর [ সংস্থানসমূহ, ২২ ]
  ডিভাইস বাস্তবায়নে অবশ্যই বানরের কাঠামো অন্তর্ভুক্ত থাকতে হবে এবং অ্যাপ্লিকেশনগুলি ব্যবহারের জন্য এটি উপলব্ধ করতে হবে।

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

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

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

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

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

ডিভাইস বাস্তবায়নগুলি অবশ্যই getSystemAvailableFeatures() এবং Hasystystemfeature android.content.pm.PackageManager শ্রেণিতে hasSystemFeature(String) পদ্ধতিগুলির মাধ্যমে সঠিক হার্ডওয়্যার কনফিগারেশন সম্পর্কিত তথ্যগুলি সঠিকভাবে প্রতিবেদন করতে হবে। [ সংস্থানসমূহ, 23 ]

8.1। প্রদর্শন

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

অ্যান্ড্রয়েড ২.২ এর জন্য, এগুলি সর্বাধিক সাধারণ ডিসপ্লে কনফিগারেশন:

উপরের একটি স্ট্যান্ডার্ড কনফিগারেশনের সাথে সম্পর্কিত ডিভাইস বাস্তবায়নগুলি অবশ্যই android.content.res.Configuration [ সংস্থানসমূহ, ২৪ ] শ্রেণীর মাধ্যমে অ্যাপ্লিকেশনগুলিতে নির্দেশিত স্ক্রিনের আকারটি প্রতিবেদন করতে কনফিগার করতে হবে।

কিছু .apk প্যাকেজগুলি এমনভাবে প্রকাশ করে যা তাদের নির্দিষ্ট ঘনত্বের পরিসীমা সমর্থন হিসাবে চিহ্নিত করে না। এই জাতীয় অ্যাপ্লিকেশনগুলি চালানোর সময়, নিম্নলিখিত সীমাবদ্ধতাগুলি প্রয়োগ হয়:

• ডিভাইস বাস্তবায়নগুলি অবশ্যই একটি .apk এ সংস্থানগুলি ব্যাখ্যা করতে হবে যার মধ্যে "মাঝারি" (এসডিকে ডকুমেন্টেশনে "এমডিপিআই" নামে পরিচিত) হিসাবে ডিফল্ট হিসাবে ঘনত্বের বাছাইপর্বের অভাব রয়েছে))
• "কম" ঘনত্বের স্ক্রিনে অপারেটিং করার সময়, ডিভাইস বাস্তবায়নগুলি অবশ্যই 0.75 এর একটি ফ্যাক্টর দ্বারা মাঝারি/এমডিপিআই সম্পদগুলি স্কেল করতে হবে।
• "উচ্চ" ঘনত্বের স্ক্রিনে অপারেটিং করার সময়, ডিভাইস বাস্তবায়নগুলি 1.5 এর একটি ফ্যাক্টর দ্বারা মাঝারি/এমডিপিআই সম্পদগুলি স্কেল করতে হবে।
• ডিভাইস বাস্তবায়নগুলি অবশ্যই ঘনত্বের সীমার মধ্যে সম্পদ স্কেল করতে হবে না এবং ঘনত্বের সীমার মধ্যে ঠিক এই কারণগুলির দ্বারা সম্পদগুলি স্কেল করতে হবে।

8.1.2। অ-মানক প্রদর্শন কনফিগারেশন

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

নোট করুন যে কিছু ডিসপ্লে কনফিগারেশন (যেমন খুব বড় বা খুব ছোট স্ক্রিন এবং কিছু দিক অনুপাত) অ্যান্ড্রয়েড 2.2 এর সাথে মৌলিকভাবে বেমানান; সুতরাং ডিভাইস প্রয়োগকারীরা উন্নয়ন প্রক্রিয়াতে যত তাড়াতাড়ি সম্ভব অ্যান্ড্রয়েড সামঞ্জস্যতা দলের সাথে যোগাযোগ করতে উত্সাহিত করা হয়।

8.1.3। মেট্রিক প্রদর্শন

ডিভাইস বাস্তবায়নগুলি অবশ্যই android.util.DisplayMetrics [ সংস্থানসমূহ, 26 ] এ সংজ্ঞায়িত সমস্ত ডিসপ্লে মেট্রিকগুলির জন্য সঠিক মানগুলির প্রতিবেদন করতে হবে।

8.1.4। ঘোষিত স্ক্রিন সমর্থন

অ্যাপ্লিকেশনগুলি অ্যান্ড্রয়েডম্যানিফেস্ট.এক্সএমএল ফাইলে <supports-screens> স্ক্রিনস> বৈশিষ্ট্যের মাধ্যমে কোন স্ক্রিন আকারগুলি সমর্থন করে তা নির্দেশ করতে পারে। ডিভাইস বাস্তবায়নগুলি অ্যান্ড্রয়েড এসডিকে ডকুমেন্টেশনে বর্ণিত হিসাবে ছোট, মাঝারি এবং বৃহত পর্দার জন্য অ্যাপ্লিকেশনগুলির যথাযথ সমর্থনকে সঠিকভাবে সম্মান করতে হবে।

8.2। কীবোর্ড

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

• ইনপুট ম্যানেজমেন্ট ফ্রেমওয়ার্কের জন্য অবশ্যই সমর্থন অন্তর্ভুক্ত করা উচিত (যা তৃতীয় পক্ষের বিকাশকারীদের ইনপুট ম্যানেজমেন্ট ইঞ্জিনগুলি তৈরি করতে দেয় - যেমন নরম কীবোর্ড) বিকাশকারী.অ্যান্ড্রয়েড.কম এ বিশদ হিসাবে
• কমপক্ষে একটি নরম কীবোর্ড বাস্তবায়ন সরবরাহ করতে হবে (হার্ড কীবোর্ড উপস্থিত কিনা তা নির্বিশেষে)
• অতিরিক্ত নরম কীবোর্ড বাস্তবায়ন অন্তর্ভুক্ত থাকতে পারে
• একটি হার্ডওয়্যার কীবোর্ড অন্তর্ভুক্ত থাকতে পারে
• অবশ্যই একটি হার্ডওয়্যার কীবোর্ড অন্তর্ভুক্ত করা উচিত নয় যা android.content.res.Configuration.keyboard [ সংস্থানসমূহ, 25 ] (অর্থাৎ, কিউওয়ার্টি বা 12-কী) এ উল্লিখিত ফর্ম্যাটগুলির মধ্যে একটির সাথে মেলে না

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

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

• একটি নন-টাচ নেভিগেশন বিকল্পগুলি বাদ দিতে পারে (এটি একটি ট্র্যাকবল, ডি-প্যাড বা চাকা বাদ দিতে পারে)
• android.content.res.Configuration.navigation [ সংস্থানসমূহ, 25 ] এর জন্য সঠিক মানটি অবশ্যই প্রতিবেদন করতে হবে

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

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

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

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

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

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

8.6। ইউএসবি

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

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

৮.৭। নেভিগেশন কী

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

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

৮.৮। ওয়্যারলেস ডেটা নেটওয়ার্কিং

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

যদি কোনও ডিভাইস বাস্তবায়নে একটি নির্দিষ্ট পদ্ধতি অন্তর্ভুক্ত থাকে যার জন্য অ্যান্ড্রয়েড এসডিকে একটি এপিআই (অর্থাৎ, ওয়াইফাই, জিএসএম, বা সিডিএমএ) অন্তর্ভুক্ত করে, বাস্তবায়ন অবশ্যই এপিআই সমর্থন করবে।

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

৮.৯। ক্যামেরা

ডিভাইস বাস্তবায়নে অবশ্যই একটি রিয়ার-ফেসিং ক্যামেরা অন্তর্ভুক্ত থাকতে হবে। অন্তর্ভুক্ত রিয়ার-ফেসিং ক্যামেরা:

• কমপক্ষে 2 মেগাপিক্সেলের একটি রেজোলিউশন থাকতে হবে
• হার্ডওয়্যার অটো-ফোকাস, বা ক্যামেরা ড্রাইভারটিতে প্রয়োগ করা সফ্টওয়্যার অটো-ফোকাস থাকা উচিত (অ্যাপ্লিকেশন সফ্টওয়্যার স্বচ্ছ)
• ফিক্স-ফোকাস বা ইডিএফ (ক্ষেত্রের বর্ধিত গভীরতা) হার্ডওয়্যার থাকতে পারে
• একটি ফ্ল্যাশ অন্তর্ভুক্ত থাকতে পারে। যদি ক্যামেরাটিতে একটি ফ্ল্যাশ অন্তর্ভুক্ত থাকে তবে Android.hardware.camera.previewcallback উদাহরণটি ক্যামেরা পূর্বরূপ পৃষ্ঠে নিবন্ধিত করা হয়েছে, যদি না অ্যাপ্লিকেশনটি স্পষ্টভাবে FLASH_MODE_AUTO বা ফ্ল্যাশ_আউটো বা FLASH_MODE_ON বৈশিষ্ট্যগুলি সক্ষম করে ফ্ল্যাশটি সক্ষম করে না থাকে তবে ফ্ল্যাশ ল্যাম্পটি আলোকিত করা উচিত নয় Camera.Parameters অবজেক্ট। নোট করুন যে এই সীমাবদ্ধতাটি ডিভাইসের অন্তর্নির্মিত সিস্টেম ক্যামেরা অ্যাপ্লিকেশনটিতে প্রযোজ্য নয়, তবে কেবল Camera.PreviewCallback ব্যবহার করে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে।

ডিভাইস বাস্তবায়নগুলি অবশ্যই ক্যামেরা সম্পর্কিত এপিআইগুলির জন্য নিম্নলিখিত আচরণগুলি প্রয়োগ করতে হবে:

1. যদি কোনও অ্যাপ্লিকেশনটি কখনও অ্যান্ড্রয়েড.হার্ডওয়্যার.ক্যামেরা.প্যারামিটার.সেটপ্রিভিউফর্ম্যাট (আইএনটি) কল করে না, তবে ডিভাইসটি অবশ্যই অ্যাপ্লিকেশন কলব্যাকগুলিতে সরবরাহিত প্রিভিউ ডেটাগুলির জন্য অ্যান্ড্রয়েড.হার্ডওয়্যার.পিক্সেলফর্ম্যাট.ওয়াইসিবিসিআর_420_sp ব্যবহার করতে হবে।
2. যদি কোনও অ্যাপ্লিকেশন একটি android.hardware.camera.previewcallback উদাহরণ নিবন্ধন করে এবং সিস্টেমটি অনপরিভিউফ্রেম () পদ্ধতিটি কল করে যখন পূর্বরূপ ফর্ম্যাটটি ycbcr_420_sp হয়, তবে বাইট [] এর ডেটা আরও এনভি 21 এনকোডিং ফর্ম্যাটে যেতে হবে। (এটি 7 কে হার্ডওয়্যার পরিবার দ্বারা স্থানীয়ভাবে ব্যবহৃত ফর্ম্যাট)) এটি, এনভি 21 অবশ্যই ডিফল্ট হতে হবে।

ডিভাইসে হার্ডওয়্যার অটোফোকাস বা অন্যান্য ক্ষমতা অন্তর্ভুক্ত কিনা তা নির্বিশেষে ডিভাইস বাস্তবায়নগুলি অ্যান্ড্রয়েড ২.২ এসডিকে ডকুমেন্টেশন [ সংস্থানসমূহ, ২ 27 ]) এর অন্তর্ভুক্ত সম্পূর্ণ ক্যামেরা এপিআই প্রয়োগ করতে হবে। উদাহরণস্বরূপ, অটোফোকাসের অভাবযুক্ত ক্যামেরাগুলি অবশ্যই কোনও নিবন্ধিত android.hardware.Camera.AutoFocusCallback উদাহরণ কল করতে হবে (যদিও এটি একটি নন-অটোফোকাস ক্যামেরার সাথে কোনও প্রাসঙ্গিকতা নেই))

ডিভাইস বাস্তবায়নগুলি অবশ্যই android.hardware.Camera.Parameters ক্লাসে ধ্রুবক হিসাবে সংজ্ঞায়িত প্রতিটি প্যারামিটারের নামটি স্বীকৃতি দিতে হবে এবং সম্মান করতে হবে, যদি অন্তর্নিহিত হার্ডওয়্যার বৈশিষ্ট্যটিকে সমর্থন করে। যদি ডিভাইস হার্ডওয়্যার কোনও বৈশিষ্ট্য সমর্থন না করে তবে এপিআই অবশ্যই নথিভুক্ত হিসাবে আচরণ করতে হবে। বিপরীতে, ডিভাইস বাস্তবায়নগুলি অবশ্যই android.hardware.Camera.setParameters() android.hardware.Camera.Parameters ধ্রুবক হিসাবে নথিভুক্ত হওয়া ব্যতীত অন্য পদ্ধতি। এটি হ'ল, হার্ডওয়্যারটি অনুমতি দিলে ডিভাইস বাস্তবায়নগুলি অবশ্যই সমস্ত স্ট্যান্ডার্ড ক্যামেরা পরামিতিগুলিকে সমর্থন করবে এবং কাস্টম ক্যামেরা প্যারামিটারের প্রকারগুলি সমর্থন করবে না।

ডিভাইস বাস্তবায়নে একটি সামনের মুখোমুখি ক্যামেরা অন্তর্ভুক্ত থাকতে পারে। তবে, যদি কোনও ডিভাইস বাস্তবায়নে একটি সামনের মুখোমুখি ক্যামেরা অন্তর্ভুক্ত থাকে তবে ডিভাইসে প্রয়োগ করা ক্যামেরা এপিআই অবশ্যই ডিফল্টরূপে সামনের মুখী ক্যামেরাটি ব্যবহার করবে না। এটি হ'ল অ্যান্ড্রয়েড ২.২-এর ক্যামেরা এপিআই কেবল রিয়ার-ফেসিং ক্যামেরার জন্য এবং ডিভাইস বাস্তবায়নগুলি যদি উপস্থিত থাকে তবে সামনের মুখী ক্যামেরায় কাজ করার জন্য এপিআই পুনরায় ব্যবহার বা ওভারলোড করা উচিত নয়। নোট করুন যে ফ্রন্ট-ফেসিং ক্যামেরাগুলি সমর্থন করার জন্য ডিভাইস প্রয়োগকারীদের দ্বারা যুক্ত যে কোনও কাস্টম এপিআই অবশ্যই বিভাগগুলি 3.5 এবং 3.6 মেনে চলতে হবে; উদাহরণস্বরূপ, যদি কোনও কাস্টম android.hardware.Camera বা Camera.Parameters সাবক্লাসটি সামনের মুখী ক্যামেরাগুলি সমর্থন করার জন্য সরবরাহ করা হয়, তবে এটি অবশ্যই একটি বিদ্যমান নেমস্পেসে অবস্থিত হওয়া উচিত নয়, বিভাগগুলি 3.5 এবং 3.6 দ্বারা বর্ণিত হিসাবে। নোট করুন যে একটি সামনের মুখী ক্যামেরার অন্তর্ভুক্তিতে ডিভাইসগুলির একটি রিয়ার-ফেসিং ক্যামেরা অন্তর্ভুক্ত রয়েছে তা পূরণ করে না।

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

ডিভাইস বাস্তবায়নে অবশ্যই একটি 3-অক্ষের অ্যাক্সিলোমিটার অন্তর্ভুক্ত থাকতে হবে এবং অবশ্যই 50 হার্জ বা তার বেশি ইভেন্ট সরবরাহ করতে সক্ষম হতে হবে। অ্যাক্সিলোমিটার দ্বারা ব্যবহৃত সমন্বয় ব্যবস্থা অবশ্যই অ্যান্ড্রয়েড সেন্সর সমন্বয় সিস্টেমটি অ্যান্ড্রয়েড এপিআইগুলিতে বিশদ হিসাবে মেনে চলতে হবে (দেখুন [ সংস্থানসমূহ, ২৮ ])।

8.11। কম্পাস

ডিভাইস বাস্তবায়নে অবশ্যই একটি 3-অক্ষের কম্পাস অন্তর্ভুক্ত থাকতে হবে এবং 10 হার্জেড বা তার বেশি ইভেন্ট সরবরাহ করতে সক্ষম হতে হবে। কম্পাস দ্বারা ব্যবহৃত সমন্বয় সিস্টেমটি অবশ্যই অ্যান্ড্রয়েড এপিআইতে সংজ্ঞায়িত হিসাবে অ্যান্ড্রয়েড সেন্সর সমন্বয় সিস্টেমটি মেনে চলতে হবে (দেখুন [ সংস্থানসমূহ, ২৮ ])।

8.12। জিপিএস

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

৮.১৩। টেলিফোনি

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

বিভাগ 8.8, ওয়্যারলেস ডেটা নেটওয়ার্কিংও দেখুন।

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

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

ডিভাইস বাস্তবায়নের অবশ্যই ব্যবহারকারীর ডেটার জন্য কমপক্ষে 150MB অ-উদ্বায়ী স্টোরেজ উপলব্ধ থাকতে হবে। অর্থাৎ, /data পার্টিশন অবশ্যই কমপক্ষে 150MB হতে হবে।

উপরের প্রয়োজনীয়তাগুলির বাইরে, ডিভাইস বাস্তবায়নের কার্নেল এবং ব্যবহারকারীস্পেসের জন্য কমপক্ষে 128MB মেমরি পাওয়া উচিত, কার্নেলের নিয়ন্ত্রণে নেই এমন হার্ডওয়্যার উপাদানগুলিতে উত্সর্গীকৃত কোনও মেমরি ছাড়াও। ডিভাইস বাস্তবায়নের ব্যবহারকারীর ডেটার জন্য কমপক্ষে 1 গিগাবাইট অ-ভোল্টাইল স্টোরেজ উপলব্ধ থাকা উচিত। নোট করুন যে এই উচ্চতর প্রয়োজনীয়তাগুলি অ্যান্ড্রয়েডের ভবিষ্যতের সংস্করণে কঠোর ন্যূনতম হওয়ার পরিকল্পনা করা হয়েছে। ডিভাইস বাস্তবায়নগুলি এখন এই প্রয়োজনীয়তাগুলি মেটাতে দৃ strongly ়ভাবে উত্সাহিত করা হয়, অন্যথায় তারা অ্যান্ড্রয়েডের ভবিষ্যতের সংস্করণের জন্য সামঞ্জস্যের জন্য যোগ্য নাও হতে পারে।

৮.১৫। অ্যাপ্লিকেশন ভাগ করা স্টোরেজ

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

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

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

ডিভাইস বাস্তবায়নে ব্যবহারকারী-অ্যাক্সেসযোগ্য অপসারণযোগ্য স্টোরেজ যেমন সুরক্ষিত ডিজিটাল কার্ডের জন্য হার্ডওয়্যার থাকতে পারে। বিকল্পভাবে, ডিভাইস বাস্তবায়নগুলি অ্যাপ্লিকেশনগুলির ভাগ করে নেওয়া স্টোরেজ হিসাবে অভ্যন্তরীণ (অ-অপসারণযোগ্য) স্টোরেজ বরাদ্দ করতে পারে।

ব্যবহৃত ভাগ করা স্টোরেজের ফর্ম নির্বিশেষে, ভাগ করা স্টোরেজটি অবশ্যই ইউএসবি ভর স্টোরেজ বাস্তবায়ন করতে হবে, যেমনটি বিভাগ 8.6 -এ বর্ণিত হয়েছে। বাক্সের বাইরে পাঠানো হিসাবে, ভাগ করা স্টোরেজটি অবশ্যই ফ্যাট ফাইল সিস্টেমের সাথে মাউন্ট করা উচিত।

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

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

8.16। ব্লুটুথ

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

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

9. পারফরম্যান্স সামঞ্জস্যতা

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

10. সুরক্ষা মডেল সামঞ্জস্যতা

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

10.1। অনুমতি

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

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

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

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

ডিভাইস বাস্তবায়নগুলি অবশ্যই সুরক্ষা এবং অনুমতি রেফারেন্সে সংজ্ঞায়িত হিসাবে সংজ্ঞায়িত হিসাবে অ্যান্ড্রয়েড ফাইল অ্যাক্সেস অনুমতি মডেলকে সমর্থন করবে [ সংস্থানসমূহ, ২৯ ]।

10.4। বিকল্প সম্পাদন পরিবেশ

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

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

বিকল্প রানটাইমগুলি অবশ্যই রানটাইমের অ্যান্ড্রয়েডম্যানিফেস্ট.এক্সএমএল ফাইলটিতে <uses-permission> প্রক্রিয়াটির মাধ্যমে অনুরোধ না করা অনুমতিগুলির দ্বারা সুরক্ষিত সংস্থানগুলিতে অ্যাক্সেস মঞ্জুর করতে হবে না।

বিকল্প রানটাইমগুলি অবশ্যই সিস্টেম অ্যাপ্লিকেশনগুলিতে সীমাবদ্ধ অ্যান্ড্রয়েড অনুমতি দ্বারা সুরক্ষিত বৈশিষ্ট্যগুলি ব্যবহার করার জন্য অ্যাপ্লিকেশনগুলিকে অনুমতি দেবে না।

বিকল্প রানটাইমস অবশ্যই অ্যান্ড্রয়েড স্যান্ডবক্স মডেল মেনে চলতে হবে। বিশেষভাবে:

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

বিকল্প রানটাইমগুলি সুপারুজার (রুট) বা অন্য কোনও ব্যবহারকারী আইডি এর যে কোনও সুযোগ -সুবিধার সাথে অন্য অ্যাপ্লিকেশনগুলির সাথে চালু, মঞ্জুর করা বা মঞ্জুর করতে হবে না।

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

অ্যাপ্লিকেশনগুলি ইনস্টল করার সময়, বিকল্প রানটাইমগুলি অবশ্যই অ্যাপ্লিকেশন দ্বারা ব্যবহৃত অ্যান্ড্রয়েড অনুমতিগুলির জন্য ব্যবহারকারীর সম্মতি অর্জন করতে হবে। এটি হ'ল, যদি কোনও অ্যাপ্লিকেশনটির জন্য কোনও ডিভাইস রিসোর্স ব্যবহার করা প্রয়োজন যার জন্য একটি সম্পর্কিত অ্যান্ড্রয়েড অনুমতি রয়েছে (যেমন ক্যামেরা, জিপিএস ইত্যাদি), বিকল্প রানটাইম অবশ্যই ব্যবহারকারীকে অবহিত করতে হবে যে অ্যাপ্লিকেশনটি সেই সংস্থানটি অ্যাক্সেস করতে সক্ষম হবে . যদি রানটাইম পরিবেশ এই পদ্ধতিতে অ্যাপ্লিকেশন ক্ষমতা রেকর্ড না করে, রানটাইম পরিবেশকে অবশ্যই রানটাইম ব্যবহার করে কোনও অ্যাপ্লিকেশন ইনস্টল করার সময় রানটাইম নিজেই অনুষ্ঠিত সমস্ত অনুমতি তালিকাভুক্ত করতে হবে।

১১. সামঞ্জস্যতা পরীক্ষা স্যুট

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

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

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

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

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

• ওভার-দ্য এয়ার (ওটিএ) রিবুটের মাধ্যমে অফলাইন আপডেটের সাথে ডাউনলোডগুলি
• হোস্ট পিসি থেকে ইউএসবি -র উপর "টিথারড" আপডেটগুলি
• অপসারণযোগ্য স্টোরেজে কোনও ফাইল থেকে রিবুট এবং আপডেটের মাধ্যমে "অফলাইন" আপডেটগুলি

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

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

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

স্পষ্টতার জন্য এবং আপনার মনে হয় যে দস্তাবেজটি কভার করে না বলে মনে করেন এমন কোনও সমস্যা আনতে আপনি ডকুমেন্ট লেখকদের সাথে সামঞ্জস্যতা@android.com এ যোগাযোগ করতে পারেন।

পরিশিষ্ট এ - ব্লুটুথ পরীক্ষা পদ্ধতি

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

পরীক্ষার পদ্ধতিটি অ্যান্ড্রয়েড ওপেন-সোর্স প্রকল্প গাছের অন্তর্ভুক্ত ব্লুটুথচ্যাট নমুনা অ্যাপের উপর ভিত্তি করে। পদ্ধতিতে দুটি ডিভাইস প্রয়োজন:

• সফ্টওয়্যার বিল্ডটি চালানো একটি প্রার্থী ডিভাইস বাস্তবায়ন পরীক্ষা করা হবে
• একটি পৃথক ডিভাইস বাস্তবায়ন ইতিমধ্যে সামঞ্জস্যপূর্ণ হিসাবে পরিচিত এবং ডিভাইস বাস্তবায়ন থেকে একটি মডেল পরীক্ষা করা হচ্ছে - এটি একটি "পরিচিত ভাল" ডিভাইস বাস্তবায়ন

নীচের পরীক্ষার পদ্ধতিটি এই ডিভাইসগুলিকে যথাক্রমে "প্রার্থী" এবং "পরিচিত ভাল" ডিভাইস হিসাবে বোঝায়।

সেটআপ এবং ইনস্টলেশন

1. অ্যান্ড্রয়েড উত্স কোড ট্রি থেকে 'নমুনা তৈরি করুন' এর মাধ্যমে ব্লুটুথচ্যাট.এপকে তৈরি করুন।
2. পরিচিত-ভাল ডিভাইসে ব্লুটুথচ্যাট.এপকে ইনস্টল করুন।
3. প্রার্থী ডিভাইসে ব্লুটুথচ্যাট.এপকে ইনস্টল করুন।

অ্যাপ্লিকেশন দ্বারা ব্লুটুথ নিয়ন্ত্রণ পরীক্ষা করুন

1. প্রার্থী ডিভাইসে ব্লুটুথচ্যাট চালু করুন, যখন ব্লুটুথ অক্ষম রয়েছে।
2. Verify that the candidate device either turns on Bluetooth, or prompts the user with a dialog to turn on Bluetooth.

Test Pairing and Communication

1. Launch the Bluetooth Chat app on both devices.
2. Make the known-good device discoverable from within BluetoothChat (using the Menu).
3. On the candidate device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the known-good device.
4. Send 10 or more messages from each device, and verify that the other device receives them correctly.
5. Close the BluetoothChat app on both devices by pressing Home .
6. Unpair each device from the other, using the device Settings app.

Test Pairing and Communication in the Reverse Direction

1. Launch the Bluetooth Chat app on both devices.
2. Make the candidate device discoverable from within BluetoothChat (using the Menu).
3. On the known-good device, scan for Bluetooth devices from within BluetoothChat (using the Menu) and pair with the candidate device.
4. Send 10 or messages from each device, and verify that the other device receives them correctly.
5. Close the Bluetooth Chat app on both devices by pressing Back repeatedly to get to the Launcher.

Test Re-Launches

1. Re-launch the Bluetooth Chat app on both devices.
2. Send 10 or messages from each device, and verify that the other device receives them correctly.

Note: the above tests have some cases which end a test section by using Home, and some using Back. These tests are not redundant and are not optional: the objective is to verify that the Bluetooth API and stack works correctly both when Activities are explicitly terminated (via the user pressing Back, which calls finish()), and implicitly sent to background (via the user pressing Home.) Each test sequence MUST be performed as described.