वाहन की वह जानकारी दिखाने के लिए हाई अवेलेबिलिटी रेंडरर (एचएआर) का इस्तेमाल करें जिसे Android नहीं दिखा सकता. ऐसा स्टार्टअप, उपलब्धता, सुरक्षा या नियमों से जुड़ी समस्याओं की वजह से हो सकता है. HAR, Rust में लिखा गया एक पोर्टेबल और पहले से मौजूद ऐप्लिकेशन है.
HAR को HAR फ़्रेमवर्क भी कहा जाता है. इसमें ऐप्लिकेशन बनाने के लिए इस्तेमाल किया जाने वाला कोड शामिल होता है. HAR की मदद से बनाए गए ऐप्लिकेशन को HAR पर आधारित ऐप्लिकेशन कहा जाता है. HAR फ़्रेमवर्क में अलग-अलग प्लैटफ़ॉर्म के लिए कोड सेक्शन होते हैं. उदाहरण के लिए, Linux सिस्टम पर आवाज़ के लिए, tinyalsa जैसी लाइब्रेरी का इस्तेमाल किया जाता है. QNX में अपनी यूनीक ऑडियो लाइब्रेरी होती हैं.
किसी प्लैटफ़ॉर्म में हार्डवेयर, ऑपरेटिंग सिस्टम, सिस्टम लाइब्रेरी, और अन्य फ़ैक्टर शामिल होते हैं. प्लैटफ़ॉर्म के हिसाब से बनाए गए कोड में, ऐसे हिस्से होते हैं जिन्हें सबसिस्टम कहा जाता है. हर सबसिस्टम, एक प्लैटफ़ॉर्म सुविधा को मैनेज करता है. जैसे, ऑडियो, ईवीएस कैमरे या वाहन का डेटा. किसी प्लैटफ़ॉर्म पर काम करने के लिए, HAR फ़्रेमवर्क के सभी सबसिस्टम लागू होने चाहिए.
प्लैटफ़ॉर्म के हिसाब से सबसिस्टम कोड, HAR पर आधारित ऐप्लिकेशन की तरह ही प्रोसेस में चल सकता है या किसी दूसरी प्रोसेस में चल सकता है. अलग होने पर, यह कोड इंटरप्रोसेस कम्यूनिकेशन (आईपीसी) को मैनेज करता है. इससे यह पुष्टि करने में मदद मिलती है कि प्लैटफ़ॉर्म, ऐप्लिकेशन के साथ काम करता है. जटिल आईपीसी मैकेनिज़्म, प्लैटफ़ॉर्म के हिसाब से बनाए गए कोड का हिस्सा होने चाहिए.
HAR टेस्ट सुइट, किसी प्लैटफ़ॉर्म के लिए लागू किए गए सभी सबसिस्टम पर टेस्ट चलाता है. इस सुइट का इस्तेमाल करके, यह पता लगाएं कि प्लैटफ़ॉर्म, HAR की ज़रूरी शर्तों को पूरा करते हैं या नहीं. साथ ही, नई समस्याओं का पता लगाएं.
शब्दावली
इस पेज पर ये शब्द मौजूद हैं:
- HAR पर आधारित ऐप्लिकेशन
- HAR फ़्रेमवर्क का इस्तेमाल करके बनाया गया OEM या फ़ंक्शन के हिसाब से काम करने वाला ऐप्लिकेशन. ऐप्लिकेशन, ऐप्लिकेशन की स्थिति और पसंद के मुताबिक बनाए जा सकने वाले अन्य पहलुओं के हिसाब से अलग-अलग होते हैं.
- HAR फ़्रेमवर्क
- ऐप्लिकेशन बनाने के लिए इस्तेमाल किए जाने वाले टूल का मुख्य सेट उपलब्ध कराता है.
- HAR प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन
- यह HAR फ़्रेमवर्क का हिस्सा है. यह एक ऐसा एपीआई उपलब्ध कराता है जिसे सभी टारगेट प्लैटफ़ॉर्म को लागू करना ज़रूरी है.
- HAR test suite
- प्लैटफ़ॉर्म पर लागू किए गए कई टेस्ट, इनसे यह पुष्टि करने में मदद मिलती है कि प्लैटफ़ॉर्म पर लागू किए गए HAR फ़्रेमवर्क, दिए गए प्लैटफ़ॉर्म के साथ काम करते हैं.
आउट ऑफ़ स्कोप
HAR में इन समस्याओं के बारे में नहीं बताया जाता:
सभी प्लैटफ़ॉर्म टारगेट के लिए अलग-अलग लागू करने की प्रोसेस: टारगेट प्लैटफ़ॉर्म के लिए लागू करने की प्रोसेस. इसके बजाय, इस पेज पर उन इंटरफ़ेस के बारे में बताया गया है जिन्हें प्लैटफ़ॉर्म के लिए लागू की गई सुविधाओं को पूरा करना होगा. साथ ही, एक टेस्ट सुइट को भी इन इंटरफ़ेस को पूरा करना होगा.
टेस्ट केस: सभी इंटरफ़ेस के लिए खास टेस्ट केस. इसके बजाय, इस पेज पर इंटरफ़ेस के लिए अलग-अलग फ़ंक्शन के बारे में बताया गया है. इनमें आर्ग्युमेंट, रिटर्न वैल्यू, उम्मीद के मुताबिक काम करने के तरीके, और उम्मीद के मुताबिक साइड इफ़ेक्ट शामिल हैं. इस पेज पर, टेस्ट सुइट के बारे में बताया गया है. इसमें टेस्ट केस लागू किए जा सकते हैं और उन्हें चलाया जा सकता है.
प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन का हाई-लेवल क्रेट स्ट्रक्चर
Rust प्रोजेक्ट में क्रेट शामिल होती हैं. पहली इमेज में, HAR प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन लेयर के लिए क्रेट स्ट्रक्चर दिखाया गया है. प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन लेयर, दो या उससे ज़्यादा रस्ट क्रेट पर असर डालती है:
ऐब्स्ट्रैक्शन (Rust
traitब्यौरे) HAR फ़्रेमवर्क क्रेट में हैं.किसी प्लैटफ़ॉर्म के लिए लागू करने की प्रोसेस, अलग
har-platform-xक्रेट के ज़रिए की जाती है. उदाहरण के लिए,har-platform-linuxयाhar-platform-android.
किसी प्लैटफ़ॉर्म के लिए HAR crate को लागू किए बिना, इसे बनाया या टेस्ट नहीं किया जा सकता. ऐसा जान-बूझकर किया गया है, क्योंकि HAR फ़्रेमवर्क एक फ़्रेमवर्क है.
किसी प्लैटफ़ॉर्म के लिए बनाए गए ऐप्लिकेशन को इस फ़्रेमवर्क के साथ बनाया जाना चाहिए, ताकि वह काम कर सके और उसकी जांच की जा सके. इस डायग्राम में, HAR फ़्रेमवर्क और प्लैटफ़ॉर्म के बीच कनेक्शन दिखाए गए हैं:
पहली इमेज. HAR क्रेट.
display-safety में मौजूद सामान्य स्ट्रक्चर
इस डिज़ाइन में, display_safety रिपॉज़िटरी में कई नई क्रेट जोड़ी गई हैं. जैसा कि इमेज 2 में दिखाया गया है:
दूसरी इमेज. ऐब्स्ट्रैक्शन मॉड्यूल.
टेस्ट सुइट, स्ट्रक्चर के हिसाब से ऐप्लिकेशन जैसा ही होता है. हालांकि, यह सिर्फ़ दिए गए प्लैटफ़ॉर्म के इम्प्लीमेंटेशन क्रेट पर निर्भर करता है. टेस्ट सुइट में, HAR फ़्रेमवर्क में तय की गई विशेषताओं और स्ट्रक्चर का रेफ़रंस होना चाहिए. हालांकि, इसमें ज़्यादा जटिल तरीके से लागू किए गए फ़्रेमवर्क का रेफ़रंस नहीं होना चाहिए.
प्लेटफ़ॉर्म ऐब्स्ट्रैक्शन लेयर की खास जानकारी
इस टेबल में, प्लैटफ़ॉर्म के हिसाब से तय किए गए सबसिस्टम के बारे में बताया गया है. इन्हें एचएआर प्लैटफ़ॉर्म ऐब्स्ट्रैक्शन लेयर तय करती है.
| ऐब्स्ट्रैक्शन का नाम | मिलता-जुलता फ़ंक्शन | ब्यौरा | नोट |
|---|---|---|---|
OpenGL |
2D रेंडरिंग | यह HAR फ़्रेमवर्क क्रेट को OpenGLES 2.0/3.0 रेंडरिंग की सुविधाएं उपलब्ध कराता है. | |
Audio |
ऑडियो रेंडरिंग | यह सिस्टम ऑडियो को मैनेज और चलाने के लिए, Android SoundPool जैसा इंटरफ़ेस उपलब्ध कराता है. | |
Camera |
वाहन के कैमरे का डिसप्ले | यह वाहन के कैमरे की जानकारी को मैनेज और डिसप्ले करने के लिए, ईवीएस एचएएल जैसा इंटरफ़ेस उपलब्ध कराता है. | |
Looper |
ऐप्लिकेशन का मुख्य लूप और डिसप्ले कॉन्फ़िगरेशन | यह प्लैटफ़ॉर्म के हिसाब से ऐप्लिकेशन के मुख्य लूप को मैनेज करने और डिसप्ले कॉन्फ़िगरेशन के लिए, Android Looper जैसा इंटरफ़ेस उपलब्ध कराता है. | |
UserInput |
टच, कीबोर्ड, स्टीयरिंग व्हील या रोटरी कंट्रोलर, और प्लैटफ़ॉर्म के हिसाब से अन्य इनपुट | यह HAR पर आधारित ऐप्लिकेशन को टच और कीबोर्ड इनपुट देने के लिए इंटरफ़ेस उपलब्ध कराता है. Linux evdev पर आधारित रेफ़रंस के तौर पर लागू किया गया har-user-input-evdev. |
|
VehicleData |
वाहन की स्थिति का इनपुट | यह इंटरफ़ेस, एचएआर पर आधारित ऐप्लिकेशन को किसी भी तरह का वाहन डेटा उपलब्ध कराता है. जैसे, Android VHAL या CAN बस से मिला डेटा. | |
ResourceManager |
ऐप्लिकेशन के हिसाब से कैश मेमोरी में सेव किया गया डिज़ाइन दस्तावेज़ | यह कुकी, एचएआर स्टार्टअप के लिए ज़रूरी रिसॉर्स की इन-मेमोरी कैश उपलब्ध कराती है. जैसे, कैश की गई इमेज और डिज़ाइन से जुड़े दस्तावेज़. अभी तक डिस्क कैश मेमोरी लागू नहीं की गई है. | |
Logging |
सिस्टम में लॉग इकट्ठा करना और टेलीमेट्री | यह कुकी, ट्रेसिंग सिस्टम का इस्तेमाल करके प्लैटफ़ॉर्म के हिसाब से लॉगिंग की सुविधा उपलब्ध कराती है. इससे प्लैटफ़ॉर्म की ज़रूरत के मुताबिक टेलीमेट्री डेटा इकट्ठा किया जा सकता है. | |
Tracing |
सिस्टम ट्रेस करने की सुविधा | यह ट्रेसिंग और प्रोफ़ाइलिंग सिस्टम के साथ इंटिग्रेट करने के लिए, ऐब्स्ट्रैक्शन उपलब्ध कराता है. | |
Monitoring |
सिस्टम मॉनिटरिंग | यह टूलकिट, HAR फ़्रेमवर्क में परफ़ॉर्मेंस और लेटेन्सी को मॉनिटर करने के लिए है. | |
Commlib |
गाड़ी का डेटा | प्रोटोबफ़ सीरियलाइज़ेशन का इस्तेमाल करके, रेफ़रंस के तौर पर लागू करना.
अब इस्तेमाल नहीं किया जाता: reference/harry-control-api में तय किए गए एपीआई का इस्तेमाल करें. साथ ही, harry-grpcio-server और harry-tonic-server (रेफ़रंस के तौर पर लागू किया गया) को लागू करें. |
|
TestSupport |
सहायता हुक की टेस्टिंग | यह टेस्ट केस बनाने और उन्हें हटाने, टेस्ट इवेंट जनरेट करने, और टेस्ट आर्टफ़ैक्ट बनाने में मदद करता है. उदाहरण के लिए, UserInput की जांच करने के लिए, सिम्युलेट किए गए टच इवेंट जनरेट करना और विश्लेषण के लिए स्क्रीनशॉट जनरेट करना. |
इस सुविधा को Rust ने लॉक किया है, ताकि इसे प्रोडक्शन बिल्ड में शामिल न किया जा सके. |
नेमिंग कनवेंशन और फ़्रेमवर्क स्ट्रक्चर
इस टेबल में, इन नामों और स्ट्रक्चर के बारे में बताया गया है:
HAR फ़्रेमवर्क के ज़रिए दिए गए, अनुमानित सबसिस्टम
traitइंस्टेंस. हरtrait, प्लैटफ़ॉर्म के हिसाब से एक खास सबसिस्टम को दिखाता है. इसे लागू करना ज़रूरी है.किसी भी प्लैटफ़ॉर्म के क्रेड में, प्लैटफ़ॉर्म के हिसाब से सबसिस्टम लागू करने के अनुमानित नाम. HAR पर आधारित ऐप्लिकेशन, इन नामों को लागू करने की उम्मीद करते हैं.
HAR फ़्रेमवर्क से जुड़े
enumऔरstructइंस्टेंस का इस्तेमाल आम तौर पर, प्लैटफ़ॉर्म से जुड़े लागू करने के तरीकों से HAR फ़्रेमवर्क को जानकारी देने के लिए किया जाता है.
| ट्रेट के नाम | लागू करने के नाम | HAR फ़्रेमवर्क के एनम और स्ट्रक्चर |
|---|---|---|
GlContextFactory |
OpenGL |
trait harry::Rendererharry::DisplayRotation |
AudioApiFactory |
Audio |
harry::AudioApiharry::AudioDeviceharry::VolumeMillibel |
ICameraManager |
Camera |
harry::ICameraDeviceharry::CameraDescriptor |
Looper |
Looper |
harry::LooperMessageharry::LooperOptionsharry::DisplayId |
PlatformVehicleData |
VehicleData |
harry::VehicleDataTypeharry::VehicleDataListener |
ResourceManager (Struct) |
ResourceManager |
harry::ResourceManagerMessageharry::ResourceTokenharry::RawImageData |
PlatformTracing |
Tracing |
लागू नहीं |
HarPerformanceMonitor |
Monitoring |
harry::Rendererharry::ResolveLatencyToken |
PlatformTestSupport |
TestSupport |
harry::TestConfigharry::TestDisplayConfig |
गड़बड़ियां और उन्हें ठीक करना
सुझाए गए एपीआई, Rust Result<> टाइप का इस्तेमाल करते हैं. Rust में, आपको गड़बड़ियां ठीक करने के लिए Result टाइप की जांच करनी होती है. ऐसा न होने पर, कंपाइलर चेतावनी या गड़बड़ी जनरेट करता है. बिल्ड-टाइम की जांच, प्लैटफ़ॉर्म के हिसाब से कोड में गड़बड़ी की जांच करती है.
प्लैटफ़ॉर्म के इंटिग्रेशन से मिली गड़बड़ियां, harry::error::Error टाइप की होती हैं. यह पुष्टि करने के लिए कि प्लैटफ़ॉर्म के गड़बड़ी वाले टाइप, ऐप्लिकेशन के कोड में लीक नहीं होते हैं, HAR फ़्रेमवर्क की ओर से उपलब्ध कराए गए स्टैंडर्ड गड़बड़ी वाले टाइप का इस्तेमाल करें.
harry::error::Error टाइप में, सभी सबसिस्टम के लिए गड़बड़ियों की खास जानकारी शामिल होती है:
// This is Rust
pub enum Error {
Msg(String), // A generic message string
// Legacy error type, likely to be removed or merged into Msg
Audio(String),
}
ठीक न की जा सकने वाली गड़बड़ियों के बारे में, मुख्य रूप से तय किए गए इंटरफ़ेस और कॉलबैक के ज़रिए बताया जाता है.
टेस्ट सुइट के डिज़ाइन के बारे में पूरी जानकारी
इस सेक्शन में, टेस्ट सुइट के डिज़ाइन के बारे में बताया गया है. यह डिज़ाइन, प्लैटफ़ॉर्म के हिसाब से ऐब्स्ट्रैक्शन के लागू होने की पुष्टि करता है.
टेस्ट सुइट के टेस्ट बनाना
Soong बिल्ड (Android.bp फ़ाइलों से तय किए गए) के लिए, टेस्ट को Android प्लैटफ़ॉर्म के बिल्ड सिस्टम के हिस्से के तौर पर कंपाइल किया जाता है. साथ ही, उन्हें atest मैनेज करता है.
टेस्ट सुइट चलाना
किसी एक प्लैटफ़ॉर्म की जांच करने के लिए:
atest कमांड का इस्तेमाल, टेस्ट के लिए सही टारगेट के साथ करें. उदाहरण के लिए, atest <module_name>. यह कमांड, Android डिवाइस या एम्युलेटर पर टेस्ट को डिप्लॉय और रन करती है.