Istilah & konsep utama
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Bagian ini menjelaskan beberapa istilah utama yang digunakan dalam pedoman ini, serta singkatan yang digunakan dalam spesifikasi.
Arti Harus, Seharusnya & Mei
Pedoman desain Android untuk Mobil menggunakan istilah HARUS, HARUS, dan MAY menurut definisi yang dipublikasikan oleh IETF. Produsen mobil dan developer aplikasi perlu memahami arti istilah-istilah ini.
Di sepanjang panduan ini, istilah HARUS, SEHARUS, dan MAY muncul sering (baik huruf besar di tabel maupun huruf kecil di teks berjalan). Penggunaan istilah ini sesuai dengan definisi yang diberikan oleh IETF untuk memperjelas berbagai tingkat persyaratan dalam spesifikasi.
Untuk detail selengkapnya, lihat definisi IETF, yang merupakan sumber resmi tentang cara istilah ini digunakan dalam panduan ini dan dalam Compatibility Definition Document (CDD) Android.
Untuk memastikan bahwa sistem Android untuk Mobil berfungsi secara konsisten dan andal di semua implementasi, produsen mobil dan developer aplikasi harus mengingat hal berikut:
| Masa Berlaku |
Arti |
| HARUS |
Panduan ini merupakan persyaratan mutlak (tidak boleh dihilangkan atau diabaikan). Persyaratan tersebut diberlakukan pada API level atau dengan:
- Proses peninjauan desain Google untuk produsen mobil yang menggunakan Layanan Otomotif Google
- Proses peninjauan Google Play Store untuk aplikasi pihak ketiga
|
| SEHARUSNYA |
Mungkin ada alasan yang valid dalam keadaan tertentu untuk mengabaikan pedoman ini, tetapi implikasi lengkapnya harus dipahami dan dipertimbangkan dengan cermat sebelum memilih arah yang berbeda.
|
| MEI |
Panduan ini sepenuhnya bersifat opsional. Satu produsen mobil atau developer aplikasi dapat memilih untuk mengikuti panduan guna memenuhi kebutuhan pasar atau produk tertentu, sementara produsen lain mungkin menghilangkan item yang sama.
Implementasi yang tidak menyertakan opsi tertentu HARUS disiapkan untuk dapat saling beroperasi dengan implementasi lain yang menyertakan opsi, meskipun mungkin dengan fungsionalitas yang dikurangi. Dengan demikian, implementasi yang menyertakan opsi tertentu HARUS disiapkan untuk saling beroperasi dengan implementasi lain yang tidak menyertakan opsi tersebut (kecuali, tentu saja, untuk fitur yang disediakan oleh opsi tersebut.)
|
Status mengemudi
Panduan ini terkadang merujuk pada perbedaan pengalaman pengguna yang bergantung pada kondisi mengemudi mobil – yaitu, apakah mobil diparkir, tidak ada aktivitas, atau bergerak. Keputusan tentang apa yang diizinkan di berbagai status mengemudi dan rentang kecepatan bergantung pada produsen mobil dan persyaratan peraturan yang relevan di berbagai wilayah.
Dalam beberapa kasus, misalnya, tindakan tertentu mungkin diizinkan hanya jika mobil berhenti dengan rem parkir menyala. Di lokasi lain, tindakan mungkin diizinkan hanya jika mobil melaju dengan kecepatan tertentu atau di bawah kecepatan tertentu, misalnya 5 mph.
Label tata letak
Label berikut digunakan di seluruh panduan ini dalam penggambaran tata letak spesifikasi.
| Label |
Deskripsi |
 |
Edge: Menunjukkan batas lebar dan tinggi jendela yang tersedia.
|
 |
Margin: Menentukan batas kiri dan kanan kanvas aplikasi, yang diukur dari tepi terdekat. Untuk pembahasan tentang bagaimana lebar margin bervariasi menurut ukuran layar, kunjungi Ruang kerja aplikasi.
|
 |
Keyline: Nilai yang proporsional dengan lebar layar, digunakan untuk menentukan jarak horizontal antara elemen dan margin terdekat atau tepi komponen. Untuk nilai keyline yang terkait dengan kategori lebar layar tertentu, buka Keyline.
|
 |
Padding: Nilai yang digunakan untuk menentukan jarak antarelemen di layar sesuai dengan hubungannya. Secara umum, semakin dekat hubungan antara dua elemen, semakin sempit padding. Untuk mengetahui detail nilai padding yang digunakan dalam tata letak spesifikasi, buka padding.
|
 |
Flex: Istilah yang digunakan untuk menentukan elemen yang berpusat secara vertikal atau horizontal dalam penampung, atau jarak yang dapat membesar atau menciut sesuai dengan elemen yang berdekatan. Dimensi tata letak fleksibel terkadang diberi nilai minimum atau maksimum, seperti yang dibahas dalam Strategi penskalaan.
|
 |
Radius Sudut: Menentukan kelengkungan sudut, dengan nol menunjukkan sudut persegi dan nilai yang lebih tinggi menunjukkan lebih banyak pembulatan.
|
Kecuali dinyatakan lain, konten di halaman ini dilisensikan berdasarkan Lisensi Creative Commons Attribution 4.0, sedangkan contoh kode dilisensikan berdasarkan Lisensi Apache 2.0. Untuk mengetahui informasi selengkapnya, lihat Kebijakan Situs Google Developers. Java adalah merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-25 UTC.
[null,null,["Terakhir diperbarui pada 2025-07-25 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)"]]
