মূল শর্তাবলী & ধারণা
সেভ করা পৃষ্ঠা গুছিয়ে রাখতে 'সংগ্রহ' ব্যবহার করুন
আপনার পছন্দ অনুযায়ী কন্টেন্ট সেভ করুন ও সঠিক বিভাগে রাখুন।
এই বিভাগটি এই নির্দেশিকাগুলিতে ব্যবহৃত কিছু মূল শব্দের পাশাপাশি চশমাগুলিতে ব্যবহৃত সংক্ষিপ্ত রূপগুলি ব্যাখ্যা করে৷
Must, Should & May এর অর্থ
গাড়ির ডিজাইনের জন্য Android নির্দেশিকা IETF দ্বারা প্রকাশিত সংজ্ঞা অনুসারে MUST , SHOULD , এবং MAY শব্দগুলি ব্যবহার করে৷ গাড়ি নির্মাতা এবং অ্যাপ বিকাশকারী উভয়কেই এই শর্তগুলির অর্থ বুঝতে হবে।
এই সমস্ত নির্দেশিকাগুলির মধ্যে, শর্তাবলী MUST , SHOULD , এবং MAY প্রায়শই প্রদর্শিত হয় (উভয়টি টেবিলে বড় হাতের এবং চলমান পাঠ্যে ছোট হাতের)। এই পদগুলির ব্যবহার স্পেসিফিকেশনে বিভিন্ন প্রয়োজনীয়তার স্তরগুলিকে স্পষ্ট করতে IETF দ্বারা প্রদত্ত সংজ্ঞাগুলির সাথে সঙ্গতিপূর্ণ।
সম্পূর্ণ বিশদ বিবরণের জন্য, IETF সংজ্ঞাগুলি দেখুন, যেগুলি এই নির্দেশিকাগুলিতে এবং অ্যান্ড্রয়েড সামঞ্জস্যপূর্ণ সংজ্ঞা নথিতে (CDD) এই পদগুলি যেভাবে ব্যবহার করা হয়েছে তার জন্য প্রামাণিক উত্স।
গাড়ির জন্য অ্যান্ড্রয়েড সিস্টেমগুলি সমস্ত বাস্তবায়ন জুড়ে ধারাবাহিকভাবে এবং নির্ভরযোগ্যভাবে কাজ করে তা নিশ্চিত করতে, গাড়ি নির্মাতা এবং অ্যাপ বিকাশকারীদের নিম্নলিখিতগুলি মনে রাখতে হবে:
| মেয়াদ | অর্থ |
|---|
| অবশ্যই | নির্দেশিকা একটি পরম প্রয়োজনীয়তা (বাদ দেওয়া বা উপেক্ষা করা যাবে না)। এই ধরনের প্রয়োজনীয়তা API স্তরে বা এর দ্বারা প্রয়োগ করা হয়:
- গুগল অটোমোটিভ সার্ভিস ব্যবহার করে গাড়ি নির্মাতাদের জন্য গুগলের ডিজাইন পর্যালোচনা প্রক্রিয়া
- তৃতীয় পক্ষের অ্যাপের জন্য Google Play স্টোরের পর্যালোচনা প্রক্রিয়া
|
| উচিত | নির্দিষ্ট পরিস্থিতিতে নির্দেশিকা উপেক্ষা করার বৈধ কারণ থাকতে পারে, তবে সম্পূর্ণ প্রভাব অবশ্যই বুঝতে হবে এবং একটি ভিন্ন কোর্স বেছে নেওয়ার আগে সাবধানে ওজন করতে হবে। |
| মে | নির্দেশিকা সত্যিই ঐচ্ছিক. একজন গাড়ি প্রস্তুতকারক বা অ্যাপ বিকাশকারী নির্দিষ্ট বাজার বা পণ্যের চাহিদা মেটাতে নির্দেশিকা অনুসরণ করা বেছে নিতে পারে, অন্যজন একই আইটেম বাদ দিতে পারে।
একটি বাস্তবায়ন যা একটি নির্দিষ্ট বিকল্প অন্তর্ভুক্ত করে না তাকে অবশ্যই অন্য একটি বাস্তবায়নের সাথে ইন্টারঅপারেশন করার জন্য প্রস্তুত থাকতে হবে যাতে বিকল্পটি অন্তর্ভুক্ত থাকে, যদিও সম্ভবত কম কার্যকারিতা সহ। একই শিরায়, একটি বাস্তবায়ন যাতে একটি নির্দিষ্ট বিকল্প অন্তর্ভুক্ত থাকে সেটিকে অবশ্যই অন্য একটি বাস্তবায়নের সাথে ইন্টারঅপারেশন করার জন্য প্রস্তুত থাকতে হবে যা বিকল্পটি অন্তর্ভুক্ত করে না (অবশ্যই, বিকল্পটি যে বৈশিষ্ট্যটি প্রদান করে তার জন্য ছাড়া)। |
IETF এর সংজ্ঞা অবশ্যই, উচিত, মে
এবং সম্পর্কিত পদ
ড্রাইভিং রাজ্য
এই নির্দেশিকাগুলি মাঝে মাঝে ব্যবহারকারীর অভিজ্ঞতার পার্থক্যগুলিকে নির্দেশ করে যা গাড়ির ড্রাইভিং অবস্থার উপর নির্ভর করে - অর্থাৎ, এটি পার্ক করা, অলস বা চলন্ত কিনা। বিভিন্ন ড্রাইভিং স্টেট এবং স্পিড রেঞ্জে কী অনুমোদিত তা সম্পর্কে সিদ্ধান্তগুলি গাড়ি প্রস্তুতকারকের উপর এবং বিভিন্ন অঞ্চলে প্রাসঙ্গিক নিয়ন্ত্রক প্রয়োজনীয়তার উপর নির্ভর করে।
কিছু ক্ষেত্রে, উদাহরণস্বরূপ, পার্কিং ব্রেক চালু রেখে গাড়ি থামিয়ে দিলেই একটি নির্দিষ্ট পদক্ষেপের অনুমতি দেওয়া যেতে পারে। অন্যদের ক্ষেত্রে, গাড়িটি একটি নির্দিষ্ট গতিতে বা তার নিচে চললে, যেমন 5 মাইল প্রতি ঘণ্টায় শুধুমাত্র তখনই ক্রিয়াটি অনুমোদিত হতে পারে।
অ্যান্ড্রয়েড অটোমোটিভ লাইব্রেরি: android.car.drivingstate
বিকাশকারীদের জন্য অতিরিক্ত প্রযুক্তিগত বিবরণ
লেআউট লেবেল
নিম্নোক্ত লেবেলগুলি স্পেক লেআউটের বর্ণনায় এই নির্দেশিকা জুড়ে ব্যবহার করা হয়।
| লেবেল | বর্ণনা |
|---|
 | প্রান্ত: উপলব্ধ উইন্ডোর প্রস্থ এবং উচ্চতা সীমানা নির্দেশ করে। |
 | মার্জিন: অ্যাপ ক্যানভাসের বাম এবং ডান সীমানা নির্ধারণ করে, নিকটতম প্রান্ত থেকে পরিমাপ করা হয়। স্ক্রিনের আকারের সাথে মার্জিনের প্রস্থ কীভাবে পরিবর্তিত হয় সে সম্পর্কে আলোচনার জন্য, অ্যাপের কাজের স্থান দেখুন। |
 | কীলাইন: একটি মান যা পর্দার প্রস্থের সমানুপাতিক, একটি উপাদান এবং নিকটতম মার্জিন বা উপাদান প্রান্তের মধ্যে অনুভূমিক দূরত্ব নির্দিষ্ট করতে ব্যবহৃত হয়। নির্দিষ্ট স্ক্রীন-প্রস্থ বিভাগের সাথে যুক্ত কীলাইন মানগুলির জন্য, কীলাইনগুলিতে যান৷ |
 | প্যাডিং: তাদের সম্পর্ক অনুযায়ী পর্দায় উপাদানগুলির মধ্যে ব্যবধান নির্দিষ্ট করতে ব্যবহৃত মান। সাধারণভাবে, দুটি উপাদানের মধ্যে সম্পর্ক যত ঘনিষ্ঠ হবে, প্যাডিং তত সংকীর্ণ হবে। বিশেষ বিন্যাসে ব্যবহৃত প্যাডিং মানগুলির বিশদ বিবরণের জন্য, প্যাডিং এ যান৷ |
 | ফ্লেক্স: একটি পাত্রে একটি উল্লম্ব বা অনুভূমিকভাবে কেন্দ্রীভূত উপাদান, বা সংলগ্ন উপাদান অনুসারে বৃদ্ধি বা সংকোচন করতে পারে এমন দূরত্ব নির্দিষ্ট করতে ব্যবহৃত শব্দ। ফ্লেক্স-লেআউট মাত্রাগুলিকে কখনও কখনও সর্বনিম্ন বা সর্বোচ্চ মান নির্ধারণ করা হয়, যেমন স্কেলিং কৌশলগুলিতে আলোচনা করা হয়েছে। |
 | কোণার ব্যাসার্ধ: একটি কোণার বক্রতা নির্দিষ্ট করে, শূন্য একটি বর্গক্ষেত্র কোণ নির্দেশ করে এবং উচ্চতর মানগুলি আরও গোলাকার নির্দেশ করে৷ |
লেআউট
মার্জিন, কীলাইন এবং বিভিন্ন স্ক্রিনের মাপের জন্য প্যাডিং অন্য কিছু উল্লেখ না করা থাকলে, এই পৃষ্ঠার কন্টেন্ট Creative Commons Attribution 4.0 License-এর অধীনে এবং কোডের নমুনাগুলি Apache 2.0 License-এর অধীনে লাইসেন্স প্রাপ্ত। আরও জানতে, Google Developers সাইট নীতি দেখুন। Java হল Oracle এবং/অথবা তার অ্যাফিলিয়েট সংস্থার রেজিস্টার্ড ট্রেডমার্ক।
2025-07-24 UTC-তে শেষবার আপডেট করা হয়েছে।
[null,null,["2025-07-24 UTC-তে শেষবার আপডেট করা হয়েছে।"],[[["\u003cp\u003eThis document clarifies key terms like MUST, SHOULD, and MAY, aligning with IETF definitions for consistent understanding across car makers and app developers.\u003c/p\u003e\n"],["\u003cp\u003eDriving state context is crucial, as the car's state (parked, idling, moving) influences permissible actions and user experience, subject to car maker decisions and regional regulations.\u003c/p\u003e\n"],["\u003cp\u003eLayout labels like Edge, Margin, Keyline, Padding, Flex, and Corner Radius are used throughout the guidelines to illustrate specifications for app design and screen elements.\u003c/p\u003e\n"],["\u003cp\u003eFor in-depth information, refer to linked resources detailing IETF definitions, Android Automotive library, and layout specifications.\u003c/p\u003e\n"]]],[],null,["# Key terms & concepts\n\n\u003cbr /\u003e\n\nThis section explains some key terms used in these guidelines, as well as the abbreviations used in the specs.\n\n*** ** * ** ***\n\nMeaning of Must, Should \\& May\n------------------------------\n\nThe Android for Cars design guidelines use the terms **MUST** , **SHOULD** , and **MAY** according to definitions published by the IETF. Both car makers and app developers need to understand the meanings of these terms.\n\nThroughout these guidelines, the terms **MUST** , **SHOULD** , and **MAY** appear frequently (both capitalized in tables and lowercase in running text). The use of these terms conforms to the definitions provided by the IETF to clarify various requirement levels in specifications.\n\nFor full details, see the IETF definitions, which are the authoritative source for the way these terms are used in these guidelines and in the Android Compatibility Definition Document (CDD).\n\nTo ensure that Android for Cars systems work consistently and reliably across all implementations, car makers and app developers need to keep the following in mind:\n\n| Term | Meaning |\n|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| MUST | The guideline is an absolute requirement (cannot be omitted or ignored). Such requirements are enforced either at the API level or by: - Google's design review process for car makers using Google Automotive Services - Google Play store's review process for third-party apps |\n| SHOULD | There may be valid reasons in particular circumstances to ignore the guideline, but the full implications must be understood and carefully weighed before choosing a different course. |\n| MAY | The guideline is truly optional. One car maker or app developer may choose to follow the guidelines to meet specific market or product needs, while another may omit the same item. An implementation that does not include a particular option **MUST** be prepared to interoperate with another implementation that does include the option, though perhaps with reduced functionality. In the same vein, an implementation that does include a particular option **MUST** be prepared to interoperate with another implementation that does not include the option (except, of course, for the feature the option provides.) |\n\n[IETF definitions of MUST, SHOULD, MAY\nand related terms](https://www.ietf.org/rfc/rfc2119.txt)\n\n*** ** * ** ***\n\nDriving states\n--------------\n\nThese guidelines occasionally refer to differences in the user experience that depend on the car's driving state -- that is, whether it's parked, idling, or moving. The decisions about what is allowed in various driving states and speed ranges depend on the car maker and on the relevant regulatory requirements in different regions.\n\nIn some cases, for example, a certain action might be allowed only if the car is stopped with the parking brake on. In others, the action might be allowed only if the car is moving at or below a certain speed, such as 5 mph. \n[Android Automotive Library: android.car.drivingstate\nAdditional technical details for developers](https://developer.android.com/reference/android/car/drivingstate/package-summary)\n\n*** ** * ** ***\n\nLayout labels\n-------------\n\nThe following labels are used throughout these guidelines in depictions of spec layouts.\n\n| Label | Description |\n|-------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Edge:** Indicates width and height boundaries of the available window. |\n| | **Margin:** Defines the left and right boundaries of the app canvas, measured from the nearest edge. For a discussion of how margin width varies with screen size, visit [App working space](/cars/design/automotive-os/design-system/layout#app_working_space). |\n| | **Keyline:** A value that is proportional to screen width, used to specify the horizontal distance between an element and the nearest margin or component edge. For the keyline values associated with specific screen-width categories, visit [Keylines](/cars/design/automotive-os/design-system/layout#keylines). |\n| | **Padding:** Value used to specify spacing between elements on the screen according to their relationships. In general, the closer the relationship is between two elements, the narrower the padding. For details of the padding values used in spec layouts, visit [padding](/cars/design/automotive-os/design-system/layout#padding). |\n| | **Flex:** Term used to specify a vertically or horizontally centered element in a container, or a distance that can grow or contract according to the adjacent elements. Flex-layout dimensions are sometimes assigned a minimum or maximum value, as discussed in [Scaling strategies](/cars/design/automotive-os/design-system/layout#scaling_strategies). |\n| | **Corner Radius:** Specifies the curvature of a corner, with zero indicating a square corner and higher values indicating more rounding. |\n\n[Layout\nMargins, keylines, and padding for various screen sizes](/cars/design/automotive-os/design-system/layout)"]]
