অ্যান্ড্রয়েড 14
নভেম্বর 20, 2023
2. ডিভাইসের ধরন
রিভিশন দেখুন
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন কোনো 64-বিট ABI সমর্থন ঘোষণা করে (কোনও 32-বিট ABI সহ বা ছাড়া):
রিভিশন দেখুন
- [ 7.5 /H-1-13] 1টির বেশি RGB রিয়ার-ফেসিং ক্যামেরা থাকলে প্রাথমিক রিয়ার-ফেসিং ক্যামেরার জন্য
LOGICAL_MULTI_CAMERA
সক্ষমতা সমর্থন করতে হবে।
- [ 7.5 /H-1-13] 1টির বেশি RGB রিয়ার-ফেসিং ক্যামেরা থাকলে প্রাথমিক রিয়ার-ফেসিং ক্যামেরার জন্য
রিভিশন দেখুন
[ 5.8 /T-0-1] বাহ্যিক প্রদর্শনের জন্য 50Hz বা 60Hz রিফ্রেশ হারের সাথে কাজ করে এমন নির্বাচিত SDR বা HDR ফর্ম্যাটের জন্য HDMI আউটপুট মোডকে অবশ্যই সর্বোচ্চ রেজোলিউশনে সেট করতে হবে।
50Hz বা 60Hz রিফ্রেশ হারের সাথে সমর্থিত সর্বোচ্চ রেজোলিউশন নির্বাচন করতে HDMI আউটপুট মোড অবশ্যই সেট করতে হবে।
রিভিশন দেখুন
- [9/W-0-1] অবশ্যই
android.hardware.security.model.compatible feature
ঘোষণা করতে হবে।
- [9/W-0-1] অবশ্যই
6. বিকাশকারীর সরঞ্জাম এবং বিকল্পগুলির সামঞ্জস্য
রিভিশন দেখুন
- [C-0-12] একটি
LMK_KILL_OCCURRED_FIELD_NUMBER
এটম লিখতে হবে
রিভিশন দেখুন
- [C-0-13] প্রদর্শনের জন্য শেল কমান্ড
dumpsys gpu --gpuwork
প্রয়োগ করতে হবে
- [C-0-12] একটি
9. নিরাপত্তা মডেল সামঞ্জস্য
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়ন একটি Linux কার্নেল ব্যবহার করে যা SELinux সমর্থন করতে সক্ষম, তারা:
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়ন SELinux ছাড়া Linux বা Linux ছাড়া অন্য কার্নেল ব্যবহার করে, তারা:
4 অক্টোবর, 2023
2. ডিভাইসের ধরন
2.2। হ্যান্ডহেল্ড প্রয়োজনীয়তা :
রিভিশন দেখুন
Android ডিভাইস বাস্তবায়নকে হ্যান্ডহেল্ড হিসাবে শ্রেণীবদ্ধ করা হয় যদি তারা নিম্নলিখিত সমস্ত মানদণ্ড পূরণ করে:
- 4 ইঞ্চি
3.3 ইঞ্চি (অথবা 2.5 ইঞ্চি ডিভাইস বাস্তবায়নের জন্য যা API লেভেল 29 বা তার আগে পাঠানো হয়েছে)থেকে 8 ইঞ্চি রেঞ্জের মধ্যে একটি ভৌত তির্যক পর্দার আকার থাকতে হবে।
নতুন প্রয়োজনীয়তা শুরু করুন
- একটি টাচস্ক্রিন ইনপুট ইন্টারফেস আছে.
- 4 ইঞ্চি
রিভিশন দেখুন
হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন:
- [ 7.1 .1.1/H-0-1] কমপক্ষে একটি
Android-সামঞ্জস্যপূর্ণ ডিসপ্লে থাকতে হবে যা এই নথিতে বর্ণিত সমস্ত প্রয়োজনীয়তা পূরণ করে৷ছোট প্রান্তে কমপক্ষে 2.2" এবং দীর্ঘ প্রান্তে 3.4" পরিমাপ করে এমন প্রদর্শন করুন৷
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন সফ্টওয়্যার স্ক্রিন ঘূর্ণন সমর্থন করে, তারা:
- [ 7.1 .1.1/H-1-1]* তৃতীয় পক্ষের অ্যাপ্লিকেশনের জন্য উপলব্ধ করা যৌক্তিক স্ক্রিনটি ছোট প্রান্তে কমপক্ষে 2 ইঞ্চি এবং দীর্ঘ প্রান্তে 2.7 ইঞ্চি হতে হবে। Android API স্তর 29 বা তার আগে পাঠানো ডিভাইসগুলি এই প্রয়োজনীয়তা থেকে অব্যাহতি পাবে।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন সফ্টওয়্যার স্ক্রিন ঘূর্ণন সমর্থন না করে, তারা:
- [ 7.1 .1.1/H-2-1]* তৃতীয় পক্ষের অ্যাপ্লিকেশনের জন্য উপলব্ধ লজিক্যাল স্ক্রীনটি অবশ্যই ছোট প্রান্তে কমপক্ষে 2.7 ইঞ্চি হতে হবে। Android API স্তর 29 বা তার আগে পাঠানো ডিভাইসগুলি এই প্রয়োজনীয়তা থেকে অব্যাহতি পাবে।
নতুন প্রয়োজনীয়তা শুরু করুন
[ 7.1 .1.1/H-0-3]* তৃতীয় পক্ষের অ্যাপ্লিকেশনের জন্য উপলব্ধ করা প্রতিটি
UI_MODE_NORMAL
ডিসপ্লেকে অবশ্যই একটি অবরোধহীন শারীরিক প্রদর্শন অঞ্চলে ম্যাপ করতে হবে যা ছোট প্রান্তে কমপক্ষে 2.2” ইঞ্চি এবং দীর্ঘ প্রান্তে 3.4” ইঞ্চি।[ 7.1 .1.3/H-0-1]*
DENSITY_DEVICE_STABLE
এর মান অবশ্যই 92% বা সংশ্লিষ্ট ডিসপ্লের প্রকৃত, ভৌত ঘনত্বের চেয়ে বেশি সেট করতে হবে।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন
android.hardware.audio.output
এবংandroid.hardware.microphone
ঘোষণা করে, তারা:[ 5.6 /H-1-1] 300 মিলিসেকেন্ড বা 5 এর কম পরিমাপের একটি গড় ক্রমাগত রাউন্ড-ট্রিপ লেটেন্সি থাকতে হবে, একটি গড় পরম বিচ্যুতি 30ms এর কম, নিম্নলিখিত ডেটা পাথগুলিতে: "স্পিকার থেকে মাইক্রোফোন", 3.5 মিমি লুপব্যাক অ্যাডাপ্টার (যদি সমর্থিত হয়), USB লুপব্যাক (যদি সমর্থিত হয়)।
[ 5.6 /H-1-2] স্পীকার থেকে মাইক্রোফোন ডেটা পাথের উপর গড় ট্যাপ-টু-টোন লেটেন্সি 300 মিলিসেকেন্ড বা তার কম অন্তত 5 পরিমাপ থাকতে হবে।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নে কমপক্ষে একটি হ্যাপটিক অ্যাকুয়েটর অন্তর্ভুক্ত থাকে, তারা:
- [ 7.10 /H]* একটি উদ্ভট ঘূর্ণায়মান ভর (ERM) হ্যাপটিক অ্যাকচুয়েটর (ভাইব্রেটর) ব্যবহার করা উচিত নয়।
- [ 7.10 /H]* android.view- এ স্পষ্ট হ্যাপটিক্সের জন্য সমস্ত পাবলিক কনস্ট্যান্ট প্রয়োগ করতে হবে। হ্যাপটিকফিডব্যাক কনস্ট্যান্ট যথা (CLOCK_TICK, CONTEXT_CLICK, KEYBOARD_PRESS, KEYBOARD_RELEASE, KEYBOARD_TAP, VALTUVALKE, LONG_MOVALKE, LONG_TEXT_CLICK _KEY_RELEASE, CONFIRM, REJECT, GESTURE_START এবং GESTURE_END)।
- [ 7.10 /H]* android.os.VibrationEffect- এ স্পষ্ট হ্যাপটিক্সের জন্য সমস্ত পাবলিক কনস্ট্যান্ট প্রয়োগ করা উচিত, যথা (EFFECT_TICK, EFFECT_CLICK, EFFECT_HEAVY_CLICK এবং EFFECT_DOUBLE_CLICK) এবং Android এর জন্য সমস্ত সম্ভাব্য পাবলিক কনস্ট্যান্টের জন্য
PRIMITIVE_*
রিচের নাম। ly ( CLICK, TICK, LOW_TICK, QUICK_FALL, QUICK_RISE, SLOW_RISE, SPIN, THUD)। এর মধ্যে কিছু আদিম, যেমন LOW_TICK এবং SPIN শুধুমাত্র তখনই সম্ভব হতে পারে যদি ভাইব্রেটর তুলনামূলকভাবে কম ফ্রিকোয়েন্সি সমর্থন করতে পারে। - [7.10/H]* android.view.HapticFeedback Constants-এ android.os.VibrationEffect ধ্রুবকগুলির সাথে সংশ্লিষ্ট প্রশস্ততা সম্পর্কগুলির সাথে ম্যাপ করার নির্দেশিকা অনুসরণ করা উচিত৷
- [ 7.10 /H] * createOneShot() এবং createWaveform() API-এর জন্য গুণমানের মূল্যায়ন অনুসরণ করা উচিত।
- [ 7.10 /H]* সর্বজনীন android.os.Vibrator.hasAmplitudeControl() API-এর ফলাফল তাদের ভাইব্রেটরের ক্ষমতা সঠিকভাবে প্রতিফলিত করে তা যাচাই করা উচিত।
- [ 7.10 /H]* যেখানে ডিভাইসটি সাধারণত হাতে ধরে রাখা বা স্পর্শ করা হয় সেই অবস্থানের কাছাকাছি অ্যাকচুয়েটরের স্থাপন করা উচিত।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নে কমপক্ষে একটি সাধারণ উদ্দেশ্য 7.10 লিনিয়ার রেজোন্যান্ট অ্যাকচুয়েটর অন্তর্ভুক্ত থাকে, তারা:
- [ 7.10 /H] যেখানে ডিভাইসটি সাধারণত হাত দ্বারা ধরা বা স্পর্শ করা হয় সেই অবস্থানের কাছাকাছি অ্যাকচুয়েটর স্থাপন করা উচিত।
- [ 7.10 /H] ডিভাইসের প্রাকৃতিক
প্রতিকৃতিঅভিযোজনের X-অক্ষে (বাম-ডানে) হ্যাপটিক অ্যাকুয়েটরকে সরানো উচিত।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নের একটি সাধারণ উদ্দেশ্য হ্যাপটিক অ্যাকুয়েটর থাকে যা X-অক্ষ লিনিয়ার রেজোন্যান্ট অ্যাকচুয়েটর (LRA), তারা:
- [ 7.10 /H] X-অক্ষ LRA এর অনুরণিত ফ্রিকোয়েন্সি 200 Hz এর নিচে হওয়া উচিত।
- [ 7.1 .1.1/H-0-1] কমপক্ষে একটি
রিভিশন দেখুন
হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন অবশ্যই নিম্নলিখিত ভিডিও এনকোডিং ফর্ম্যাটগুলিকে সমর্থন করবে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে সেগুলি উপলব্ধ করবে:
- [ 5.2 /H-0-3] AV1
হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন অবশ্যই নিম্নলিখিত ভিডিও ডিকোডিং ফর্ম্যাটগুলিকে সমর্থন করবে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে সেগুলি উপলব্ধ করবে:
- [ 5.3 /H-0-6] AV1
রিভিশন দেখুন
যদি 7.2.3 বিভাগে বিশদ বিবরণ অনুযায়ী সাম্প্রতিক ফাংশন নেভিগেশন কী সহ ডিভাইস বাস্তবায়ন ইন্টারফেস পরিবর্তন করে, তারা:
- [ 3.8 .3/H-1-1] অবশ্যই স্ক্রিন পিনিং আচরণ বাস্তবায়ন করতে হবে এবং বৈশিষ্ট্যটি টগল করার জন্য ব্যবহারকারীকে একটি সেটিংস মেনু প্রদান করতে হবে।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নে
ControlsProviderService
এবংControl
API-এর সমর্থন অন্তর্ভুক্ত থাকে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিকে ডিভাইস নিয়ন্ত্রণ প্রকাশ করার অনুমতি দেয়, তাহলে তারা:- [ 3.8 .16/H-1-6] ডিভাইস বাস্তবায়ন অবশ্যই সঠিকভাবে ব্যবহারকারীর সামর্থ্য নিম্নরূপ রেন্ডার করবে:
- যদি ডিভাইসটি
config_supportsMultiWindow=true
সেট করে থাকে এবং অ্যাপটিControlsProviderService
ঘোষণায় মেটাডেটাMETA_DATA_PANEL_ACTIVITY
ঘোষণা করে, যার মধ্যে একটি বৈধ কার্যকলাপের কম্পোনেন্টনাম (এপিআই দ্বারা সংজ্ঞায়িত করা হয়েছে), তাহলে অ্যাপটিকে এই ব্যবহারকারীর সামর্থ্যে বলা কার্যকলাপ এমবেড করতে হবে। - অ্যাপটি যদি মেটাডেটা
META_DATA_PANEL_ACTIVITY
ঘোষণা না করে, তাহলে এটিকে অবশ্যইControlsProviderService
API দ্বারা প্রদত্ত নির্দিষ্ট ক্ষেত্রগুলির পাশাপাশি কন্ট্রোল API দ্বারা প্রদত্ত যেকোন নির্দিষ্ট ক্ষেত্রগুলিকে রেন্ডার করতে হবে৷
- যদি ডিভাইসটি
- [ 3.8 .16/H-1-7] অ্যাপটি যদি মেটাডেটা
META_DATA_PANEL_ACTIVITY
ঘোষণা করে, তাহলে এটিকে [3.8.16/H-1-5] এ সংজ্ঞায়িত সেটিং এর মানটি পাস করতে হবে যখনEXTRA_LOCKSCREEN_ALLOW_TRIVIAL_CONTROLS
লঞ্চ করা অ্যাক্টিভিটি ব্যবহার করে।
যদি ডিভাইস বাস্তবায়ন ব্যবহারকারীদের যে কোনো ধরনের কল করার অনুমতি দেয়, তারা
- [ 7.4.1.2 /H-0-1] ফিচার পতাকা
android.software.telecom
ঘোষণা করতে হবে। - [ 7.4.1.2 /H-0-2] টেলিকম ফ্রেমওয়ার্ক অবশ্যই বাস্তবায়ন করতে হবে।
রিভিশন দেখুন
হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন:
- [ 8.5 /H-0-1] SDK নথিতে বর্ণিত হিসাবে এটি শুরু হওয়ার পর থেকে এই পরিষেবাগুলির প্রতিটির সময়কাল সহ সক্রিয় ফোরগ্রাউন্ড পরিষেবা বা ব্যবহারকারীর দ্বারা শুরু করা চাকরি সহ সমস্ত অ্যাপ দেখতে
সেটিংস মেনুতেএকটি ব্যবহারকারীর সামর্থ্য প্রদান করতে হবে .এবং একটি ফোরগ্রাউন্ড পরিষেবা বা ব্যবহারকারীর সূচনা করা কাজ চালাচ্ছে এমন একটি অ্যাপ বন্ধ করার ক্ষমতা।একটি ফোরগ্রাউন্ড পরিষেবা চালাচ্ছে এমন একটি অ্যাপ বন্ধ করার ক্ষমতা এবং সক্রিয় ফোরগ্রাউন্ড পরিষেবা রয়েছে এমন সমস্ত অ্যাপ এবং SDK নথিতে বর্ণিত হিসাবে এটি শুরু হওয়ার পর থেকে এই পরিষেবাগুলির প্রতিটির সময়কাল প্রদর্শন করার ক্ষমতা সহ।- কিছু অ্যাপ SDK নথিতে বর্ণিত ব্যবহারকারীর সামর্থ্য অনুযায়ী বন্ধ হওয়া বা তালিকাভুক্ত হওয়া থেকে অব্যাহতি পেতে পারে।
- [ 8.5 /H-0-1] SDK নথিতে বর্ণিত হিসাবে এটি শুরু হওয়ার পর থেকে এই পরিষেবাগুলির প্রতিটির সময়কাল সহ সক্রিয় ফোরগ্রাউন্ড পরিষেবা বা ব্যবহারকারীর দ্বারা শুরু করা চাকরি সহ সমস্ত অ্যাপ দেখতে
- [ 8.5 /H-0-2] একটি ফোরগ্রাউন্ড পরিষেবা বা ব্যবহারকারীর দ্বারা সূচিত কাজ চালানোর জন্য একটি অ্যাপ বন্ধ করার জন্য একটি ব্যবহারকারীর সামর্থ্য প্রদান করতে হবে৷
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়ন android.hardware.telephony
এর জন্য সমর্থন ঘোষণা করে, তারা:
- [ 9.5 /H-1-1]
UserManager.isHeadlessSystemUserMode
true
সেট করা উচিত নয়।
যদি ডিভাইস বাস্তবায়নের একটি নিরাপদ লক স্ক্রীন থাকে এবং এতে এক বা একাধিক ট্রাস্ট এজেন্ট অন্তর্ভুক্ত থাকে, যা TrustAgentService
System API প্রয়োগ করে, তারা:
- [ 9.11.1 /H-1-1] প্রস্তাবিত প্রাথমিক প্রমাণীকরণ পদ্ধতিগুলির একটির (যেমন: পিন, প্যাটার্ন, পাসওয়ার্ড) প্রতি 72 ঘন্টায় একবারের চেয়ে বেশি ঘন ঘন ব্যবহারকারীকে চ্যালেঞ্জ করতে হবে।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন UserManager.isHeadlessSystemUserMode
true
সেট করে, তারা
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন সিস্টেম API HotwordDetectionService
সমর্থন করে বা মাইক অ্যাক্সেস ইঙ্গিত ছাড়া হটওয়ার্ড সনাক্তকরণের জন্য অন্য একটি প্রক্রিয়া সমর্থন করে, তারা:
- [9.8/H-1-1] নিশ্চিত করতে হবে যে হটওয়ার্ড সনাক্তকরণ পরিষেবাটি শুধুমাত্র সিস্টেমে ডেটা প্রেরণ করতে পারে,
ContentCaptureService
, অথবাSpeechRecognizer#createOnDeviceSpeechRecognizer()
দ্বারা তৈরি ডিভাইসে স্পিচ রিকগনিশন পরিষেবা। - [9.8/H-1-6] প্রতিটি সফল হটওয়ার্ড ফলাফলে হটওয়ার্ড সনাক্তকরণ পরিষেবার বাইরে 100 বাইটের বেশি ডেটা (অডিও স্ট্রিম ব্যতীত) প্রেরণ করার অনুমতি দেওয়া উচিত নয়।
- [৯.৮/H-1-15] নিশ্চিত করতে হবে যে সফল হটওয়ার্ড ফলাফলে প্রদত্ত অডিও স্ট্রীমগুলি হটওয়ার্ড সনাক্তকরণ পরিষেবা থেকে ভয়েস ইন্টারঅ্যাকশন পরিষেবাতে একতরফাভাবে প্রেরণ করা হয়েছে৷
যদি ডিভাইস বাস্তবায়নে এমন একটি অ্যাপ্লিকেশন অন্তর্ভুক্ত থাকে যা সিস্টেম API HotwordDetectionService
, বা মাইক ব্যবহারের ইঙ্গিত ছাড়াই হটওয়ার্ড সনাক্তকরণের অনুরূপ পদ্ধতি ব্যবহার করে, অ্যাপ্লিকেশন:
- [9.8/H-2-3] হটওয়ার্ড সনাক্তকরণ পরিষেবা, অডিও ডেটা, ডেটা যা অডিও পুনর্গঠন (সম্পূর্ণ বা আংশিকভাবে) করতে ব্যবহার করা যেতে পারে, বা হটওয়ার্ডের সাথে সম্পর্কিত নয় এমন অডিও বিষয়বস্তু থেকে প্রেরণ করা উচিত নয়,
ContentCaptureService
বা অন-ডিভাইস স্পিচ রিকগনিশন সার্ভিস।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন সিস্টেম API VisualQueryDetectionService
বা মাইক এবং/অথবা ক্যামেরা অ্যাক্সেস ইঙ্গিত ছাড়া ক্যোয়ারী সনাক্তকরণের জন্য অন্য পদ্ধতি সমর্থন করে, তারা:
- [9.8/H-3-1] অবশ্যই নিশ্চিত করতে হবে যে ক্যোয়ারী সনাক্তকরণ পরিষেবাটি কেবলমাত্র সিস্টেমে ডেটা প্রেরণ করতে পারে, বা
ContentCaptureService
, বা অন-ডিভাইস স্পিচ রিকগনিশন পরিষেবা (SpeechRecognizer#createOnDeviceSpeechRecognizer()
দ্বারা তৈরি করা হয়েছে)৷ - [9.8/H-3-2]
ContentCaptureService
বা অন-ডিভাইস স্পিচ রিকগনিশন পরিষেবা ব্যতীত,VisualQueryDetectionService
থেকে কোনও অডিও বা ভিডিও তথ্য প্রেরণের অনুমতি দেওয়া উচিত নয়৷ - [9.8/H-3-3] সিস্টেম UI-তে একটি ব্যবহারকারীর বিজ্ঞপ্তি প্রদর্শন করতে হবে যখন ডিভাইসটি ডিজিটাল সহকারী অ্যাপ্লিকেশনের সাথে যুক্ত হওয়ার জন্য ব্যবহারকারীর অভিপ্রায় সনাক্ত করে (যেমন ক্যামেরার মাধ্যমে ব্যবহারকারীর উপস্থিতি সনাক্ত করে)।
- [9.8/H-3-4] অবশ্যই একটি মাইক্রোফোন সূচক প্রদর্শন করতে হবে এবং ব্যবহারকারীর ক্যোয়ারী শনাক্ত হওয়ার পরই UI-তে সনাক্ত করা ব্যবহারকারীর ক্যোয়ারী প্রদর্শন করতে হবে।
- [9.8/H-3-5] ভিজ্যুয়াল কোয়েরি সনাক্তকরণ পরিষেবা প্রদান করার জন্য একটি ব্যবহারকারী-ইনস্টলযোগ্য অ্যাপ্লিকেশনকে অনুমতি দেওয়া উচিত নয়৷
রিভিশন দেখুন
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন android.os.Build.VERSION_CODES.T
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
দেয়, তাহলে তারা:
- Android 13 CDD সেকশন 2.2.7.1- এ তালিকাভুক্ত মিডিয়া প্রয়োজনীয়তা অবশ্যই পূরণ করতে হবে।
নতুন প্রয়োজনীয়তা শুরু করুন
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়নandroid.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
এর জন্য android.os.Build.VERSION_CODES.U
ফেরত দেয়, তাহলে তারা:- [5.1/H-1-1] সর্বাধিক সংখ্যক হার্ডওয়্যার ভিডিও ডিকোডার সেশনের বিজ্ঞাপন দিতে হবে যা
CodecCapabilities.getMaxSupportedInstances()
এবংVideoCapabilities.getSupportedPerformancePoints()
পদ্ধতির মাধ্যমে যেকোন কোডেক সংমিশ্রণে একযোগে চালানো যেতে পারে। - [5.1/H-1-2] 1080p রেজোলিউশন@30 fps এ 3টি সেশনের সাথে একযোগে চলমান যেকোনো কোডেক সংমিশ্রণে 8-বিট (SDR) হার্ডওয়্যার ভিডিও ডিকোডার সেশনের (AVC, HEVC, VP9, AV1 বা পরবর্তী) 6টি দৃষ্টান্ত সমর্থন করতে হবে এবং 4k রেজোলিউশন@30fps-এ 3টি সেশন, যদি না AV1। AV1 কোডেকগুলি শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, কিন্তু এখনও 1080p30fps-এ 6টি দৃষ্টান্ত সমর্থন করার জন্য প্রয়োজন৷
- [5.1/H-1-3] সর্বাধিক সংখ্যক হার্ডওয়্যার ভিডিও এনকোডার সেশনের বিজ্ঞাপন দিতে হবে যা
CodecCapabilities.getMaxSupportedInstances()
এবংVideoCapabilities.getSupportedPerformancePoints()
পদ্ধতির মাধ্যমে যেকোন কোডেক সংমিশ্রণে একযোগে চালানো যেতে পারে। - [5.1/H-1-4] 8-বিট (SDR) হার্ডওয়্যার ভিডিও এনকোডার সেশনের (AVC, HEVC, VP9, AV1 বা পরবর্তী) 6 টি দৃষ্টান্ত সমর্থন করতে হবে যেকোন কোডেক সংমিশ্রণে 1080p রেজোলিউশন@30 fps এ 4টি সেশনের সাথে একযোগে চলমান এবং 4k রেজোলিউশন@30fps-এ 2টি সেশন, যদি না AV1। AV1 কোডেকগুলি শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, কিন্তু এখনও 1080p30fps-এ 6টি দৃষ্টান্ত সমর্থন করার জন্য প্রয়োজন৷
- [5.1/H-1-5] অবশ্যই সর্বাধিক সংখ্যক হার্ডওয়্যার ভিডিও এনকোডার এবং ডিকোডার সেশনের বিজ্ঞাপন দিতে হবে যা
CodecCapabilities.getMaxSupportedInstances()
এবংVideoCapabilities.getSupportedPerformancePoints()
পদ্ধতির মাধ্যমে যেকোন কোডেক সংমিশ্রণে একযোগে চালানো যেতে পারে। - [5.1/H-1-6] 4K এ 3টি সেশনের সাথে একযোগে চলমান যেকোনো কোডেক সংমিশ্রণে 8-বিট (SDR) হার্ডওয়্যার ভিডিও ডিকোডার এবং হার্ডওয়্যার ভিডিও এনকোডার সেশনের (AVC, HEVC, VP9, AV1 বা পরবর্তী) 6টি উদাহরণ সমর্থন করতে হবে @30fps রেজোলিউশন (AV1 ছাড়া), যার মধ্যে সর্বাধিক 2টি এনকোডার সেশন এবং 1080p রেজোলিউশনে 3টি সেশন। AV1 কোডেকগুলি শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, কিন্তু এখনও 1080p30fps-এ 6টি দৃষ্টান্ত সমর্থন করার জন্য প্রয়োজন৷
- [5.1/H-1-19] 10-বিট (HDR) হার্ডওয়্যার ভিডিও ডিকোডার এবং হার্ডওয়্যার ভিডিও এনকোডার সেশন (AVC, HEVC, VP9, AV1 বা পরবর্তী) 4K@30fps রেজোলিউশনে একযোগে চলমান যেকোনো কোডেক সংমিশ্রণে 3টি দৃষ্টান্ত সমর্থন করতে হবে (AV1 না থাকলে) যার মধ্যে সর্বাধিক 1টি একটি এনকোডার সেশন, যা একটি GL পৃষ্ঠের মাধ্যমে RGBA_1010102 ইনপুট ফর্ম্যাটে কনফিগার করা যেতে পারে। GL পৃষ্ঠ থেকে এনকোডিং করলে এনকোডার দ্বারা HDR মেটাডেটা তৈরির প্রয়োজন হয় না। AV1 কোডেক সেশন শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, এমনকি যখন এই প্রয়োজনীয়তা 4K এর জন্য কল করা হয়।
- [5.1/H-1-7] লোডের অধীনে থাকা সমস্ত হার্ডওয়্যার ভিডিও এনকোডারগুলির জন্য একটি 1080p বা ছোট ভিডিও এনকোডিং সেশনের জন্য 40 ms বা তার কম কোডেক ইনিশিয়ালাইজেশন লেটেন্সি থাকা আবশ্যক৷ এখানে লোডকে 1080p অডিও-ভিডিও রেকর্ডিং ইনিশিয়ালাইজেশনের সাথে হার্ডওয়্যার ভিডিও কোডেক ব্যবহার করে একটি সমবর্তী 1080p থেকে 720p ভিডিও-শুধুমাত্র ভিডিও ট্রান্সকোডিং সেশন হিসাবে সংজ্ঞায়িত করা হয়েছে। ডলবি ভিশন কোডেকের জন্য, কোডেক ইনিশিয়ালাইজেশন লেটেন্সি 50 ms বা তার কম হতে হবে।
- [5.1/H-1-8] লোডের অধীনে থাকাকালীন সমস্ত অডিও এনকোডারের জন্য 128 kbps বা নিম্ন বিটরেট অডিও এনকোডিং সেশনের জন্য 30 ms বা তার কম কোডেক ইনিশিয়ালাইজেশন লেটেন্সি থাকতে হবে। এখানে লোডকে 1080p অডিও-ভিডিও রেকর্ডিং ইনিশিয়ালাইজেশনের সাথে হার্ডওয়্যার ভিডিও কোডেক ব্যবহার করে একটি সমবর্তী 1080p থেকে 720p ভিডিও-শুধুমাত্র ভিডিও ট্রান্সকোডিং সেশন হিসাবে সংজ্ঞায়িত করা হয়েছে।
- [5.1/H-1-9] 8- উভয়ের জন্য 4k রেজোলিউশন@30 fps (এভি1 না থাকলে) যেকোন কোডেক সংমিশ্রণে সুরক্ষিত হার্ডওয়্যার ভিডিও ডিকোডার সেশনের (AVC, HEVC, VP9, AV1 বা পরবর্তী) 2টি দৃষ্টান্ত সমর্থন করতে হবে বিট (এসডিআর) এবং 10-বিট এইচডিআর সামগ্রী। AV1 কোডেক সেশন শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, এমনকি যখন এই প্রয়োজনীয়তা 4K এর জন্য কল করা হয়।
- [5.1/H-1-10] যেকোন কোডেকে নিরাপদ হার্ডওয়্যার ভিডিও ডিকোডার সেশনের 1টি (মোট 4টি দৃষ্টান্ত) (AVC, HEVC, VP9, AV1 বা পরবর্তী) সহ অ-সুরক্ষিত হার্ডওয়্যার ভিডিও ডিকোডার সেশনের 3টি দৃষ্টান্ত সমর্থন করতে হবে 4K রেজোলিউশন@30 এফপিএস (এভি1 ছাড়া) 3টি সেশনের সাথে একযোগে সংমিশ্রণ চলছে যার মধ্যে একটি সুরক্ষিত ডিকোডার সেশন এবং 1080p রেজোলিউশন@30fps-এ 1টি nn-সুরক্ষিত সেশন রয়েছে যেখানে সর্বাধিক 2টি সেশন 10-বিট HDR-এ হতে পারে। AV1 কোডেক সেশন শুধুমাত্র 1080p রেজোলিউশন সমর্থন করার জন্য প্রয়োজন, এমনকি যখন এই প্রয়োজনীয়তা 4K এর জন্য কল করা হয়।
- [5.1/H-1-11] ডিভাইসে প্রতিটি হার্ডওয়্যার AVC, HEVC, VP9 বা AV1 ডিকোডারের জন্য একটি সুরক্ষিত ডিকোডার সমর্থন করতে হবে।
- [5.1/H-1-12] লোডের অধীনে থাকা সমস্ত হার্ডওয়্যার ভিডিও ডিকোডারের জন্য একটি 1080p বা ছোট ভিডিও ডিকোডিং সেশনের জন্য 40 ms বা তার কম কোডেক ইনিশিয়ালাইজেশন লেটেন্সি থাকা আবশ্যক৷ এখানে লোডকে 1080p অডিও-ভিডিও প্লেব্যাক ইনিশিয়ালাইজেশন সহ হার্ডওয়্যার ভিডিও কোডেক ব্যবহার করে একটি সমবর্তী 1080p থেকে 720p ভিডিও-শুধুমাত্র ভিডিও ট্রান্সকোডিং সেশন হিসাবে সংজ্ঞায়িত করা হয়েছে। ডলবি ভিশন কোডেকের জন্য, কোডেক ইনিশিয়ালাইজেশন লেটেন্সি 50 ms বা তার কম হতে হবে।
- [5.1/H-1-13] লোডের অধীনে থাকাকালীন সমস্ত অডিও ডিকোডারের জন্য 128 kbps বা নিম্ন বিটরেট অডিও ডিকোডিং সেশনের জন্য 30 ms বা তার কম কোডেক ইনিশিয়ালাইজেশন লেটেন্সি থাকতে হবে। এখানে লোডকে 1080p অডিও-ভিডিও প্লেব্যাক ইনিশিয়ালাইজেশন সহ হার্ডওয়্যার ভিডিও কোডেক ব্যবহার করে একটি সমবর্তী 1080p থেকে 720p ভিডিও-শুধুমাত্র ভিডিও ট্রান্সকোডিং সেশন হিসাবে সংজ্ঞায়িত করা হয়েছে।
- [5.1/H-1-14] AV1 হার্ডওয়্যার ডিকোডার মেইন 10, লেভেল 4.1 এবং ফিল্ম গ্রেইন সমর্থন করতে হবে।
- [5.1/H-1-15] 4K60 সমর্থনকারী কমপক্ষে 1টি হার্ডওয়্যার ভিডিও ডিকোডার থাকতে হবে।
- [5.1/H-1-16] 4K60 সমর্থনকারী কমপক্ষে 1টি হার্ডওয়্যার ভিডিও এনকোডার থাকতে হবে।
- [5.3/H-1-1] লোডের অধীনে একটি 4K 60 fps ভিডিও সেশনের জন্য 10 সেকেন্ডে (অর্থাৎ 0.167 শতাংশের কম ফ্রেম ড্রপ) 1 ফ্রেমের বেশি ড্রপ করা উচিত নয়৷
- [5.3/H-1-2] একটি 4K সেশনের জন্য লোডের অধীনে একটি 60 fps ভিডিও সেশনে একটি ভিডিও রেজোলিউশন পরিবর্তনের সময় 10 সেকেন্ডে 1 ফ্রেমের বেশি ড্রপ করা উচিত নয়৷
- [5.6/H-1-1] CTS ভেরিফায়ার ট্যাপ-টু-টোন টেস্ট ব্যবহার করে 80 মিলিসেকেন্ড বা তার কম ট্যাপ-টু-টোন লেটেন্সি থাকতে হবে।
- [5.6/H-1-2] একটি রাউন্ড-ট্রিপ অডিও লেটেন্সি 80 মিলিসেকেন্ড বা অন্তত একটি সমর্থিত ডেটা পাথের বেশি হতে হবে।
- [5.6/H-1-3] কম লেটেন্সি এবং স্ট্রিমিং কনফিগারেশনের জন্য সম্পূর্ণ ডাটা পাথের মাধ্যমে সমর্থিত হলে 3.5 মিমি অডিও জ্যাক এবং USB অডিওর উপরে থাকলে স্টিরিও আউটপুটের জন্য >=24-বিট অডিও সমর্থন করতে হবে। কম লেটেন্সি কনফিগারেশনের জন্য, AAudio অ্যাপটিকে লো-লেটেন্সি কলব্যাক মোডে ব্যবহার করা উচিত। স্ট্রিমিং কনফিগারেশনের জন্য, অ্যাপটির দ্বারা একটি জাভা অডিওট্র্যাক ব্যবহার করা উচিত। লো লেটেন্সি এবং স্ট্রিমিং কনফিগারেশন উভয় ক্ষেত্রেই, HAL আউটপুট সিঙ্কের হয়
AUDIO_FORMAT_PCM_24_BIT
,AUDIO_FORMAT_PCM_24_BIT_PACKED
,AUDIO_FORMAT_PCM_32_BIT
বাAUDIO_FORMAT_PCM_FLOAT
এর লক্ষ্যমাত্রা আউটপুট করার জন্য গ্রহণ করা উচিত। - [5.6/H-1-4] সমর্থন করা আবশ্যক >=4 চ্যানেল ইউএসবি অডিও ডিভাইস (এটি গানের পূর্বরূপ দেখার জন্য ডিজে কন্ট্রোলার দ্বারা ব্যবহৃত হয়।)
- [5.6/H-1-5] ক্লাস কমপ্লায়েন্ট MIDI ডিভাইসগুলিকে সমর্থন করতে হবে এবং MIDI বৈশিষ্ট্য পতাকা ঘোষণা করতে হবে।
- [5.6/H-1-9] কমপক্ষে 12টি চ্যানেল মিক্সিং সমর্থন করতে হবে। এটি 7.1.4 চ্যানেল মাস্ক সহ একটি অডিওট্র্যাক খোলার এবং সমস্ত চ্যানেলকে স্টেরিওতে সঠিকভাবে স্থানিক বা ডাউনমিক্স করার ক্ষমতা বোঝায়।
- [5.6/H-SR] 9.1.6 এবং 22.2 চ্যানেল মাস্কের জন্য কমপক্ষে সমর্থন সহ 24টি চ্যানেল মিক্সিং সমর্থন করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
- [5.7/H-1-2] নীচের বিষয়বস্তু ডিক্রিপশন ক্ষমতা সহ
MediaDrm.SECURITY_LEVEL_HW_SECURE_ALL
সমর্থন করতে হবে।
ন্যূনতম নমুনার আকার | 4 MiB |
সাবস্যাম্পলের ন্যূনতম সংখ্যা - H264 বা HEVC | 32 |
ন্যূনতম সাব নমুনার সংখ্যা - VP9 | 9 |
ন্যূনতম সাবস্যাম্পেল সংখ্যা - AV1 | 288 |
ন্যূনতম সাবস্যাম্পল বাফার সাইজ | 1 MiB |
ন্যূনতম জেনেরিক ক্রিপ্টো বাফার আকার | 500 KiB |
সমবর্তী সেশনের ন্যূনতম সংখ্যা | 30 |
প্রতি সেশনে কীগুলির ন্যূনতম সংখ্যা | 20 |
ন্যূনতম মোট কী সংখ্যা (সমস্ত সেশন) | 80 |
DRM কীগুলির ন্যূনতম মোট সংখ্যা (সমস্ত সেশন) | 6 |
বার্তার আকার | 16 কিবি |
প্রতি সেকেন্ডে ডিক্রিপ্ট করা ফ্রেম | 60 FPS |
- [5.1/H-1-17] AVIF বেসলাইন প্রোফাইল সমর্থনকারী কমপক্ষে 1টি হার্ডওয়্যার ইমেজ ডিকোডার থাকতে হবে।
- [5.1/H-1-18] AV1 এনকোডারকে অবশ্যই সমর্থন করতে হবে যা 30fps এবং 1Mbps এ 480p রেজোলিউশন পর্যন্ত এনকোড করতে পারে।
-
[5.12/H-1-1] অবশ্যই[5.12/H-SR] ডিভাইসে উপস্থিত সমস্ত হার্ডওয়্যার AV1 এবং HEVC এনকোডারগুলির জন্যFeature_HdrEditing
বৈশিষ্ট্য সমর্থন করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়। - [5.12/H-1-2] ডিভাইসে উপস্থিত সমস্ত হার্ডওয়্যার AV1 এবং HEVC এনকোডারের জন্য RGBA_1010102 কালার ফরম্যাট সমর্থন করতে হবে।
- [5.12/H-1-3] 8 এবং 10-বিট উভয় ক্ষেত্রেই YUV টেক্সচার থেকে নমুনার জন্য EXT_YUV_target এক্সটেনশনের সমর্থনের বিজ্ঞাপন দিতে হবে।
- [7.1.4/H-1-1] ডেটা প্রসেসিং ইউনিট (DPU) হার্ডওয়্যার কম্পোজার (HWC) তে কমপক্ষে 6টি হার্ডওয়্যার ওভারলে থাকতে হবে, যার মধ্যে কমপক্ষে 2টি 10-বিট ভিডিও সামগ্রী প্রদর্শন করতে সক্ষম।
যদি হ্যান্ডহেল্ড ডিভাইস বাস্তবায়ন android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
এর জন্য android.os.Build.VERSION_CODES.U
ফেরত দেয় এবং তারা একটি হার্ডওয়্যার AVC বা HEVC এনকোডারের জন্য সমর্থন অন্তর্ভুক্ত করে, তাহলে তারা:
- [5.2/H-2-1] হার্ডওয়্যার AVC এবং HEVC কোডেকগুলির জন্য ভিডিও এনকোডার রেট-ডিস্টরশন কার্ভ দ্বারা সংজ্ঞায়িত ন্যূনতম মানের লক্ষ্য পূরণ করতে হবে, যেমন আসন্ন ডকুমেন্টেশনে সংজ্ঞায়িত করা হয়েছে।
রিভিশন দেখুন
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
এর জন্য android.os.Build.VERSION_CODES.U
ফেরত দেয়, তাহলে তারা:- [ 7.5 /H-1-1] 4k@30fps এ ভিডিও ক্যাপচার সমর্থনকারী কমপক্ষে 12 মেগাপিক্সেলের রেজোলিউশন সহ একটি প্রাথমিক রিয়ার ফেসিং ক্যামেরা থাকতে হবে। প্রাইমারি রিয়ার-ফেসিং ক্যামেরা হল সবচেয়ে কম ক্যামেরা আইডি সহ রিয়ার-ফেসিং ক্যামেরা।
- [ 7.5 /H-1-2] কমপক্ষে 6 মেগাপিক্সেলের রেজোলিউশন সহ একটি প্রাথমিক ফ্রন্ট ফেসিং ক্যামেরা থাকতে হবে এবং 1080p@30fps এ ভিডিও ক্যাপচার সমর্থন করে। প্রাইমারি ফ্রন্ট-ফেসিং ক্যামেরা হল ফ্রন্ট-ফেসিং ক্যামেরা যার সর্বনিম্ন ক্যামেরা আইডি।
- [ 7.5 /H-1-3] উভয় প্রাথমিক ক্যামেরার জন্য
android.info.supportedHardwareLevel
প্রপার্টি সম্পূর্ণ বা ভাল হিসাবে সমর্থন করতে হবে। - [ 7.5 /H-1-4]
CameraMetadata.SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME
সমর্থন করতে হবে। উভয় প্রাথমিক ক্যামেরার জন্য SENSOR_INFO_TIMESTAMP_SOURCE_REALTIME। - [ 7.5 /H-1-5] উভয় প্রাথমিক ক্যামেরার জন্য ITS লাইটিং অবস্থার (3000K) অধীনে CTS ক্যামেরা পারফরম্যান্স টেস্ট দ্বারা পরিমাপ করা 1080p রেজোলিউশনের জন্য camera2 JPEG ক্যাপচার লেটেন্সি < 1000
900ms থাকতে হবে। - [ 7.5 /H-1-6] উভয় প্রাথমিক ক্যামেরার জন্য ITS আলোর অবস্থার (3000K) অধীনে CTS ক্যামেরা পারফরম্যান্স টেস্ট দ্বারা পরিমাপ করা ক্যামেরা2 স্টার্টআপ লেটেন্সি (প্রথম প্রিভিউ ফ্রেমে ক্যামেরা খুলুন) < 500 ms থাকতে হবে।
- [ 7.5 /H-1-8] প্রাথমিক ব্যাক ক্যামেরার জন্য অবশ্যই
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_RAW
এবংandroid.graphics.ImageFormat.RAW_SENSOR
সমর্থন করতে হবে। - [ 7.5 /H-1-9] 720p বা 1080p @ 240fps সমর্থনকারী একটি পিছনের মুখী প্রাথমিক ক্যামেরা থাকতে হবে।
- [ 7.5 /H-1-10] প্রাথমিক ক্যামেরাগুলির জন্য ন্যূনতম ZOOM_RATIO < 1.0 থাকতে হবে যদি একই দিকে মুখ করে একটি আল্ট্রাওয়াইড RGB ক্যামেরা থাকে।
- [ 7.5 /H-1-11] প্রাথমিক ক্যামেরাগুলিতে সমসাময়িক ফ্রন্ট-ব্যাক স্ট্রিমিং প্রয়োগ করতে হবে।
- [ 7.5 /H-1-12] প্রাইমারি ফ্রন্ট এবং প্রাইমারি ব্যাক ক্যামেরা উভয়ের জন্য
CONTROL_VIDEO_STABILIZATION_MODE_PREVIEW_STABILIZATION
সমর্থন করতে হবে। - [ 7.5 /H-1-13] প্রাথমিক ক্যামেরাগুলির জন্য
LOGICAL_MULTI_CAMERA
সক্ষমতা সমর্থন করতে হবে যদি একই দিকের দিকে 1টির বেশি RGB ক্যামেরা থাকে। - [ 7.5 /H-1-14] প্রাইমারি ফ্রন্ট এবং প্রাইমারি ব্যাক ক্যামেরা উভয়ের জন্যই
STREAM_USE_CASE
ক্ষমতা সমর্থন করতে হবে। - [ 7.5 /H-1-15] প্রাথমিক ক্যামেরার জন্য ক্যামেরাএক্স এবং ক্যামেরা2 এক্সটেনশন উভয়ের মাধ্যমে
বোকেহ এবংনাইট মোড এক্সটেনশন সমর্থন করতে হবে। - [ 7.5 /H-1-16] প্রাথমিক ক্যামেরাগুলির জন্য অবশ্যই DYNAMIC_RANGE_TEN_BIT সক্ষমতা সমর্থন করতে হবে৷
- [ 7.5 /H-1-17] প্রাথমিক ক্যামেরাগুলির জন্য অবশ্যই CONTROL_SCENE_MODE_FACE_PRIORITY এবং মুখ সনাক্তকরণ ( STATISTICS_FACE_DETECT_MODE_SIMPLE বা STATISTICS_FACE_DETECT_MODE_FULL ) সমর্থন করতে হবে৷
রিভিশন দেখুন
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
এর জন্য android.os.Build.VERSION_CODES.U
ফেরত দেয়, তাহলে তারা:- [7.1.1.1/H-2-1] কমপক্ষে 1080p এর স্ক্রিন রেজোলিউশন থাকতে হবে।
- [7.1.1.3/H-2-1] কমপক্ষে 400 dpi এর পর্দার ঘনত্ব থাকতে হবে।
- [7.1.1.3/H-3-1] কমপক্ষে 1000 নিট গড় সমর্থন করে এমন একটি HDR ডিসপ্লে থাকতে হবে।
- [7.6.1/H-2-1] কমপক্ষে 8 জিবি শারীরিক মেমরি থাকতে হবে।
রিভিশন দেখুন
android.os.Build.VERSION_CODES.MEDIA_PERFORMANCE_CLASS
এর জন্য android.os.Build.VERSION_CODES.U
ফেরত দেয়, তাহলে তারা:- [8.2/H-1-1] কমপক্ষে 150 MB/s এর একটি ক্রমিক লেখার কর্মক্ষমতা নিশ্চিত করতে হবে।
- [8.2/H-1-2] কমপক্ষে 10 এমবি/সেকেন্ডের একটি র্যান্ডম রাইটিং পারফরম্যান্স নিশ্চিত করতে হবে।
- [8.2/H-1-3] কমপক্ষে 250 MB/s এর একটি অনুক্রমিক পঠন কর্মক্ষমতা নিশ্চিত করতে হবে।
- [8.2/H-1-4] কমপক্ষে 100 MB/s এর র্যান্ডম রিড পারফরম্যান্স নিশ্চিত করতে হবে।
- [8.2/H-1-5] 2x রিড এবং 1x লেখার পারফরম্যান্স কমপক্ষে 50 MB/s এর সাথে একটি সমান্তরাল ক্রমিক পঠন এবং লেখার কর্মক্ষমতা নিশ্চিত করতে হবে।
রিভিশন দেখুন
টেলিভিশন ডিভাইস বাস্তবায়ন অবশ্যই নিম্নলিখিত ভিডিও এনকোডিং ফর্ম্যাটগুলিকে সমর্থন করে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে তাদের উপলব্ধ করা উচিত:
- [ 5.2 /T-0-3] AV1
টেলিভিশন ডিভাইস বাস্তবায়ন অবশ্যই নিম্নলিখিত ভিডিও ডিকোডিং ফর্ম্যাটগুলিকে সমর্থন করে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে তাদের উপলব্ধ করা উচিত:
- [ 5.3.2 /T-0-7] AV1
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়নের একটি নিরাপদ লক স্ক্রীন থাকে এবং এতে এক বা একাধিক ট্রাস্ট এজেন্ট অন্তর্ভুক্ত থাকে, যা TrustAgentService
System API প্রয়োগ করে, তারা:
- [ 9.11.1 /W-1-1] প্রস্তাবিত প্রাথমিক প্রমাণীকরণ পদ্ধতিগুলির একটির (যেমন: পিন, প্যাটার্ন, পাসওয়ার্ড) প্রতি 72 ঘন্টায় একবারের চেয়ে বেশি ঘন ঘন ব্যবহারকারীকে চ্যালেঞ্জ করতে হবে।
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়নে AM/FM ব্রডকাস্ট রেডিওর জন্য সমর্থন অন্তর্ভুক্ত থাকে এবং যেকোন অ্যাপ্লিকেশনের কার্যকারিতা প্রকাশ করে, তারা:
- [ 7.4
.10/A-0-1]FEATURE_BROADCAST_RADIO
এর জন্য সমর্থন ঘোষণা করতে হবে।
একটি বাহ্যিক দৃশ্য ক্যামেরা হল একটি ক্যামেরা যা ডিভাইস বাস্তবায়নের বাইরের দৃশ্যগুলিকে চিত্রিত করে, যেমন রিয়ারভিউ ক্যামেরা।
স্বয়ংচালিত ডিভাইস বাস্তবায়ন:
- এক বা একাধিক বাহ্যিক দৃশ্য ক্যামেরা অন্তর্ভুক্ত করা উচিত।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে একটি বহিরাগত ভিউ ক্যামেরা অন্তর্ভুক্ত থাকে, এই ধরনের ক্যামেরার জন্য, তারা:
- [ 7.5 /A-1-1] অ্যান্ড্রয়েড ক্যামেরা API-এর মাধ্যমে অ্যাক্সেসযোগ্য বাহ্যিক দৃশ্য ক্যামেরা থাকা উচিত নয়, যদি না তারা ক্যামেরার মূল প্রয়োজনীয়তাগুলি মেনে চলে।
- [ 7.5 /A-SR-1] ক্যামেরা প্রিভিউ ঘোরানো বা অনুভূমিকভাবে মিরর না করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
- [ 7.5 /A-SR-2] কমপক্ষে 1.3 মেগাপিক্সেলের রেজোলিউশন থাকার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
- ফিক্সড-ফোকাস বা EDOF (ক্ষেত্রের বর্ধিত গভীরতা) হার্ডওয়্যার থাকতে হবে।
- ক্যামেরা ড্রাইভারে হার্ডওয়্যার অটো-ফোকাস বা সফ্টওয়্যার অটো-ফোকাস লাগানো থাকতে পারে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে এক বা একাধিক বাহ্যিক ভিউ ক্যামেরা এবং লোড এক্সটেরিয়র ভিউ সিস্টেম (EVS) পরিষেবা অন্তর্ভুক্ত থাকে, তাহলে এই ধরনের ক্যামেরার জন্য, তারা:
- [ 7.5 /A-2-1] ক্যামেরা প্রিভিউ ঘোরানো বা অনুভূমিকভাবে মিরর করা উচিত নয়।
স্বয়ংচালিত ডিভাইস বাস্তবায়ন:
- তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ এক বা একাধিক ক্যামেরা অন্তর্ভুক্ত হতে পারে৷
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে কমপক্ষে একটি ক্যামেরা থাকে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করা হয়, তাহলে তারা:
- [ 7.5 /A-3-1] ফিচার ফ্ল্যাগ
android.hardware.camera.any
রিপোর্ট করতে হবে। - [ 7.5 /A-3-2] ক্যামেরাটিকে সিস্টেম ক্যামেরা হিসাবে ঘোষণা করা উচিত নয়।
- বিভাগ 7.5.3 এ বর্ণিত বহিরাগত ক্যামেরা সমর্থন করতে পারে।
- অনুচ্ছেদ 7.5.1- এ বর্ণিত রিয়ার-ফেসিং ক্যামেরাগুলিতে উপলব্ধ বৈশিষ্ট্যগুলি (যেমন অটো-ফোকাস, ইত্যাদি) অন্তর্ভুক্ত থাকতে পারে৷
পিছনের দিকের ক্যামেরার অর্থ হল একটি বিশ্বমুখী ক্যামেরা যা গাড়ির যে কোনও জায়গায় অবস্থিত হতে পারে এবং গাড়ির কেবিনের বাইরের দিকে মুখ করে থাকে; অর্থাৎ, এটি গাড়ির বডির দূরের দিকের দৃশ্যগুলিকে চিত্রিত করে, যেমন পিছনের-ভিউ ক্যামেরা৷
একটি ফ্রন্ট-ফেসিং ক্যামেরা মানে একটি ব্যবহারকারী-মুখী ক্যামেরা যা যানবাহনের যেকোনো স্থানে অবস্থিত হতে পারে এবং গাড়ির কেবিনের ভিতরের দিকে মুখ করে থাকে; এটি ব্যবহারকারীর ছবি, যেমন ভিডিও কনফারেন্সিং এবং অনুরূপ অ্যাপ্লিকেশনের জন্য।
স্বয়ংচালিত ডিভাইস বাস্তবায়ন:
- [7.5/A-SR-1] এক বা একাধিক বিশ্বমুখী ক্যামেরা অন্তর্ভুক্ত করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
- এক বা একাধিক ব্যবহারকারী-মুখী ক্যামেরা অন্তর্ভুক্ত হতে পারে।
- [7.5/A-SR-2] একাধিক ক্যামেরার একযোগে স্ট্রিমিং সমর্থন করার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে কমপক্ষে একটি ক্যামেরা অন্তর্ভুক্ত থাকে যা বিশ্বমুখী হয় তবে এই জাতীয় ক্যামেরার জন্য, তারা:
- [7.5/A-1-1] অবশ্যই ভিত্তিক হতে হবে যাতে ক্যামেরার দীর্ঘ মাত্রা অ্যান্ড্রয়েড অটোমোটিভ সেন্সর অক্ষের XY সমতলের সাথে সারিবদ্ধ হয়।
- [7.5/A-SR-3] স্থির-ফোকাস বা EDOF (ক্ষেত্রের বর্ধিত গভীরতা) হার্ডওয়্যার থাকতে দৃঢ়ভাবে সুপারিশ করা হয়।
- [7.5/A-1-2] সর্বনিম্ন ক্যামেরা আইডি সহ বিশ্বমুখী ক্যামেরা হিসাবে প্রাথমিক বিশ্বমুখী ক্যামেরা থাকতে হবে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে কমপক্ষে একটি ক্যামেরা থাকে যা ব্যবহারকারীর মুখোমুখি হয়, তাহলে এই ধরনের ক্যামেরার জন্য:
- [7.5/A-2-1] প্রাথমিক ব্যবহারকারী-মুখী ক্যামেরাটি অবশ্যই সর্বনিম্ন ক্যামেরা আইডি সহ ব্যবহারকারী-মুখী ক্যামেরা হতে হবে।
- ভিত্তিক হতে পারে যাতে ক্যামেরার দীর্ঘ মাত্রা Android অটোমোটিভ সেন্সর অক্ষের XY সমতলের সাথে সারিবদ্ধ হয়।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে একটি ক্যামেরা অন্তর্ভুক্ত থাকে যা android.hardware.Camera
বা android.hardware.camera2
API এর মাধ্যমে অ্যাক্সেসযোগ্য, তাহলে তারা:
- [7.5/A-3-1] বিভাগ 7.5-এর মূল ক্যামেরার প্রয়োজনীয়তা অবশ্যই মেনে চলতে হবে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে এমন একটি ক্যামেরা অন্তর্ভুক্ত থাকে যা android.hardware.Camera
বা android.hardware.camera2
API এর মাধ্যমে অ্যাক্সেসযোগ্য নয়, তাহলে তারা:
- [7.5/A-4-1] এক্সটেন্ডেড ভিউ সিস্টেম পরিষেবার মাধ্যমে অ্যাক্সেসযোগ্য হতে হবে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে এক্সটেন্ডেড ভিউ সিস্টেম সার্ভিসের মাধ্যমে অ্যাক্সেসযোগ্য এক বা একাধিক ক্যামেরা অন্তর্ভুক্ত থাকে, এই ধরনের ক্যামেরার জন্য, তারা:
- [7.5/A-5-1] ক্যামেরা প্রিভিউ ঘোরানো বা অনুভূমিকভাবে মিরর করা উচিত নয়।
- [7.5/A-SR-4] কমপক্ষে 1.3 মেগাপিক্সেলের রেজোলিউশন থাকার জন্য দৃঢ়ভাবে সুপারিশ করা হয়।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়নে এক বা একাধিক ক্যামেরা অন্তর্ভুক্ত থাকে যা এক্সটেন্ডেড ভিউ সিস্টেম সার্ভিস এবং android.hardware.Camera
বা android.hardware.Camera2
API উভয়ের মাধ্যমে অ্যাক্সেসযোগ্য, তাহলে এই ধরনের ক্যামেরার জন্য, তারা:
- [7.5/A-6-1] একই ক্যামেরা আইডি রিপোর্ট করতে হবে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়ন একটি মালিকানাধীন ক্যামেরা API প্রদান করে, তারা:
- [7.5/A-7-1]
android.hardware.camera2
API বা এক্সটেন্ডেড ভিউ সিস্টেম API ব্যবহার করে এমন একটি ক্যামেরা API প্রয়োগ করতে হবে।
রিভিশন দেখুন
স্বয়ংচালিত ডিভাইস বাস্তবায়ন:
- [ 3.8 /A-0-1] সম্পূর্ণ সেকেন্ডারি ব্যবহারকারী যারা বর্তমান ফোরগ্রাউন্ড ব্যবহারকারী নন তাদের কার্যক্রম চালু করতে এবং যেকোনো ডিসপ্লেতে UI অ্যাক্সেস করার অনুমতি দেওয়া উচিত নয়।
রিভিশন দেখুন
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়ন android.hardware.microphone
ঘোষণা করে, তারা:
- [ 9.8.2 /A-1-1] যখন একটি অ্যাপ মাইক্রোফোন থেকে অডিও ডেটা অ্যাক্সেস করে তখন মাইক্রোফোন সূচকটি অবশ্যই প্রদর্শন করতে হবে, কিন্তু যখন মাইক্রোফোনটি শুধুমাত্র
HotwordDetectionService
,SOURCE_HOTWORD
,ContentCaptureService
বা অনুচ্ছেদে বলা ভূমিকা ধারণকারী অ্যাপগুলি দ্বারা অ্যাক্সেস করা হয় তখন নয়৷ 9.1 CDD শনাক্তকারী [C-4-X] সহ। - [ 9.8.2 /A-1-2] দৃশ্যমান ব্যবহারকারী ইন্টারফেস বা সরাসরি ব্যবহারকারীর মিথস্ক্রিয়া আছে এমন সিস্টেম অ্যাপগুলির জন্য মাইক্রোফোন নির্দেশক লুকানো উচিত নয়৷
- [ 9.8.2 /A-1-3] সেটিংস অ্যাপে মাইক্রোফোন টগল করার জন্য ব্যবহারকারীর সামর্থ্য প্রদান করতে হবে।
যদি স্বয়ংচালিত ডিভাইস বাস্তবায়ন android.hardware.camera.any
ঘোষণা করে, তাহলে তারা:
- [ 9.8.2 /A-2-1] যখন কোনও অ্যাপ লাইভ ক্যামেরা ডেটা অ্যাক্সেস করে তখন অবশ্যই ক্যামেরা সূচকটি প্রদর্শন করতে হবে, কিন্তু যখন ক্যামেরাটি শুধুমাত্র অ্যাপ(গুলি) দ্বারা অ্যাক্সেস করা হচ্ছে , সেকশন 9.1 অনুমতিতে
বলা হয়েছেসেই ভূমিকাগুলি ধারণ করে। CDD শনাক্তকারী [C-4-X][C-3-X]সহ।
- [ 9.8.2 /A-2-3] সেটিংস অ্যাপে ক্যামেরা টগল করার জন্য ব্যবহারকারীর সামর্থ্য প্রদান করতে হবে।
- [ 9.8.2 /A-2-4]
PermissionManager.getIndicatorAppOpUsageData()
থেকে প্রত্যাবর্তিত ক্যামেরা ব্যবহার করে সাম্প্রতিক এবং সক্রিয় অ্যাপগুলিকে তাদের সাথে যুক্ত যেকোন অ্যাট্রিবিউশন বার্তা সহ অবশ্যই প্রদর্শন করতে হবে।
যদি ডিভাইস বাস্তবায়নের একটি নিরাপদ লক স্ক্রীন থাকে এবং এতে এক বা একাধিক ট্রাস্ট এজেন্ট অন্তর্ভুক্ত থাকে, যা TrustAgentService
System API প্রয়োগ করে, তারা:
- [ 9.11.1 /A-1-1] প্রস্তাবিত প্রাথমিক প্রমাণীকরণ পদ্ধতিগুলির একটির জন্য ব্যবহারকারীকে অবশ্যই চ্যালেঞ্জ করতে হবে (যেমন: পিন, প্যাটার্ন, পাসওয়ার্ড) প্রতি 336 ঘন্টায় একবারের চেয়ে বেশি ঘন ঘন।
3. সফটওয়্যার
3.1। পরিচালিত API সামঞ্জস্যতা :
রিভিশন দেখুন
ডিভাইস বাস্তবায়ন:
- [C-0-8] 23-এর কম এপিআই স্তর লক্ষ্য করে অ্যাপ্লিকেশন ইনস্টল করা সমর্থন করবে না।
3.2.3.5। শর্তাধীন আবেদনের উদ্দেশ্য :
রিভিশন দেখুন
যদি ডিভাইস বাস্তবায়ন
android.hardware.nfc.uicc
বাandroid.hardware.nfc.ese
রিপোর্ট করে, তারা:- [সি -19-1] অবশ্যই এনএফসিএডাপ্টারটি প্রয়োগ করতে হবে CA
3.3.1। অ্যাপ্লিকেশন বাইনারি ইন্টারফেস :
সংশোধন দেখুন
ডিভাইস বাস্তবায়ন:
- [সি -0-12] মূল
ভলকান 1.0ভলকান 1.1 ফাংশন প্রতীক, পাশাপাশিVK_KHR_surface
,VK_KHR_android_surface
, vk_khr_swapchain,VK_KHR_swapchain
libvulkan.so
এবংVK_KHR_maintenance1
, এবংVK_KHR_get_physical_device_properties2
_ মনে রাখবেন যে সমস্ত প্রতীক অবশ্যই উপস্থিত থাকতে হবে, বিভাগ 7.1.4.2 প্রতিটি সংশ্লিষ্ট ফাংশনগুলির সম্পূর্ণ বাস্তবায়ন প্রত্যাশিত হওয়ার জন্য প্রয়োজনীয়তাগুলি আরও বিশদভাবে বর্ণনা করে।
- [সি -0-12] মূল
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নে কোনও স্ক্রিন বা ভিডিও আউটপুট অন্তর্ভুক্ত থাকে তবে তারা:
- [সি -1-5]
Settings.THEME_CUSTOMIZATION_OVERLAY_PACKAGES
বর্ণিতFRUIT_SALAD
থিম স্টাইলগুলি ব্যবহার করেandroid.theme.customization.theme_styles
RAINBOW
VIBRANT
প্যালেটগুলিTONAL_SPOT
SPRITZ
EXPRESSIVE
MONOCHROMATIC
.
- [সি -1-5]
সংশোধন দেখুন
বিভাগ 7.2.3 এ বিশদ হিসাবে রিসেন্টস ফাংশন নেভিগেশন কী সহ ডিভাইস বাস্তবায়নগুলি ইন্টারফেসটি পরিবর্তন করে, তারা:
- [সি -১-২] অবশ্যই স্ক্রিনের পিনিং আচরণটি প্রয়োগ করতে হবে এবং বৈশিষ্ট্যটি টগল করতে ব্যবহারকারীকে একটি সেটিংস মেনু সরবরাহ করতে হবে।
3.9.2 পরিচালিত প্রোফাইল সমর্থন :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
android.software.managed_users
ঘোষণা করে তবে তারা:- [সি -১-১০] অবশ্যই অবশ্যই নিশ্চিত করতে হবে যে স্ক্রিনশট ডেটা ওয়ার্ক প্রোফাইল স্টোরেজে সংরক্ষণ করা হয়েছে যখন কোনও স্ক্রিনশটটি
topActivity
উইন্ডো দিয়ে ধরা পড়ে যা ফোকাস রয়েছে (ব্যবহারকারী যে সমস্ত ক্রিয়াকলাপের মধ্যে শেষের সাথে ইন্টারঅ্যাক্ট করেছিলেন) এবং একটি কাজের প্রোফাইলের অন্তর্গত অ্যাপ - [সি -1-11] কাজের প্রোফাইলের জন্য স্ক্রিনশট সংরক্ষণ করার সময় ওয়ার্ক প্রোফাইল অ্যাপ্লিকেশন উইন্ডো/উইন্ডোজ ব্যতীত অন্য কোনও স্ক্রিন সামগ্রী (সিস্টেম বার, বিজ্ঞপ্তি বা কোনও ব্যক্তিগত প্রোফাইল সামগ্রী) ক্যাপচার করা উচিত নয় (ব্যক্তিগত প্রোফাইল ডেটা নিশ্চিত করার জন্য কাজের প্রোফাইলে সংরক্ষণ করা হয়নি)।
- [সি -১-১০] অবশ্যই অবশ্যই নিশ্চিত করতে হবে যে স্ক্রিনশট ডেটা ওয়ার্ক প্রোফাইল স্টোরেজে সংরক্ষণ করা হয়েছে যখন কোনও স্ক্রিনশটটি
3.9.5 ডিভাইস নীতি রেজোলিউশন ফ্রেমওয়ার্ক : নতুন বিভাগ
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
android.software.device_admin
বাandroid.software.managed_users
রিপোর্ট করে, তবে তারা:- [সি -1-1] অবশ্যই এওএসপি ডকুমেন্টেশনে নথিভুক্ত হিসাবে ডিভাইস নীতি দ্বন্দ্বগুলি সমাধান করতে হবে।
5. মাল্টিমিডিয়া সামঞ্জস্যতা
সংশোধন দেখুন
ডিভাইস বাস্তবায়নগুলি অবশ্যই নীচের চিত্র এনকোডিং এনকোডিং সমর্থন করে:
- [সি -0-4] আভিফ
- ডিভাইসগুলি অবশ্যই
BITRATE_MODE_CQ
এবং বেসলাইন প্রোফাইলকে সমর্থন করবে।
- ডিভাইসগুলি অবশ্যই
- [সি -0-4] আভিফ
সংশোধন দেখুন
ডিভাইস বাস্তবায়নগুলি অবশ্যই নিম্নলিখিত চিত্র এনকোডিং ডিকোডিং সমর্থন করে:
[সি -0-7] আভিফ (বেসলাইন প্রোফাইল)
সংশোধন দেখুন
ফর্ম্যাট/কোডেক বিস্তারিত সমর্থিত ফাইল প্রকার/ধারক ফর্ম্যাট জেপিইজি বেস+প্রগতিশীল Jpeg (.jpg) জিআইএফ GIF (.gif) পিএনজি PNG (.png) বিএমপি বিএমপি (.বিএমপি) ওয়েবপি WebP (.webp) কাঁচা এআরডাব্লু (.আরডাব্লু), সিআর 2 (.cr2), ডিএনজি (.ডিএনজি), নেফ (.এনএফ), এনআরডাব্লু (.এনআরডাব্লু), ওআরএফ (.আরএফ), পিইএফ (.পিএফ), আরএএফ (.আরএফ), আরডাব্লু 2 (আরডাব্লু 2 ( .আরডাব্লু 2), এসআরডাব্লু (.এসআরডাব্লু) হাইফ চিত্র, চিত্র সংগ্রহ, চিত্র ক্রম হাইফ (.হাইফ), হাইক (.হিক) অ্যাভিআইএফ (বেসলাইন প্রোফাইল) চিত্র, চিত্র সংগ্রহ, চিত্র সিকোয়েন্স বেসলাইন প্রোফাইল হিফ কনটেইনার (.এভিআইএফ) সংশোধন দেখুন
ফর্ম্যাট/কোডেক বিস্তারিত সমর্থন করতে ফাইল প্রকার/ধারক ফর্ম্যাট H.263 - 3 জিপিপি (.3 জিপি)
- এমপিইজি -4 (.এমপি 4)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
এইচ .264 এভিসি বিশদের জন্য বিভাগ 5.2 এবং 5.3 দেখুন - 3 জিপিপি (.3 জিপি)
- এমপিইজি -4 (.এমপি 4)
- এমপিইজি -২ টিএস (.ts, সন্ধানযোগ্য নয়)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
এইচ .265 এইচইভিসি বিশদের জন্য বিভাগ 5.3 দেখুন - এমপিইজি -4 (.এমপি 4)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
MPEG-2 প্রধান প্রোফাইল - এমপিইজি 2-টিএস (.ts, সন্ধানযোগ্য নয়)
- এমপিইজি -4 (.এমপি 4, কেবল ডিকোড)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
MPEG-4 SP - 3 জিপিপি (.3 জিপি)
- এমপিইজি -4 (.এমপি 4)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
ভিপি 8 বিশদের জন্য বিভাগ 5.2 এবং 5.3 দেখুন - WebM (.webm)
- ম্যাট্রোস্কা (.mkv)
ভিপি 9 বিশদের জন্য বিভাগ 5.3 দেখুন - WebM (.webm)
- ম্যাট্রোস্কা (.mkv)
AV1 বিশদের জন্য বিভাগ 5.2 এবং বিভাগ 5.3 দেখুন - এমপিইজি -4 (.এমপি 4)
- ম্যাট্রোস্কা (.mkv, কেবল ডিকোড)
5.1.10। মিডিয়া কোডেক বৈশিষ্ট্য :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি ভিডিও কোডেকগুলি সমর্থন করে:
- [সি -২-১] সমস্ত ভিডিও কোডেক অবশ্যই কোডেক দ্বারা সমর্থিত হলে নিম্নলিখিত আকারের জন্য অর্জনযোগ্য ফ্রেম রেট ডেটা প্রকাশ করতে হবে:
এসডি (নিম্ন মানের) এসডি (উচ্চ মানের) HD 720p HD 1080p ইউএইচডি ভিডিও রেজল্যুশন - 176 এক্স 144 পিএক্স (এইচ 263, এমপিইজি 2, এমপিইজি 4)
- 352 x 288 পিএক্স (এমপিইজি 4 এনকোডার, এইচ 263, এমপিইজি 2)
- 320 x 180 পিএক্স (ভিপি 8, ভিপি 8)
- 320 x 240 পিএক্স (অন্যান্য)
- 704 এক্স 576 পিএক্স (এইচ 263)
- 640 x 360 পিএক্স (ভিপি 8, ভিপি 9)
- 640 x 480 পিএক্স (এমপিইজি 4 এনকোডার)
- 720 এক্স 480 পিএক্স (অন্যান্য, এভি 1 )
- 1408 x 1152 PX (H263)
- 1280 x 720 পিএক্স (অন্যান্য, এভি 1 )
1920 x 1080 পিএক্স (এমপিইজি 4 ব্যতীত অন্যান্য) 3840 x 2160 পিএক্স (এইচইভিসি, ভিপি 9, এভি 1 ) সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি কোনও ভিডিও এনকোডারকে সমর্থন করে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করে তোলে তবে তারা:- দুটি স্লাইডিং উইন্ডোগুলিরও বেশি হওয়া উচিত নয়, ইন্ট্রাফ্রেম (আই-ফ্রেম) অন্তরগুলির মধ্যে বিটরেটের চেয়ে 15% এরও বেশি।
- 1 সেকেন্ডের স্লাইডিং উইন্ডোতে বিটরেটের চেয়ে 100% এর বেশি হওয়া উচিত নয়।
যদি ডিভাইস বাস্তবায়নগুলি কোনও ভিডিও এনকোডারকে সমর্থন করে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করে তোলে এবং এটি সেট করে
MediaFormat.KEY_BITRATE_MODE
থেকেBITRATE_MODE_VBR
যাতে এনকোডারটি ভেরিয়েবল বিটরেট মোডে কাজ করে, ততক্ষণ যতক্ষণ না এটি ন্যূনতম মানের তলকে প্রভাবিত করে না, এনকোডেড বিট্রেট:-
[সি -5-1] অবশ্যইএকটি স্লাইডিং উইন্ডোর উপরে হওয়া উচিত নয়, ইন্ট্রাফ্রেম (আই-ফ্রেম) অন্তরগুলির মধ্যে বিটরেটের চেয়ে 15% এরও বেশি। -
[সি -5-2] 1 সেকেন্ডের স্লাইডিং উইন্ডোতে বিট্রেটের চেয়ে 100% এর বেশি হওয়া উচিতনয় ।
যদি ডিভাইস বাস্তবায়নগুলি কোনও ভিডিও এনকোডারকে সমর্থন করে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করে তোলে এবং
MediaFormat.KEY_BITRATE_MODE
BITRATE_MODE_CBR
সেট করে তাই এনকোডারটি ধ্রুবক বিটরেট মোডে কাজ করে, তবে এনকোডেড বিটরেট:-
[সি -6-১] অবশ্যই[সি-এসআর -২] দৃ strongly ়ভাবে 1 সেকেন্ডের স্লাইডিং উইন্ডোতে লক্ষ্য বিটরেটের চেয়ে 15% এর বেশি না হওয়ার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়েছে ।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি H.263 এনকোডারগুলিকে সমর্থন করে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করে তোলে তবে তারা:
- [সি -1-1] বেসলাইন প্রোফাইল স্তর 45 ব্যবহার করে কিউসিআইএফ রেজোলিউশন (176 x 144) সমর্থন করতে হবে S এসকিউসিআইএফ রেজোলিউশন al চ্ছিক।
-
সমর্থিত এনকোডারের জন্য গতিশীলভাবে কনফিগারযোগ্য বিটরেটগুলি সমর্থন করা উচিত।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি H.265 কোডেককে সমর্থন করে তবে তারা:
- [সি -1-1] অবশ্যই 512 x 512 রেজোলিউশন পর্যন্ত মূল প্রোফাইল স্তর 3 সমর্থন করতে হবে।
-
নিম্নলিখিত সারণীতে নির্দেশিত হিসাবে এইচডি এনকোডিং প্রোফাইলগুলি সমর্থন করা উচিত। - [সি-এসআর -১] 720 x 480 এসডি প্রোফাইল এবং এইচডি এনকোডিং প্রোফাইলগুলি সমর্থন করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয় যা যদি কোনও হার্ডওয়্যার এনকোডার থাকে তবে নিম্নলিখিত টেবিলে নির্দেশিত হিসাবে।
5.2.6। এভি 1 : নতুন বিভাগ
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি এভি 1 কোডেককে সমর্থন করে তবে তারা:
- [সি -1-1] 8-বিট এবং 10-বিট সামগ্রী সহ প্রধান প্রোফাইলকে সমর্থন করতে হবে।
[সি -১-২] অবশ্যই পারফরম্যান্স ডেটা প্রকাশ করতে হবে অর্থাত্ নীচের সারণীতে সমর্থিত রেজোলিউশনের জন্য
getSupportedFrameRatesFor()
বাgetSupportedPerformancePoints()
এপিআই এর মাধ্যমে পারফরম্যান্স ডেটা রিপোর্ট করতে হবে।[সি -1-3] অবশ্যই এইচডিআর মেটাডেটা গ্রহণ করতে হবে এবং এটি বিটস্ট্রিমে আউটপুট করতে হবে
যদি এভি 1 এনকোডারটি হার্ডওয়্যার ত্বরান্বিত হয়, তবে এটি:
- [সি -২-১] নীচের সারণী থেকে এইচডি 1080 পি এনকোডিং প্রোফাইল পর্যন্ত সমর্থন করতে হবে:
এসডি HD 720p HD 1080p ইউএইচডি ভিডিও রেজল্যুশন 720 এক্স 480 পিএক্স 1280 x 720 পিক্সেল 1920 x 1080 পিক্সেল 3840 x 2160 পিক্সেল ভিডিও ফ্রেম রেট 30 fps 30 fps 30 fps 30 fps ভিডিও বিটরেট 5 এমবিপিএস 8 এমবিপিএস 16 এমবিপিএস 50 Mbps সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি H.263 ডিকোডারকে সমর্থন করে তবে তারা:
- [সি -1-1] অবশ্যই বেসলাইন প্রোফাইল স্তর 30 (সিআইএফ, কিউসিআইএফ এবং এসকিউসিআইএফ রেজোলিউশন @ 30fps 384 কেবিপিএস) এবং স্তর 45 (কিউসিআইএফ এবং এসকিউসিআইএফ রেজোলিউশন @ 30fps 128 কেবিপিএস) সমর্থন করতে হবে।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি AV1 কোডেককে সমর্থন করে তবে তারা:- [সি -1-1] অবশ্যই 10-বিট সামগ্রী সহ প্রোফাইল 0 সমর্থন করতে হবে।
যদি ডিভাইস বাস্তবায়নগুলি AV1 কোডেককে সমর্থন করে এবং এটি তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলব্ধ করে তোলে তবে তারা:
- [সি -1-1] 8-বিট এবং 10-বিট সামগ্রী সহ প্রধান প্রোফাইলকে সমর্থন করতে হবে।
যদি ডিভাইস বাস্তবায়নগুলি একটি হার্ডওয়্যার ত্বরণযুক্ত ডিকোডারের সাথে AV1 কোডেকের জন্য সহায়তা সরবরাহ করে তবে তারা:
- [সি -২-১] অবশ্যই নীচের টেবিল থেকে কমপক্ষে এইচডি 720p ভিডিও ডিকোডিং প্রোফাইলগুলি ডিকোড করতে সক্ষম হতে হবে যখন
Display.getSupportedModes()
দ্বারা প্রতিবেদন করা উচ্চতা। - [সি -২-২] অবশ্যই নীচের টেবিল থেকে কমপক্ষে এইচডি 1080p ভিডিও ডিকোডিং প্রোফাইলগুলি ডিকোড করতে সক্ষম হতে হবে যখন
Display.getSupportedModes()
দ্বারা প্রতিবেদন করা উচ্চতা।
এসডি HD 720p HD 1080p ইউএইচডি ভিডিও রেজল্যুশন 720 এক্স 480 পিএক্স 1280 x 720 পিক্সেল 1920 x 1080 পিক্সেল 3840 x 2160 পিক্সেল ভিডিও ফ্রেম রেট 30 fps 30 fps 30 fps 30 fps ভিডিও বিটরেট 5 এমবিপিএস 8 এমবিপিএস 16 এমবিপিএস 50 Mbps যদি ডিভাইস বাস্তবায়নগুলি মিডিয়া এপিআইগুলির মাধ্যমে এইচডিআর প্রোফাইলকে সমর্থন করে তবে তারা:
- [সি -3-1] বিটস্ট্রিম এবং/অথবা ধারক থেকে এইচডিআর মেটাডেটা নিষ্কাশন এবং আউটপুটকে সমর্থন করতে হবে।
- [সি -3-2] অবশ্যই ডিভাইস স্ক্রিনে বা একটি স্ট্যান্ডার্ড ভিডিও আউটপুট পোর্টে (উদাহরণস্বরূপ, এইচডিএমআই) এইচডিআর সামগ্রীটি সঠিকভাবে প্রদর্শন করতে হবে।
5.4.2। ভয়েস স্বীকৃতির জন্য ক্যাপচার :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
android.hardware.microphone
ঘোষণা করে তবে তারা:- অডিও ইনপুট সংবেদনশীলতা সেট করা উচিত যেমন 1000 হার্জ সাইনোসয়েডাল টোন উত্স 90 ডিবি সাউন্ড প্রেসার লেভেল (এসপিএল) এ খেলেছে (মাইক্রোফোনের পাশ থেকে
30 সেন্টিমিটার দূরত্বেপরিমাপ করা হয়েছে) 1770 এর একটি পরিসরের মধ্যে আরএমএস 2500 এর একটি আদর্শ প্রতিক্রিয়া দেয় এবং ভয়েস রিকগনিশন অডিও উত্সটি রেকর্ড করতে ব্যবহৃত প্রতিটি এবং প্রতিটি মাইক্রোফোনের জন্য 16 বিট -নমুনা (বা -22.35 ডিবি ± 3 ডিবি পূর্ণ স্কেল) এর জন্য 3530।
- অডিও ইনপুট সংবেদনশীলতা সেট করা উচিত যেমন 1000 হার্জ সাইনোসয়েডাল টোন উত্স 90 ডিবি সাউন্ড প্রেসার লেভেল (এসপিএল) এ খেলেছে (মাইক্রোফোনের পাশ থেকে
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
android.hardware.audio.output
বৈশিষ্ট্যটি ঘোষণা করে তবে তারা:- [সি -1-4] অবশ্যই ভাসমান-পয়েন্ট ইনপুট এবং আউটপুট সহ অডিও প্রভাবগুলি সমর্থন করতে হবে।
- [সি -1-5] অবশ্যই নিশ্চিত করতে হবে যে অডিও প্রভাবগুলি মিশ্রার চ্যানেল গণনা পর্যন্ত একাধিক চ্যানেলকে সমর্থন করে যা এফসিসি_লিমিট হিসাবেও পরিচিত।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
android.hardware.audio.output
ঘোষণা করে তবে তাদের দৃ strongly ়ভাবে নিম্নলিখিত প্রয়োজনীয়তাগুলি পূরণ বা অতিক্রম করার জন্য সুপারিশ করা হয়:- [সি-এসআর -4] অডিওট্র্যাক.জেটটাইমস্ট্যাম্প এবং
AAudioStream_getTimestamp
দ্বারা ফিরে আসা আউটপুট টাইমস্ট্যাম্পটি +/- 1 এমএসের সঠিক।
- [সি-এসআর -4] ইনপুট এবং আউটপুট টাইমস্ট্যাম্পগুলির উপর ভিত্তি করে গণনা করা রাউন্ড-ট্রিপ ল্যাটেন্সিগুলি
AAudioStream_getTimestamp
দ্বারা ফিরে এসেছিলAAUDIO_PERFORMANCE_MODE_NONE
এবং ওয়েইটরেস, ওয়েটস-ওয়েটস-এর জন্যAAUDIO_PERFORMANCE_MODE_LOW_LATENCY
জন্য পরিমাপকৃত রাউন্ড ট্রিপ ল্যাটেন্সির 30 টি এমএসসি-র মধ্যে থাকার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
- [সি-এসআর -4] অডিওট্র্যাক.জেটটাইমস্ট্যাম্প এবং
7. হার্ডওয়্যার সামঞ্জস্যতা
সংশোধন দেখুন
অ্যান্ড্রয়েডে এমন সুবিধাগুলি অন্তর্ভুক্ত রয়েছে যা ডিভাইসের জন্য তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি
বিভিন্ন হার্ডওয়্যার কনফিগারেশনে ভালভাবে চালিত হয় তা নিশ্চিত করার জন্য ডিভাইসের জন্য স্বয়ংক্রিয়ভাবে অ্যাপ্লিকেশন সম্পদ এবং ইউআই লেআউটগুলি সামঞ্জস্য করে।হার্ডওয়্যার প্রদর্শন এবং কনফিগারেশন বিভিন্ন। একটি অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে হ'ল একটি ডিসপ্লে স্ক্রিন যা অ্যান্ড্রয়েড বিকাশকারীদের মধ্যে বর্ণিত সমস্ত আচরণ এবং এপিআইগুলিকে প্রয়োগ করে-স্ক্রিন সামঞ্জস্যতা ওভারভিউ , এই বিভাগটি (7.1) এবং এর সাবসেকশনগুলির পাশাপাশি কোনও অতিরিক্ত ডিভাইস-প্রকারের নির্দিষ্ট আচরণগুলি নথিভুক্ত করা হয়েছে বিভাগ 2 এর বিভাগ 2 এ নথিভুক্ত এই সিডিডি।অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে (গুলি) এ যেখানে সমস্ত তৃতীয় পক্ষের অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ অ্যাপ্লিকেশনগুলি চলতে পারে, ডিভাইস বাস্তবায়নগুলি অবশ্যই এই বিভাগে বিশদ হিসাবে এই এপিআই এবং আচরণগুলি যথাযথভাবে প্রয়োগ করতে হবে।নতুন প্রয়োজনীয়তা শুরু করুন
ডিভাইস বাস্তবায়ন:
- [সি -0-1] অবশ্যই ডিফল্টরূপে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি কেবল অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লেগুলিতে রেন্ডার করতে হবে।
এই বিভাগে প্রয়োজনীয়তা দ্বারা উল্লিখিত ইউনিটগুলি নিম্নলিখিত হিসাবে সংজ্ঞায়িত করা হয়েছে:
- শারীরিক তির্যক আকার । প্রদর্শনের আলোকিত অংশের দুটি বিরোধী কোণার মধ্যে ইঞ্চি দূরত্ব।
-
প্রতি ইঞ্চি বিন্দু (ডিপিআই)ঘনত্ব । প্রতি ইঞ্চি (পিপিআই বা ডিপিআই) পিক্সেল হিসাবে প্রকাশিত একটি লিনিয়ার অনুভূমিক বা উল্লম্ব স্প্যান দ্বারা অন্তর্ভুক্ত পিক্সেলের সংখ্যা। যেখানেডিপিআইপিপিআই এবং ডিপিআই মানগুলি তালিকাভুক্ত করা হয়েছে, উভয় অনুভূমিক এবং উল্লম্ব ডিপিআই অবশ্যই তালিকাভুক্ত সীমার মধ্যে পড়তে হবে। - আনুমানিক অনুপাত . পর্দার সংক্ষিপ্ত মাত্রায় দীর্ঘ মাত্রার পিক্সেলের অনুপাত। উদাহরণস্বরূপ, 480x854 পিক্সেলের একটি প্রদর্শন 854/480 = 1.779, বা মোটামুটি "16: 9" হবে।
- ঘনত্ব-স্বতন্ত্র পিক্সেল (ডিপি) ।
একটিভার্চুয়াল পিক্সেল ইউনিট160 ডিপিআই স্ক্রিনস্ক্রিন ঘনত্ব 160 এর মধ্যেস্বাভাবিককরা হয়েছে a ডিপি = (160 / ডি) * পি ।
7.1.1.1। পর্দার আকার এবং আকৃতি :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি
UI_MODE_TYPE_NORMAL
আকারের কনফিগারেশনে সক্ষম স্ক্রিনগুলিকে সমর্থন করে এবং এই স্ক্রিনগুলি রেন্ডার করতে গোলাকার কোণগুলির সাথেঅ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণব্যবহার শারীরিক প্রদর্শন (গুলি) অন্তর্ভুক্ত করে, তারা:- [সি -1-1] অবশ্যই নিশ্চিত করতে হবে যে এই জাতীয় প্রতিটি প্রদর্শনের জন্য নিম্নলিখিত প্রয়োজনীয়তার মধ্যে কমপক্ষে একটির সাথে পূরণ করা হয়েছে:
- বৃত্তাকার কোণগুলির ব্যাসার্ধ 38 ডিপি এর চেয়ে কম বা সমান।
যখন 15 ডিপি বাই 15 ডিপি বক্সটি লজিকাল ডিসপ্লেটির প্রতিটি কোণে নোঙ্গর করা হয়, তখন প্রতিটি বাক্সের কমপক্ষে একটি পিক্সেল স্ক্রিনে দৃশ্যমান।
আয়তক্ষেত্রাকার কোণগুলির সাথে ডিসপ্লে মোডে স্যুইচ করতে ব্যবহারকারীর সামর্থ্য অন্তর্ভুক্ত করা উচিত।
নতুন প্রয়োজনীয়তা শুরু করুন
যদি ডিভাইস বাস্তবায়নগুলি কেবল
NO_KEYS
কীবোর্ড কনফিগারেশনে সক্ষম হয় এবংUI_MODE_TYPE_NORMAL
UI মোড কনফিগারেশনের জন্য সমর্থন প্রতিবেদন করতে চায় তবে তারা:- [সি -4-1] কমপক্ষে 596 ডিপি এক্স 384 ডিপি বা তার বেশি সংখ্যক ডিসপ্লে কাটআউটগুলি বাদ দিয়ে অবশ্যই একটি বিন্যাসের আকার থাকতে হবে।
যদি ডিভাইস বাস্তবায়নে একটি অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে (গুলি) অন্তর্ভুক্ত থাকে যা ভাঁজযোগ্য, বা একাধিক ডিসপ্লে প্যানেলের মধ্যে একটি ভাঁজ কব্জা অন্তর্ভুক্ত করে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি রেন্ডার করার জন্য এই জাতীয় প্রদর্শন (গুলি) উপলব্ধ করে, তারা:
- [সি -২-১] উইন্ডো ম্যানেজার জেটপ্যাক লাইব্রেরি দ্বারা ব্যবহৃত হতে এক্সটেনশন এপিআই বা সিডিকার এপিআইয়ের স্থিতিশীল সংস্করণটির সর্বশেষতম উপলব্ধ স্থিতিশীল সংস্করণটি প্রয়োগ করতে হবে।
যদি ডিভাইস বাস্তবায়নে একটি অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে (গুলি) অন্তর্ভুক্ত থাকে যা ভাঁজযোগ্য, বা একাধিক ডিসপ্লে প্যানেলের মধ্যে একটি ভাঁজ কব্জা অন্তর্ভুক্ত করে এবং যদি কব্জা বা ভাঁজ একটি ফুলস্ক্রিন অ্যাপ্লিকেশন উইন্ডোটি অতিক্রম করে তবে তারা:
- [সি -৩-১] অবশ্যই অ্যাপ্লিকেশনটিতে এক্সটেনশান বা সিডিকার এপিআইয়ের মাধ্যমে অবস্থান, সীমানা এবং কব্জাগুলির বা ভাঁজ করার বিষয়ে রিপোর্ট করতে হবে।
যদি ডিভাইস বাস্তবায়নে এক বা একাধিক অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে অঞ্চলগুলি অন্তর্ভুক্ত থাকে যা ভাঁজযোগ্য, বা একাধিক অ্যান্ড্রয়েড-সামঞ্জস্যপূর্ণ ডিসপ্লে প্যানেল অঞ্চলগুলির মধ্যে একটি ভাঁজ কব্জা অন্তর্ভুক্ত করে এবং অ্যাপ্লিকেশনগুলিতে এই জাতীয় প্রদর্শন অঞ্চলগুলি উপলব্ধ করে তোলে, তারা:
- [সি -4-1] আসন্ন ডকুমেন্টেশনে বর্ণিত হিসাবে উইন্ডো ম্যানেজার এক্সটেনশন এপিআই স্তরের সঠিক সংস্করণটি প্রয়োগ করতে হবে।
7.1.1.2। স্ক্রিন দিক অনুপাত : সরানো হয়েছে
সংশোধন দেখুন
ডিভাইস বাস্তবায়ন:
- [সি -0-1]
ডিফল্টরূপে, ডিভাইস বাস্তবায়নগুলিঅবশ্যইঅ্যান্ড্রয়েড ফ্রেমওয়ার্কের একটি ঘনত্বের প্রতিবেদন করতে হবে যাDENSITY_DEVICE_STABLE
এপিআইয়ের মাধ্যমেDisplayMetrics
তালিকাভুক্ত করা হয় এবং এই মানটিঅবশ্যইপ্রতিটি শারীরিক প্রদর্শনের জন্য একটি স্থির মান হতে হবে ;তবে,তবে ডিভাইসটি প্রাথমিক বুটের পরে সেট করা ব্যবহারকারীর দ্বারা তৈরি ডিসপ্লে কনফিগারেশন পরিবর্তনগুলি অনুসারে একটি পৃথকস্বেচ্ছাসেবী ঘনত্বেরDisplayMetrics.density
রিপোর্ট করতে পারে।
- ডিভাইস বাস্তবায়নগুলি স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্ক ঘনত্বকে সংজ্ঞায়িত করা উচিত যা স্ক্রিনের শারীরিক ঘনত্বের সংখ্যাগতভাবে নিকটতম, যদি না লজিকাল ঘনত্ব ন্যূনতম সমর্থিতের নীচে রিপোর্ট করা স্ক্রিনের আকারকে ধাক্কা দেয়। যদি স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্ক ঘনত্ব যা শারীরিক ঘনত্বের নিকটতম নিকটতম হয় এমন একটি স্ক্রিনের আকারের ফলাফল যা ক্ষুদ্রতম সমর্থিত সামঞ্জস্যপূর্ণ স্ক্রিনের আকার (320 ডিপি প্রস্থ) এর চেয়ে ছোট, তবে ডিভাইস বাস্তবায়নের পরবর্তী নিম্নতম স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্ক ঘনত্বের প্রতিবেদন করা উচিত।
নতুন প্রয়োজনীয়তা শুরু করুন
- স্ট্যান্ডার্ড অ্যান্ড্রয়েড ফ্রেমওয়ার্ক ঘনত্বকে সংজ্ঞায়িত করা উচিত যা স্ক্রিনের শারীরিক ঘনত্বের নিকটতম নিকটতম, বা এমন একটি মান যা হ্যান্ডহেল্ড ডিভাইসের একই সমতুল্য কৌণিক ক্ষেত্রের ভিউ পরিমাপের জন্য মানচিত্র তৈরি করে।
যদি ডিভাইস বাস্তবায়নগুলি সরবরাহ করে তবে ডিভাইসের ডিসপ্লে আকার পরিবর্তন করার জন্য একটি সামর্থ্য
রয়েছে, তারা :- [সি -1-1]
ডিসপ্লে আকারটি অবশ্যই স্কেল করা উচিত নয় অবশ্যই1.5 গুণDENSITY_DEVICE_STABLE
নেটিভ ঘনত্বেরচেয়ে বড় ডিসপ্লে স্কেল করা উচিত নয় বা 320DP এর চেয়ে ছোট একটি কার্যকর ন্যূনতম স্ক্রিন মাত্রা তৈরি করতে হবে (রিসোর্স কোয়ালিফায়ার এসডাব্লু 320 ডিপির সমতুল্য), যেটি প্রথমে আসে। - [সি -১-২]
ডিসপ্লে আকারটি অবশ্যইDENSITY_DEVICE_STABLE
নেটিভ ঘনত্বের0.85 গুণ কম প্রদর্শনটি স্কেল করা উচিত নয় ।
- [সি -0-1]
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নে ভলকান
১.০ বা তার বেশিসমর্থন অন্তর্ভুক্ত থাকে তবে তারা:[সি -1-3] প্রতিটি গণিত
VkPhysicalDevice
জন্যভলকান 1.0ভলকান 1.1 এপিআই সম্পূর্ণরূপে প্রয়োগ করতে হবে।[সি -1-5] অবশ্যই অ্যাপ্লিকেশন প্যাকেজের বাইরের গ্রন্থাগারগুলির দ্বারা সরবরাহিত স্তরগুলি গণনা করা উচিত নয়, বা অ্যাপ্লিকেশনটিতে
android:debuggable
না থাকলে ভলকান এপিআই সন্ধানcom.android.graphics.injectLayers.enable
বাধা দেওয়ার অন্যান্য উপায় সরবরাহtrue
উচিত নয়com.android.graphics.injectLayers.enable
true
-
VkPhysicalDeviceProtectedMemoryFeatures
এবংVK_EXT_global_priority
সমর্থন করা উচিত।
- [সি -1-13] অবশ্যই অ্যান্ড্রয়েড বেসলাইন 2021 প্রোফাইল দ্বারা নির্দিষ্ট প্রয়োজনীয়তাগুলি পূরণ করতে হবে।
[সি-এসআর -5]
VkPhysicalDeviceProtectedMemoryFeatures.protectedMemory
সমর্থন করার জন্য দৃ strongly ়ভাবে সুপারিশVK_EXT_global_priority
হয়।[সি-এসআর -6] এইচডব্লিউআইয়ের সাথে
SkiaVk
ব্যবহার করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
যদি ডিভাইস বাস্তবায়নে ভলকান 1.1 এর সমর্থন অন্তর্ভুক্ত থাকে এবং এখানে বর্ণিত ভলকান বৈশিষ্ট্য পতাকাগুলির কোনও ঘোষণা করুন, তারা:
- [সি-এসআর -7] তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলিতে উপলভ্য
VK_KHR_external_fence_fd
এক্সটেনশানটি তৈরি করার জন্য এবং এখানে বর্ণিত হিসাবে পোজিক্স ফাইল বর্ণনাকারীদের কাছ থেকে বেড়া পে-লোড আমদানি করতে এবং আমদানি করতে অ্যাপ্লিকেশনটিকে সক্ষম করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নের একাধিক বায়োমেট্রিক সেন্সর থাকে তবে তারা:
[সি -7-১] অবশ্যই, যখন কোনও বায়োমেট্রিক লকআউটে থাকে (অর্থাত্ বায়োমেট্রিকটি ব্যবহারকারী প্রাথমিক প্রমাণীকরণের সাথে আনলক না করা পর্যন্ত অক্ষম করা হয়) বা সময়সীমাবদ্ধ লকআউট (অর্থাত্ বায়োমেট্রিক অস্থায়ীভাবে অক্ষম না হওয়া পর্যন্ত ব্যবহারকারী একটি সময়ের ব্যবধানের জন্য অপেক্ষা না করা পর্যন্ত) অনেকগুলি ব্যর্থ প্রচেষ্টার কারণে, নিম্ন বায়োমেট্রিক শ্রেণীর অন্যান্য সমস্ত বায়োমেট্রিকগুলি লক আউট করুন। সময়সীমার লকআউটের ক্ষেত্রে, বায়োমেট্রিক যাচাইয়ের ব্যাকঅফ সময়টি সময়সীমার লকআউটে সমস্ত বায়োমেট্রিকের সর্বাধিক ব্যাক অফের সময় হতে হবে।
[সি-এসআর -12] দৃ strongly ়ভাবে সুপারিশ করা হয়, যখন কোনও বায়োমেট্রিক লকআউটে থাকে (অর্থাত্ বায়োমেট্রিক ব্যবহারকারী প্রাথমিক প্রমাণীকরণের সাথে আনলক না করা পর্যন্ত) বা সময়সীমাবদ্ধ লকআউট (অর্থাত্ বায়োমেট্রিক অস্থায়ীভাবে অক্ষম না হওয়া পর্যন্ত ব্যবহারকারী কিছু সময়ের জন্য অপেক্ষা না করা অবধি অক্ষম থাকে বিরতি) একই বায়োমেট্রিক শ্রেণীর অন্যান্য সমস্ত বায়োমেট্রিক্স লক আউট করার জন্য অনেকগুলি ব্যর্থ প্রচেষ্টার কারণে। সময়সীমাবদ্ধ লকআউটের ক্ষেত্রে, বায়োমেট্রিক যাচাইয়ের ব্যাকঅফ সময়টি সময়সীমাবদ্ধ লকআউটে সমস্ত বায়োমেট্রিকের সর্বাধিক ব্যাক অফের সময় হওয়ার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
[সি -7-২] বায়োমেট্রিক লক আউট হওয়ার জন্য লকআউট কাউন্টারটি পুনরায় সেট করতে প্রস্তাবিত প্রাথমিক প্রমাণীকরণের (যেমন: পিন, প্যাটার্ন, পাসওয়ার্ড) জন্য ব্যবহারকারীকে চ্যালেঞ্জ জানাতে হবে। ক্লাস 3 বায়োমেট্রিক্সকে একই বা নিম্ন শ্রেণীর লক করা বায়োমেট্রিকের জন্য লকআউট কাউন্টারটি পুনরায় সেট করার অনুমতি দেওয়া যেতে পারে। ক্লাস 2 বা ক্লাস 1 বায়োমেট্রিক্সকে কোনও বায়োমেট্রিক্সের জন্য রিসেট লকআউট অপারেশন সম্পূর্ণ করার অনুমতি দেওয়া উচিত নয়।
যদি ডিভাইস বাস্তবায়নগুলি কোনও বায়োমেট্রিক সেন্সরকে ক্লাস 1 (পূর্বে সুবিধা ) হিসাবে বিবেচনা করতে চায় তবে তারা:
[সি -১-১২] অ্যান্ড্রয়েড বায়োমেট্রিক্স টেস্ট প্রোটোকল দ্বারা পরিমাপকৃত হিসাবে উপস্থাপনা আক্রমণ যন্ত্র (পিএআই) প্রজাতির প্রতি 40% এর চেয়ে বেশি নয় এমন একটি স্পুফ এবং ইমপোস্টার গ্রহণযোগ্যতার হার থাকতে হবে।
[সি-এসআর -13] অ্যান্ড্রয়েড বায়োমেট্রিক্স টেস্ট প্রোটোকলগুলি দ্বারা পরিমাপ করা হিসাবে উপস্থাপনা আক্রমণ উপকরণ (পিএআই) প্রজাতির প্রতি 30% এর চেয়ে বেশি নয় এমন একটি স্পুফ এবং ইমপোস্টার গ্রহণযোগ্যতার হার রাখার দৃ strongly ়ভাবে সুপারিশ করা হয়।
[সি-এসআর -14] বায়োমেট্রিক সেন্সরের বায়োমেট্রিক শ্রেণি এবং এটি সক্ষম করার সম্পর্কিত ঝুঁকিগুলি প্রকাশ করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
[সি-এসআর -17] নতুন এইডএল ইন্টারফেসগুলি (যেমন,
IFace.aidl
এবংIFingerprint.aidl
) বাস্তবায়নের জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
যদি ডিভাইস বাস্তবায়নগুলি কোনও বায়োমেট্রিক সেন্সরটিকে ক্লাস 2 (পূর্বে দুর্বল ) হিসাবে বিবেচনা করতে চায় তবে তারা:
- [সি-এসআর -15] অ্যান্ড্রয়েড বায়োমেট্রিক্স টেস্ট প্রোটোকল দ্বারা পরিমাপকৃত হিসাবে উপস্থাপনা আক্রমণ যন্ত্র (পিএআই) প্রজাতির প্রতি 20% এর চেয়ে বেশি নয় এমন একটি স্পুফ এবং ইমপোস্টার গ্রহণযোগ্যতার হার রাখার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়।
- [সি -২-৩] অ্যান্ড্রয়েড ব্যবহারকারী বা কার্নেল স্পেসের বাইরে যেমন বিশ্বস্ত এক্সিকিউশন এনভায়রনমেন্ট (টিইই) (টিইই) এর বাইরে,
বাবিচ্ছিন্ন এক্সিকিউশন পরিবেশে বা সুরক্ষিত সুরক্ষিত চ্যানেল সহ একটি চিপে বায়োমেট্রিক ম্যাচিং সম্পাদন করতে হবে ভার্চুয়াল মেশিন যা বিভাগ 9.17 এ প্রয়োজনীয়তা পূরণ করে । - [সি -২-৪] অবশ্যই সমস্ত সনাক্তযোগ্য ডেটা এনক্রিপ্ট করা এবং ক্রিপ্টোগ্রাফিকভাবে প্রমাণীকরণ করতে হবে যাতে তারা বিচ্ছিন্ন সম্পাদনের পরিবেশের বাইরে বা বিচ্ছিন্ন সম্পাদন পরিবেশের একটি সুরক্ষিত চ্যানেল সহ একটি চিপের বাইরে অর্জিত, পড়তে বা পরিবর্তন করা যায় না বা বাস্তবায়ন নির্দেশিকাগুলিতে নথিভুক্ত করা যায় অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট সাইটে বা হাইপারভাইজার দ্বারা নিয়ন্ত্রিত একটি সুরক্ষিত ভার্চুয়াল মেশিন যা বিভাগ 9.17 এ প্রয়োজনীয়তা পূরণ করে ।
- [সি -2-5] ক্যামেরা ভিত্তিক বায়োমেট্রিক্সের জন্য, যখন বায়োমেট্রিক ভিত্তিক প্রমাণীকরণ বা তালিকাভুক্তি ঘটছে:
- অবশ্যই ক্যামেরাটি এমন একটি মোডে পরিচালনা করতে হবে যা ক্যামেরা ফ্রেমগুলিকে বিচ্ছিন্ন এক্সিকিউশন পরিবেশের বাইরে পড়তে বা পরিবর্তন করা থেকে বাধা দেয় বা বিচ্ছিন্ন এক্সিকিউশন পরিবেশের সুরক্ষিত চ্যানেল সহ একটি চিপ বা হাইপারভাইজার দ্বারা নিয়ন্ত্রিত একটি সুরক্ষিত ভার্চুয়াল মেশিন যা বিভাগ 9.17 -এ প্রয়োজনীয়তা পূরণ করে ।
- আরজিবি সিঙ্গল-ক্যামেরা সমাধানগুলির জন্য, নথিভুক্তির জন্য পূর্বরূপের মতো অপারেশনগুলিকে সমর্থন করার জন্য ক্যামেরা ফ্রেমগুলি বিচ্ছিন্ন সম্পাদন পরিবেশের বাইরে পাঠযোগ্য হতে পারে, তবে এখনও অবশ্যই পরিবর্তনযোগ্য হবে না।
- [সি -২-7] অবশ্যই টিইয়ের প্রসঙ্গে বা বিভাগে নিয়ন্ত্রিত সুরক্ষিত ভার্চুয়াল মেশিন যা বিভাগে নিয়ন্ত্রিত সুরক্ষিত ভার্চুয়াল মেশিনে অ্যাপ্লিকেশন প্রসেসরের কাছে সনাক্তকরণযোগ্য বায়োমেট্রিক ডেটা বা এটি থেকে প্রাপ্ত কোনও ডেটা (যেমন এম্বেডিংস) থেকে প্রাপ্ত কোনও ডেটা অ্যাক্সেসের অনুমতি দিতে হবে না 9.17 । অ্যান্ড্রয়েড সংস্করণ 9 বা তার আগে চালু হওয়া আপগ্রেড করা ডিভাইসগুলি সি -2-7 থেকে ছাড় দেওয়া হয় না।
যদি ডিভাইস বাস্তবায়নগুলি কোনও বায়োমেট্রিক সেন্সরকে ক্লাস 3 (পূর্বে শক্তিশালী ) হিসাবে বিবেচনা করতে চায় তবে তারা:
- [সি-এসআর -16] অ্যান্ড্রয়েড বায়োমেট্রিক্স টেস্ট প্রোটোকলগুলি দ্বারা পরিমাপ করা হিসাবে উপস্থাপনা আক্রমণ উপকরণ (পিএআই) প্রজাতির প্রতি 7% এর চেয়ে বেশি নয় এমন একটি স্পুফ এবং ইমপোস্টার গ্রহণযোগ্যতার হার রাখার দৃ strongly ়ভাবে সুপারিশ করা হয়।
7.3.13। আইইইই 802.1.15.4 (ইউডাব্লুবি) :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নে 802.1.15.4 এর জন্য সমর্থন অন্তর্ভুক্ত থাকে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনটিতে কার্যকারিতাটি প্রকাশ করে, তারা:
- [সি -1-2] অবশ্যই হার্ডওয়্যার বৈশিষ্ট্যটি
android.hardware.uwb
বৈশিষ্ট্যটি প্রতিবেদন করতে হবে। - [সি -১-৩] এওএসপি বাস্তবায়নে সংজ্ঞায়িত সমস্ত নিম্নলিখিত কনফিগারেশন সেটগুলি ( এফআইআরএ ইউসিআই প্যারামিটারগুলির প্রাক-সংজ্ঞায়িত সংমিশ্রণ) সমর্থন করতে হবে।
-
CONFIG_ID_1
: এফআইআরএ-সংজ্ঞায়িত ইউনিকাস্টSTATIC STS DS-TWR
রেঞ্জিং, মুলতুবি মোড, রঞ্জিং ইন্টারভাল 240 এমএস। -
CONFIG_ID_2
: এফআইআরএ-সংজ্ঞায়িত ওয়ান-টু-অনেকগুলিSTATIC STS DS-TWR
রেঞ্জিং, মুলতুবি মোড, অন্তর অন্তর 200 এমএস। সাধারণ ব্যবহারের ক্ষেত্রে: স্মার্ট ফোন অনেক স্মার্ট ডিভাইসের সাথে ইন্টারেক্ট করে। -
CONFIG_ID_3
:CONFIG_ID_1
হিসাবে একই, অ্যাঙ্গেল-অফ-অ্যারিভাল (এওএ) ডেটা ব্যতীত রিপোর্ট করা হয়নি। -
CONFIG_ID_4
: পি-এসটিএস সুরক্ষা মোড ব্যতীতCONFIG_ID_1
হিসাবে একই। -
CONFIG_ID_5
: পি-এসটিএস সুরক্ষা মোড ব্যতীতCONFIG_ID_2
হিসাবে একই। -
CONFIG_ID_6
: পি-এসটিএস সুরক্ষা মোড ব্যতীতCONFIG_ID_3
হিসাবে একই। -
CONFIG_ID_7
: পি-এসটিএস পৃথক কন্ট্রোলি কী মোড ব্যতীতCONFIG_ID_2
হিসাবে একই।
-
- [সি -1-4] ব্যবহারকারীকে ইউডাব্লুবি রেডিওটি অন/অফ স্টেটে টগল করার অনুমতি দেওয়ার জন্য অবশ্যই একটি ব্যবহারকারীর সাশ্রয়ীতা সরবরাহ করতে হবে।
- [সি -1-5] অবশ্যই কার্যকর করতে হবে যে ইউডাব্লুবি রেডিও ব্যবহার করে অ্যাপ্লিকেশনগুলি
UWB_RANGING
অনুমতি (NEARBY_DEVICES
অনুমতি গোষ্ঠীর অধীনে) ধরে রাখে।
এফআইআরএ , সিসিসি এবং সিএসএ সহ স্ট্যান্ডার্ড সংস্থাগুলি দ্বারা সংজ্ঞায়িত প্রাসঙ্গিক কনফরমেশন এবং শংসাপত্র পরীক্ষাগুলি পাস করা 802.1.15.4 ফাংশন সঠিকভাবে নিশ্চিত করতে সহায়তা করে।
- [সি -1-2] অবশ্যই হার্ডওয়্যার বৈশিষ্ট্যটি
সংশোধন দেখুন
অ্যান্ড্রয়েড এপিআই দ্বারা ব্যবহৃত "টেলিফোনি" এবং এই দস্তাবেজটি বিশেষত ভয়েস কল স্থাপন এবং এসএমএস বার্তা প্রেরণ , বা একটি মোবাইল (যেমন জিএসএম, সিডিএমএ, এলটিই, এনআর) জিএসএম বা সিডিএমএ নেটওয়ার্কের মাধ্যমে মোবাইল ডেটা স্থাপনের সাথে সম্পর্কিত হার্ডওয়্যারকে বোঝায়। "টেলিফোনি" সমর্থনকারী একটি ডিভাইস পণ্যটির সাথে ফিট করে কিছু বা সমস্ত কল, মেসেজিং এবং ডেটা পরিষেবা সরবরাহ করতে বেছে নিতে পারে।
একটি জিএসএম বা সিডিএমএ নেটওয়ার্কের মাধ্যমে। যদিও এই ভয়েস কলগুলি প্যাকেট-স্যুইচড হতে পারে বা নাও হতে পারে তবে এগুলি অ্যান্ড্রয়েডের উদ্দেশ্যে যে কোনও ডেটা সংযোগের চেয়ে স্বতন্ত্র বিবেচিত যা একই নেটওয়ার্ক ব্যবহার করে প্রয়োগ করা যেতে পারে। অন্য কথায়, অ্যান্ড্রয়েড "টেলিফোনি" কার্যকারিতা এবং এপিআইগুলি বিশেষত ভয়েস কল এবং এসএমএসকে উল্লেখ করে। উদাহরণস্বরূপ, ডিভাইস বাস্তবায়নগুলি যেগুলি এসএমএস বার্তাগুলি কল করতে বা প্রেরণ/গ্রহণ করতে পারে না তারা ডেটা সংযোগের জন্য সেলুলার নেটওয়ার্ক ব্যবহার করে কিনা তা নির্বিশেষে টেলিফোনি ডিভাইস হিসাবে বিবেচিত হয় না।7.4.2। আইইইই 802.11 (ওয়াই-ফাই) :
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নে 802.11 এর জন্য সমর্থন অন্তর্ভুক্ত থাকে এবং তৃতীয় পক্ষের অ্যাপ্লিকেশনটিতে কার্যকারিতাটি প্রকাশ করে, তারা:
- [সি -1-4] অবশ্যই মাল্টিকাস্ট ডিএনএস (এমডিএনএস) সমর্থন করতে হবে এবং অপারেশনের যে কোনও সময় এমডিএনএস প্যাকেটগুলি (224.0.0.251 বা এফএফ 02 :: এফবি ) ফিল্টার করা উচিত নয়, যখন স্ক্রিনটি কোনও সক্রিয় অবস্থায় নেই, যদি না বাদ দিয়ে বা না হয় লক্ষ্য বাজারে প্রযোজ্য নিয়ন্ত্রক প্রয়োজনীয়তার দ্বারা প্রয়োজনীয় বিদ্যুৎ খরচ রেঞ্জের মধ্যে থাকার জন্য এই প্যাকেটগুলি ফিল্টার করা প্রয়োজনীয়।
অ্যান্ড্রয়েড টেলিভিশন ডিভাইস বাস্তবায়নের জন্য, এমনকি স্ট্যান্ডবাই পাওয়ার স্টেটগুলিতে থাকা অবস্থায়ও।
- [সি -1-4] অবশ্যই মাল্টিকাস্ট ডিএনএস (এমডিএনএস) সমর্থন করতে হবে এবং অপারেশনের যে কোনও সময় এমডিএনএস প্যাকেটগুলি (224.0.0.251 বা এফএফ 02 :: এফবি ) ফিল্টার করা উচিত নয়, যখন স্ক্রিনটি কোনও সক্রিয় অবস্থায় নেই, যদি না বাদ দিয়ে বা না হয় লক্ষ্য বাজারে প্রযোজ্য নিয়ন্ত্রক প্রয়োজনীয়তার দ্বারা প্রয়োজনীয় বিদ্যুৎ খরচ রেঞ্জের মধ্যে থাকার জন্য এই প্যাকেটগুলি ফিল্টার করা প্রয়োজনীয়।
সংশোধন দেখুন
যদি ডিভাইস বাস্তবায়নগুলি বৈশিষ্ট্য_ব্লুটাথ_লে ঘোষণা করে তবে তারা:
- [সি-এসআর -২] আরএক্স অফসেটের জন্য পরিমাপ ও ক্ষতিপূরণ
ADVERTISE_TX_POWER_HIGH
জন্য দৃ strongly একই দিকের মুখোমুখি পর্দার সাথে 'সমান্তরাল প্লেনস' এ। - [সি-এসআর -3] মিডিয়ান বিএলই আরএসএসআই
ADVERTISE_TX_POWER_HIGH
ডিবিএম +/- 10 ডিবি হয় তা নিশ্চিত করার জন্য টিএক্স অফসেটের জন্য পরিমাপ ও ক্ষতিপূরণ দেওয়ার জন্য দৃ strongly যেমন তারা একই দিকের মুখোমুখি পর্দার সাথে 'সমান্তরাল বিমানগুলিতে' রয়েছে।
- [সি -10-3] মিডিয়ান বিএলই আরএসএসআই -55 ডিবিএম +/- 10 ডিবি আইএস -55 ডিবিএম +/- 10 ডিবি
ADVERTISE_TX_POWER_HIGH
সংক্রমণকারী একটি রেফারেন্স ডিভাইস থেকে 1 মি দূরত্বে 1 এম দূরত্বে নিশ্চিত করতে আরএক্স অফসেটের জন্য পরিমাপ ও ক্ষতিপূরণ দিতে হবে। - [সি -10-4] মিডিয়ান বিএলই আরএসএসআই -55 ডিবিএম +/- 10 ডিবি হয় তা নিশ্চিত করতে টিএক্স অফসেটের জন্য পরিমাপ ও ক্ষতিপূরণ দিতে হবে যখন 1 এম দূরত্বে অবস্থিত একটি রেফারেন্স ডিভাইস থেকে স্ক্যান করা এবং
ADVERTISE_TX_POWER_HIGH
সংক্রমণ করে।
যদি ডিভাইস বাস্তবায়নগুলি ব্লুটুথ সংস্করণ 5.0 সমর্থন করে তবে তারা:
- [সি-এসআর -4] এর জন্য সমর্থন সরবরাহ করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয়:
- লে 2 মি ফাই
- লে কোডেক ফাই
- লে বিজ্ঞাপন এক্সটেনশন
- পর্যায়ক্রমিক বিজ্ঞাপন
- কমপক্ষে 10 বিজ্ঞাপন সেট
- কমপক্ষে 8 লে সমবর্তী সংযোগগুলি। প্রতিটি সংযোগ উভয় সংযোগ টপোলজির ভূমিকাতে থাকতে পারে।
- লে লিঙ্ক স্তর গোপনীয়তা
- কমপক্ষে 8 টি এন্ট্রিগুলির একটি "সমাধান তালিকা" আকার
- [সি-এসআর -২] আরএক্স অফসেটের জন্য পরিমাপ ও ক্ষতিপূরণ
সংশোধন দেখুন
- [সি -1-7] অবশ্যই নিশ্চিত করতে হবে যে রেফারেন্স ডিভাইস থেকে 1 মিটার দূরত্বের পরিমাপের মাঝারিটি [0.75 মিটার, 1.25 মিটার] এর মধ্যে রয়েছে, যেখানে স্থল সত্যের দূরত্বটি ডিইটি-র শীর্ষ প্রান্ত থেকে পরিমাপ করা হয়।
ফেস আপ এবং 45 ডিগ্রি কাত করা।
- [সি -1-7] অবশ্যই নিশ্চিত করতে হবে যে রেফারেন্স ডিভাইস থেকে 1 মিটার দূরত্বের পরিমাপের মাঝারিটি [0.75 মিটার, 1.25 মিটার] এর মধ্যে রয়েছে, যেখানে স্থল সত্যের দূরত্বটি ডিইটি-র শীর্ষ প্রান্ত থেকে পরিমাপ করা হয়।
7.5.1। রিয়ার-ফেসিং ক্যামেরা :
সংশোধন দেখুন
একটি রিয়ার-ফেসিং ক্যামেরা হ'ল একটি ক্যামেরা যা প্রদর্শনের বিপরীতে ডিভাইসের পাশে অবস্থিত; এটি হ'ল এটি ডিভাইসের দূরবর্তী দিকে একটি traditional তিহ্যবাহী ক্যামেরার মতো দৃশ্যের চিত্র দেয়।
একটি রিয়ার-ফেসিং ক্যামেরা হ'ল একটি বিশ্বমুখী ক্যামেরা যা ডিভাইসের দূরবর্তী দিকে traditional তিহ্যবাহী ক্যামেরার মতো চিত্রগুলি চিত্র দেয়; হ্যান্ডহেল্ড ডিভাইসে, এটি প্রদর্শনের বিপরীতে ডিভাইসের পাশে অবস্থিত একটি ক্যামেরা।
7.5.2। সামনের মুখের ক্যামেরা :
সংশোধন দেখুন
একটি সামনের মুখী ক্যামেরা হ'ল একটি ক্যামেরা যা ডিভাইসের একই পাশে প্রদর্শিত হয়; এটি হ'ল, একটি ক্যামেরা সাধারণত ব্যবহারকারীকে চিত্রিত করতে ব্যবহৃত হয় যেমন ভিডিও কনফারেন্সিং এবং অনুরূপ অ্যাপ্লিকেশনগুলির জন্য।
একটি সামনের মুখোমুখি ক্যামেরা হ'ল একটি ব্যবহারকারী-মুখী ক্যামেরা যা সাধারণত ব্যবহারকারীকে চিত্রিত করতে ব্যবহৃত হয় যেমন ভিডিও কনফারেন্সিং এবং অনুরূপ অ্যাপ্লিকেশনগুলির জন্য; হ্যান্ডহেল্ড ডিভাইসে, এটি প্রদর্শনের মতো ডিভাইসের একই পাশে অবস্থিত একটি ক্যামেরা।
সংশোধন দেখুন
একটি বাহ্যিক ক্যামেরা এমন একটি ক্যামেরা যা যে কোনও সময় ডিভাইস বাস্তবায়ন থেকে শারীরিকভাবে সংযুক্ত বা বিচ্ছিন্ন হতে পারে এবং যে কোনও দিকের মুখোমুখি হতে পারে; যেমন ইউএসবি ক্যামেরা।
সংশোধন দেখুন
ডিভাইস বাস্তবায়নগুলি অবশ্যই সমস্ত উপলব্ধ ক্যামেরার জন্য ক্যামেরা সম্পর্কিত এপিআইগুলির জন্য নিম্নলিখিত আচরণগুলি প্রয়োগ করতে হবে। ডিভাইস বাস্তবায়ন:
- [সি-এসআর -১] একাধিক আরজিবি ক্যামেরা সহ নিকটবর্তী এবং একই দিকে মুখোমুখি ডিভাইসগুলির জন্য, এটি একটি লজিকাল ক্যামেরা ডিভাইস সমর্থন করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয় যা সামর্থ্য
CameraMetadata.REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
তালিকাভুক্ত করে R শারীরিক উপ-ডিভাইস হিসাবে।
- [সি-এসআর -১] একাধিক আরজিবি ক্যামেরা সহ নিকটবর্তী এবং একই দিকে মুখোমুখি ডিভাইসগুলির জন্য, এটি একটি লজিকাল ক্যামেরা ডিভাইস সমর্থন করার জন্য দৃ strongly ়ভাবে সুপারিশ করা হয় যা সামর্থ্য
7.5.5। ক্যামেরা ওরিয়েন্টেশন :
সংশোধন দেখুন
নিম্নলিখিত সমস্ত মানদণ্ড পূরণ করে এমন ডিভাইসগুলি উপরের প্রয়োজনীয়তা থেকে অব্যাহতিপ্রাপ্ত:
- ডিভাইস বাস্তবায়ন যা স্বয়ংচালিত ডিভাইসগুলির মতো ব্যবহারকারী দ্বারা ঘোরানো সক্ষম নয়।
সংশোধন দেখুন
হ্যান্ড-হোল্ড বা জীর্ণ হওয়ার উদ্দেশ্যে করা ডিভাইসগুলিতে একটি সাধারণ উদ্দেশ্য হ্যাপটিক অ্যাকিউউটর অন্তর্ভুক্ত থাকতে পারে, যা রিংটোন, অ্যালার্ম, বিজ্ঞপ্তিগুলি, পাশাপাশি সাধারণ স্পর্শ প্রতিক্রিয়াগুলির মাধ্যমে মনোযোগ পাওয়া সহ অ্যাপ্লিকেশনগুলিতে উপলব্ধ।
যদি ডিভাইস বাস্তবায়নে এমন সাধারণ উদ্দেশ্য হ্যাপটিক অ্যাকিউউটর অন্তর্ভুক্ত না হয় তবে তারা:
- [7.10/সি]
Vibrator.hasVibrator()
।
যদি ডিভাইস বাস্তবায়নে কমপক্ষে একটি সাধারণ উদ্দেশ্য হ্যাপটিক অ্যাকিউউটর অন্তর্ভুক্ত থাকে তবে তারা:
- [সি -1-1]
Vibrator.hasVibrator()
। - একটি অভিনব ঘোরানো ভর (ইআরএম) হ্যাপটিক অ্যাকিউউটর (ভাইব্রেটর) ব্যবহার করা উচিত নয়।
- অ্যান্ড্রয়েড.ভিউ
android.view.HapticFeedbackConstants
CLOCK_TICK
CONTEXT_CLICK
KEYBOARD_PRESS
KEYBOARD_RELEASE
KEYBOARD_TAP
LONG_PRESS
TEXT_HANDLE_MOVE
VIRTUAL_KEY
VIRTUAL_KEY_RELEASE
CONFIRM
REJECT
GESTURE_START
GESTURE_END
- অ্যান্ড্রয়েড.অভ
android.os.VibrationEffect
EFFECT_TICK
EFFECT_CLICK
EFFECT_HEAVY_CLICK
EFFECT_DOUBLE_CLICK
PRIMITIVE_*
_android.os.VibrationEffect.Composition
CLICK
TICK
LOW_TICK
QUICK_FALL
,QUICK_RISE
,SLOW_RISE
,SPIN
,THUD
)। এর মধ্যে কিছু আদিম, যেমনLOW_TICK
এবংSPIN
কেবল তখনই সম্ভব হতে পারে যদি ভাইব্রেটর তুলনামূলকভাবে কম ফ্রিকোয়েন্সি সমর্থন করতে পারে। - অ্যান্ড্রয়েডে পাবলিক ধ্রুবকগুলি ম্যাপিংয়ের জন্য গাইডেন্সটি
android.os.VibrationEffect
করা উচিতandroid.view.HapticFeedbackConstants
- এই লিঙ্কযুক্ত হ্যাপটিক ধ্রুবক ম্যাপিংগুলি ব্যবহার করা উচিত।
-
createOneShot()
এবংcreateWaveform()
এপিআইগুলির জন্য মানের মূল্যায়ন অনুসরণ করা উচিত। - যাচাই করা উচিত যে সর্বজনীন
android.os.Vibrator.hasAmplitudeControl()
এপিআই তাদের ভাইব্রেটারের ক্ষমতাগুলি সঠিকভাবে প্রতিফলিত করে। -
android.os.Vibrator.hasAmplitudeControl()
চালিয়ে প্রশস্ততা স্কেলিবিলিটির জন্য ক্ষমতাগুলি যাচাই করা উচিত।
যদি ডিভাইস বাস্তবায়নগুলি হ্যাপটিক ধ্রুবক ম্যাপিং অনুসরণ করে তবে তারা:
-
android.os.Vibrator.areAllEffectsSupported()
এবংandroid.os.Vibrator.arePrimitivesSupported()
এপিআইগুলি চালিয়ে বাস্তবায়নের স্থিতি যাচাই করা উচিত। - হ্যাপটিক ধ্রুবকগুলির জন্য একটি মানের মূল্যায়ন করা উচিত।
- ধ্রুবকগুলির জন্য বাস্তবায়ন গাইডেন্সে বর্ণিত হিসাবে অসমর্থিত আদিমগুলির জন্য ফ্যালব্যাক কনফিগারেশনের প্রয়োজন হলে যাচাই করা উচিত এবং আপডেট করা উচিত।
- এখানে বর্ণিত হিসাবে ব্যর্থতার ঝুঁকি হ্রাস করতে ফ্যালব্যাক সমর্থন সরবরাহ করা উচিত।
ডিভাইস-নির্দিষ্ট প্রয়োজনীয়তার জন্য বিভাগ 2.2.1 দেখুন।
- [7.10/সি]
9. সুরক্ষা মডেল সামঞ্জস্যতা
সংশোধন দেখুন
ডিভাইস বাস্তবায়ন:
- [সি -0-4] অবশ্যই উভয় ব্যবহারকারী ইন্টারফেসের একটি এবং কেবল একটি বাস্তবায়ন থাকতে হবে।
যদি ডিভাইস বাস্তবায়নগুলি সিস্টেম ইউআই গোয়েন্দা , সিস্টেম অ্যাম্বিয়েন্ট অডিও বুদ্ধি , সিস্টেম অডিও বুদ্ধি , সিস্টেম বিজ্ঞপ্তি বুদ্ধি , সিস্টেম পাঠ্য গোয়েন্দা , বা সিস্টেম ভিজ্যুয়াল বুদ্ধি ভূমিকা, প্যাকেজগুলি রাখে এমন কোনও প্যাকেজ প্রাক-ইনস্টল করে থাকে:
- [সি -৪-১] অবশ্যই বিভাগগুলিতে ডিভাইস বাস্তবায়নের জন্য বর্ণিত সমস্ত প্রয়োজনীয়তা পূরণ করতে হবে
"9.8.6 সামগ্রী ক্যাপচার""9.8.6 ওএস-স্তর এবং পরিবেষ্টিত ডেটা এবং 9.8.15 স্যান্ডবক্সড এপিআই বাস্তবায়ন"।
- [সি -4-2] অবশ্যই অ্যান্ড্রয়েড.পারেমিশন.ইনটারনেট অনুমতি থাকা উচিত নয়। এটি ধারা 9.8.6 এ তালিকাভুক্ত দৃ strongly ়ভাবে প্রস্তাবিত চেয়ে কঠোর।
- [C-4-3] MUST NOT bind to other apps, except for the following system apps: Bluetooth, Contacts, Media, Telephony, SystemUI, and components providing Internet APIs. This is stricter than the STRONGLY RECOMMENDED listed in section 9.8.6.
If device implementations include a default application to support the
VoiceInteractionService
they:- [C-5-1] MUST NOT grant
ACCESS_FINE_LOCATION
as the default for that application.
See revision
If device implementations create the additional user profile discussed above, then they:
- [C-4-5] MUST visually distinguish the dual instance application icons when the icons are presented to users.
- [C-4-6] MUST provide a user-affordance to delete entire clone profile data.
- [C-4-7] MUST uninstall all Clone apps, delete the private app data directories and their content, and delete Clone profile data, when the user chooses to delete entire Clone profile data.
- SHOULD prompt the user to delete entire Clone Profile data when the last clone app is deleted.
- [C-4-8] MUST inform the user that app data will be deleted when the clone application is uninstalled, or provide an option to users to keep app data when the application is uninstalled from the device.
- [C-4-9] MUST delete the private app data directories and their content, when the user chooses to delete the data during uninstall.
[C-4-1] MUST allow the below intents originating from the additional profile to be handled by applications of the primary user on the device:
-
Intent.ACTION_VIEW
-
Intent.ACTION_SENDTO
-
Intent.ACTION_SEND
-
Intent.ACTION_EDIT
-
Intent.ACTION_INSERT
-
Intent.ACTION_INSERT_OR_EDIT
-
Intent.ACTION_SEND_MULTIPLE
-
Intent.ACTION_PICK
-
Intent.ACTION_GET_CONTENT
-
MediaStore.ACTION_IMAGE_CAPTURE
-
MediaStore.ACTION_VIDEO_CAPTURE
-
[C-4-2] MUST inherit all device policy user restrictions and selected non-user restrictions(list below) applied on the primary user of the device to this additional user profile.
[C-4-3] MUST only allow writing contacts from this additional profile via the following intents:
[C-4-4] MUST NOT have contact syncs running for applications running in this additional user profile.
- [C-4-14] MUST have separate permission and storage management for the applications running in this additional profile
- [C-4-5] MUST only allow applications in the additional profile that have a launcher activity to access contacts that are already accessible to the parent user profile.
See revision
A Memory Safety technology is a technology that mitigates at least the following classes of bugs with a high (> 90%) probability in applications that use the
android:memtagMode
manifest option:- heap buffer overflow
- use after free
- দ্বিগুণ বিনামূল্যে
- wild free (free of a non-malloc pointer)
Device implementations:
- [C-SR-15] Are STRONGLY RECOMMENDED to set
ro.arm64.memtag.bootctl_supported
.
If device implementations set the system property
ro.arm64.memtag.bootctl_supported
to true, they:[C-3-1] MUST allow the system property
arm64.memtag.bootctl
to accept a comma-separated list of the following values, with the desired effect applied on the next subsequent reboot:-
memtag
: a Memory Safety technology as defined above is enabled -
memtag-once
: a Memory Safety technology as defined above is transiently enabled, and is automatically disabled upon, next reboot -
memtag-off
: a Memory Safety technology as defined above is disabled
-
[C-3-2] MUST allow the shell user to set
arm64.memtag.bootctl
.[C-3-3] MUST allow any process to read
arm64.memtag.bootctl
.[C-3-4] MUST set
arm64.memtag.bootctl
to the currently requested state upon boot, it MUST also update the property, if the device implementation allows to modify the state without changing the system property.[C-SR-16] Are STRONGLY RECOMMENDED to show a Developer Setting that sets memtag-once and reboots the device. With a compatible bootloader, the Android Open Source Project meets the above requirements through the MTE bootloader protocol .
- [C-SR-17] Are STRONGLY RECOMMENDED to show a Setting in the Security Settings menu that allows the user to enable
memtag
.
See revision
Device implementations:
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
enabled that includes exactly the same message as AOSPwhenevereach and every time a session to capture the screencasting or screen recordingisenabledstarted via theMediaProjection.createVirtualDisplay()
,VirtualDeviceManager.createVirtualDisplay()
, or proprietary APIs.MUST NOT provide users an affordance to disable future display of the user consent.
[C-SR-1] Are STRONGLY RECOMMENDED to display a user warning which is exactly the same message as implemented in AOSP but CAN be altered as long as the message clearly warns the user that any sensitive information on the user's screen is captured.
[C-0-4] MUST NOT provide users an affordance to disable future prompts of the user consent to capture the screen, unless the session is started by a system app that the user has allowed to
associate()
with theandroid.app.role.COMPANION_DEVICE_APP_STREAMING
or theandroid.app.role.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
device profile.
- [C-0-2] MUST display a user warning and obtain explicit user consent allowing any sensitive information that is displayed on the user's screen to be captured
9.8.6. OS-level and ambient data : This section was renamed from Content Capture and App Search to OS-level and ambient data .
See revision
Android, through the System APIs
, supports a mechanism for device implementations to capture the followingContentCaptureService
,AugmentedAutofillService
,AppSearchGlobalManager.query
, or by other proprietary meansapplication data interactions between the applications and the usersensitive data :- Any screen or other data sent via the
AugmentedAutofillService
to the system. - Any screen or other data accessible via
Content Capture
API. - Any screen or other data accessible via
FieldClassificationService
API - Any application data passed to the system via the
AppSearchManager
API and accessible viaAppSearchGlobalManager.query
.
- Any other events that an application provides to the system via the
Content Capture
API or orAppSearchManager
API a similarly capable Android and proprietary API.
- Audio data obtained as a result of using
SpeechRecognizer#onDeviceSpeechRecognizer()
by the Speech Recognizer Implementation. - Audio data obtained in background (continuously) through
AudioRecord
,SoundTrigger
or other Audio APIs, and not resulting in a user-visible indicator - Camera data obtained in background (continuously) through CameraManager or other Camera APIs, and not resulting in a user-visible indicator
If device implementations capture any of the data above, they:
[C-1-3] MUST only send all such data
and the logoff the device using a privacy-preserving mechanism , except with explicit user consent every time the data is shared . The privacy-preserving mechanism is defined as “those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users”, to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such asRAPPOR
).[C-1-5] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.6
Content CaptureOS-level and ambient data ), except with explicit user consent every time it is ভাগ করা Unless such functionality is built as an Android SDK API (AmbientContext
,HotwordDetectionService
).[C-1-6] MUST provide user affordance to erase such data that the
implementation or the proprietary means collectsContentCaptureService
ifwhen the data is stored in any form on the device. If the user chooses to erase the data, MUST remove all collected historical data.
- [C-SR-3] Are STRONGLY RECOMMENDED to be implemented with Android SDK API or a similar OEM-owned open-source repository; and / or be performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementations).
Android, through
SpeechRecognizer#onDeviceSpeechRecognizer()
provides ability to perform speech recognition on the device, without involving the network. Any implementation of on-device SpeechRecognizer MUST follow the policies outlined in this section.- Any screen or other data sent via the
9.8.10. Connectivity Bug Report :
See revision
If device implementations declare the
android.hardware.telephony
feature flag, they:- [C-1-4] Reports generated using
BUGREPORT_MODE_TELEPHONY
MUST contain at least the following information:-
SubscriptionManagerService
dump
-
- [C-1-4] Reports generated using
9.8.14. Credential Manager : Removed
9.8.15. Sandboxed API Implementations : New section
See revision
Android, through a set of delegate APIs provides a mechanism to process secure OS-level and ambient data. Such processing can be delegated to a preinstalled apk with privileged access and reduced communication capabilities, known as a Sandboxed API Implementation.
Any Sandboxed API implementation:
- [C-0-1] MUST NOT request the INTERNET permission.
- [C-0-2] MUST only access the internet through structured APIs backed by publicly available open-source implementations using privacy-preserving mechanisms, or indirectly via Android SDK APIs. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST keep the services separate from other system components (eg not binding the service or sharing process IDs) except for the following:
- Telephony, Contacts, System UI, and Media
- [C-0-4] MUST NOT allow users to replace the services with a user-installable application or service
- [C-0-5] MUST only allow the preinstalled services to capture such data. Unless the replacement capability is built into AOSP (eg for Digital Assistant Apps).
- [C-0-6] MUST NOT allow any apps other than the preinstalled services mechanism to be able to capture such data. Unless such capture capability is implemented with an Android SDK API.
- [C-0-7] MUST provide user affordance to disable the services.
- [C-0-8] MUST NOT omit user affordance to manage Android permissions that are held by the services and follow the Android permissions model as described in Section 9.1. অনুমতি ।
9.8.16. Continuous Audio and Camera data : New section
See revision
In addition to requirements outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, and 9.8.15 Sandboxed API implementations, implementations that make use of Audio data obtained in background (continuously) through AudioRecord, SoundTrigger or other Audio APIs OR Camera data obtained in background (continuously) through CameraManager or other Camera APIs:
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
- This access is performed in a Sandboxed implementation (see 9.8.15 Sandboxed API implementation), through a package holding one or more of the following roles: System UI Intelligence , System Ambient Audio Intelligence , System Audio Intelligence , System Notification Intelligence , System Text Intelligence , or System Visual Intelligence .
- The access is performed through a sandbox, implemented and enforced via mechanisms in AOSP (
HotwordDetectionService
,WearableSensingService
,VisualQueryDetector
). - Audio access is performed for assistive purposes by the Digital Assistant application, supplying
SOURCE_HOTWORD
as an audio source. - The access is performed by the system and implemented with open-source code.
- [C-SR-1] Is STRONGLY RECOMMENDED to require user consent for every functionality utilizing such data, and be disabled by default.
- [C-SR-2] STRONGLY RECOMMENDED to apply the same treatment (ie follow the restrictions outlined in 9.8.2 Recording, 9.8.6 OS-level and ambient data, 9.8.15 Sandboxed API implementations, and 9.8.16 Continuous Audio and Camera data) to Camera data coming from a remote wearable device.
If the Camera data is supplied from a remote wearable device and accessed in an unencrypted form outside Android OS, sandboxed implementation or a sandboxed functionality built by
WearableSensingManager
, then they:- [C-1-1] MUST indicate to the remote wearable device to display an additional indicator there.
If devices provide capability to engage with a Digital Assistant Application without the assigned keyword (either handling generic user queries, or analyzing user presence through camera):
- [C-2-1] MUST ensure such implementation is provided by a package holding the
android.app.role.ASSISTANT
role. - [C-2-2] MUST ensure such implementation utilizes
HotwordDetectionService
and/orVisualQueryDetectionService
Android APIs.
- [C-0-1] MUST enforce a corresponding indicator (camera and/or microphone as per section 9.8.2 Recording), unless:
9.8.17. Telemetry : New section
See revision
Android stores system and app logs using StatsLog APIs. These logs are managed via StatsManager APIs which can be used by privileged system applications.
StatsManager also provides a way to collect data categorized as privacy sensitive from devices with a privacy preserving mechanism. In particular,
StatsManager::query
API provides the ability to query restricted metric categories defined in StatsLog .Any implementation querying and collecting restricted metrics from StatsManager:
- [C-0-1] MUST be the sole application/implementation on the device and hold the
READ_RESTRICTED_STATS
permission. - [C-0-2] MUST only send telemetry data and the log of the device using a privacy-preserving mechanism. The privacy-preserving mechanism is defined as "those which allow only analysis in aggregate and prevent matching of logged events or derived outcomes to individual users", to prevent any per-user data being introspectable (eg, implemented using a differential privacy technology such as RAPPOR ).
- [C-0-3] MUST NOT associate such data with any user identity (such as Account ) on the device.
- [C-0-4] MUST NOT share such data with other OS components that don't follow requirements outlined in the current section (9.8.17 Privacy-preserving Telemetry).
- [C-0-5] MUST provide a user affordance to enable/disable privacy-preserving telemetry collection, use, and sharing.
- [C-0-6] MUST provide user affordance to erase such data that the implementation collects if the data is stored in any form on the device. If the user chose to erase the data, MUST remove all data currently stored on the device.
- [C-0-7] MUST disclose underlying privacy-preserving protocol implementation in an open source repository.
- [C-0-8 ]MUST enforce data egress policies in this section to gate collection of data in restricted metric categories defined in StatsLog .
- [C-0-1] MUST be the sole application/implementation on the device and hold the
See revision
Device implementationsIf device implementations have the ability to verify file content on the per-page basis, then they :
[
C-0-3C-2-1 ] support cryptographically verifying file contentagainst a trusted keywithout reading the whole file.[
C-0-4C-2-2 ] MUST NOT allow the read requests on a protected file to succeed when the read contentdo not verify against a trusted keyis not verified per [C-2-1] above .
- [C-2-4] MUST return file checksum in O(1) for enabled files.
See revision
The Android Keystore System allows app developers to store cryptographic keys in a container and use them in cryptographic operations through the KeyChain API or the Keystore API . Device implementations:
- [C-0-3] MUST limit the number of failed primary authentication attempts.
- [C-SR-2] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations add or modify the authentication methods to unlock the lock screen if based on a known secret and use a new authentication method to be treated as a secure way to lock the screen, then:
- [C-SR-3] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-2-1] A PIN of a length less than 6 digits MUST NOT allow automatic entry without user interaction to avoid revealing the PIN length.
9.11.1. Secure Lock Screen, Authentication and Virtual Devices :
See revision
Device implementations:
- [C-0-1] MUST limit the number of failed primary authentication attempts.
- [C-SR-5] Are STRONGLY RECOMMENDED to implement an upper bound of 20 failed primary authentication attempts and if users consent and opt-in the feature, perform a "Factory Data Reset" after exceeding the limit of failed primary authentication attempts.
If device implementations set a numerical PIN as the recommended primary authentication method, then:
- [C-SR-6] A PIN is STRONGLY RECOMMENDED to have at least 6 digits, or equivalently a 20-bit entropy.
- [C-SR-7] A PIN of a length less than 6 digits is STRONGLY RECOMMENDED NOT to allow automatic entry without user interaction to avoid revealing the PIN length.
If device implementations have a secure lock screen and include one or more trust agent, which implements the
TrustAgentService
System API, they:[C-7-8] The user MUST be challenged for one of the recommended primary authentication (eg: PIN, pattern, password) methods at least once every 72 hours or less unless the safety of the user (eg driver distraction) is of উদ্বেগIf device implementations allow applications to create secondary virtual displays and support associated input events such as via VirtualDeviceManager and the displays are not marked with VIRTUAL_DISPLAY_FLAG_SECURE, they:
[C-13-10] MUST disable installation of apps initiated from virtual devices.9.17। Android Virtualization Framework :
See revision
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), the Android host:- [C-1-1] MUST support all the APIs defined by the
android.system.virtualmachine
package. - [C-1-2] MUST NOT modify the Android SELinux and permission model for the management of Protected Virtual Machines (pVM) .
- [C-1-3] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy provided in the upstream Android Open Source Project (AOSP) and the policy MUST compile with all neverallow rules present.
- [C-1-4] MUST only allow platform signed code & privileged apps
MUST NOT allow untrusted code (eg 3p apps)to create and run aProtected Virtual MachinepVM . Note: This might change in future Android releases.
- [C-1-5] MUST NOT allow a
Protected Virtual MachinepVM to execute code that is not part of the factory image or their updates.Anything that is not covered by Android Verified Boot (eg files downloaded from the Internet or sideloaded) MUST NOT be allowed to be run in a Protected Virtual Machine.
- [C-1-5] MUST only allow a non-debuggable pVM to execute code from the factory image or their platform updates which also includes any updates to privileged apps.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then anyProtected Virtual MachinepVM instance:- [C-2-1] MUST be able to run all operating systems available in the virtualization APEX in a
Protected Virtual MachinepVM . - [C-2-2] MUST NOT allow a
Protected Virtual MachinepVM to run an operating system that is not signed by the device implementor or OS vendor. - [C-2-3] MUST NOT allow a
Protected Virtual MachinepVM to execute data as code (eg SELinux neverallow execmem).
- [C-2-4] MUST NOT modify, omit, or replace the neverallow rules present within the system/sepolicy/microdroid provided in the upstream Android Open Source Project (AOSP).
- [C-2-5] MUST implement
Protected Virtual MachinepVM defense-in-depth mechanisms (eg SELinux for pVMs) even for non-Microdroid operating systems. - [C-2-6] MUST ensure that the pVM fails
firmware refusesto boot ifit cannot verify the initialimages that the VM will run cannot be verified. The verification MUST be done inside the VM. - [C-2-7] MUST ensure that the pVM fails
firmware refusesto boot if the integrity of the instance.img is compromised.
If the device implements support for the Android Virtualization Framework APIs (
android.system.virtualmachine.*
), then the hypervisor:- [C-3-1] MUST ensure that memory pages exclusively owned by a VM (either pVM or host VM) are accessible only to the virtual machine itself or the hypervisor, not by other virtual machines - either protected or non-protected.
MUST NOT allow any pVM to have access to a page belonging to another entity (ie other pVM or hypervisor), unless explicitly shared by the page owner. This includes the host VM. This applies to both CPU and DMA accesses. - [C-3-2] MUST wipe a page after it is used by a pVM and before it is returned to the host (eg the pVM is destroyed).
- [C-
3-3SR-1 ] Is STRONGLY RECOMMENDED to ensureMUST ensurethat that the pVM firmware is loaded and executed prior to any code in a pVM. - [C-3-4] MUST ensure that each VM derives a per-VM secret which
{Boot Certificate Chain (BCC) and Compound Device Identifier (CDIs) provided to a pVM instancecan only be derived by that particular VM instance and changes upon factory reset and OTA.
If the device implements support for the Android Virtualization Framework APIs, then across all areas:
- [C-4-1] MUST NOT provide functionality to a pVM that allows bypassing the Android Security Model.
If the device implements support for the Android Virtualization Framework APIs, then:
- [C-5-1] MUST be capable to support Isolated Compilation but may disable Isolated Compilation feature on the device shipment
of an ART runtime update.
If the device implements support for the Android Virtualization Framework APIs, then for Key Management:
- [C-6-1] MUST root DICE chain at a point that the user cannot modify, even on unlocked devices. (To ensure it cannot be spoofed).
- [C- SR-2
6-2] Is STRONGLY RECOMMENDED to use DICE as the per-VM secret derivation mechanism.MUST do DICE properly ie provide the correct values.
- [C-1-1] MUST support all the APIs defined by the