भाषा की जानकारी

इस पेज पर, ISO/IEC 14977 Extended Backus-Naur Form (EBNF) और protobuf का इस्तेमाल करके, Vehicle Service Interface Definition Language (VSIDL) के बारे में बताया गया है. इस पेज पर, भाषा के कॉन्टेक्स्ट-फ़्री ग्रामर और भाषा के एलिमेंट के मतलब पर फ़ोकस किया गया है.

भाषा का क्रम

Meta Object Facility (MOF) के मुताबिक, VSIDL कंपाइलर (VSIDLC), पहली इमेज में दिखाई गई भाषाओं का इस्तेमाल करता है:

पहली इमेज. VSIDLC की भाषाएं.

VSIDLC मुख्य रूप से, प्रोटोकॉल बफ़र (protobuf) भाषा पर आधारित है. Protobuf का इस्तेमाल, उन डेटा टाइप को तय करने के लिए किया जाता है जिन्हें पब्लिश-सब्सक्राइब और रिमोट प्रोसीजर कॉल (RPC) कॉल का इस्तेमाल करके शेयर किया जाता है. तकनीकी नज़रिए से, VSIDL मॉडल, TextProto फ़ाइलें होती हैं. इनमें VSIDL का सिंटैक्स, protobuf फ़ाइल (syntax.proto) में तय किया जाता है. डेटा टाइप और VSIDL मॉडल तय करने के लिए, protobuf फ़ाइलों का इस्तेमाल Rust कोड जनरेट करने के लिए किया जाता है. जनरेट किए गए कोड में मुख्य रूप से ऐसे स्ट्रक्चर्ड होते हैं जो शेयर किए गए मैसेज के लिए डेटा स्ट्रक्चर लागू करते हैं. साथ ही, इनमें ऐसे Rust फ़ंक्शन होते हैं जो Rust में सर्विस यूनिट बनाने के लिए फ़ंक्शन लागू करते हैं. हालांकि, ये सर्विस यूनिट अपने-आप कॉल नहीं होती हैं. जनरेट किए गए इस Rust कोड के साथ, कस्टम Rust कोड भी होता है. यह जनरेट किए गए कोड का इस्तेमाल करके, सर्विस यूनिट को इंस्टैंशिएट करता है और ऐप्लिकेशन के कारोबार के लॉजिक को लागू करता है.

एब्सट्रैक्ट सिंटैक्स

दूसरी इमेज में, VSIDL में इस्तेमाल होने वाले मुख्य मैसेज टाइप दिखाए गए हैं:

दूसरी इमेज. VSIDL में इस्तेमाल होने वाले मुख्य मैसेज टाइप.

VSIDL एंट्री

इस सेक्शन में, VSIDL एंट्री मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

start VsidlEntry =
  "package" , ":" , String , ";" ,
  { "service_bundle" , ServiceBundle } ,
  { "extension" , ":" , Any } ,
  { "some_ip_mapping" , ":" , SomeIpMapping } ,
  { "vhal_mapping" , ":" , VhalMapping }
;

Proto की परिभाषा

// The root message for VSIDL files
message VsidlEntry {
  // Required. Package name for entities mentioned in the file.
  string package = 1;
  // Enables custom extensions beyond the standard VSIDL model.
  repeated google.protobuf.Any extension = 3;

  // SOMEIP mapping rules
  repeated sdv.someip.v1.SomeIpMapping some_ip_mapping = 4;
  // VHAL mapping rules
  repeated VhalMapping vhal_mapping = 5;
  // List of SDV service bundles defined in the file.
  repeated ServiceBundle service_bundle = 6;
}

इस्तेमाल का उदाहरण

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "Manager"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    topic: "front-right"
    capacity: 10
  }
}

जानकारी

VsidlEntry मैसेज, .vsidl एक्सटेंशन वाली VSIDL फ़ाइल के लिए, रूट कंटेनर के तौर पर काम करता है. इस मैसेज में, VSIDL की एक फ़ाइल में मौजूद सभी परिभाषाएं और कॉन्फ़िगरेशन शामिल होते हैं. VsidlEntry, टॉप-लेवल एलिमेंट है, जो बाकी सभी चीज़ों को एक साथ जोड़ता है.

मकसद:

• VSIDL फ़ाइल के पूरे स्ट्रक्चर को तय करना.
• फ़ाइल में मौजूद सभी एंटिटी के लिए, पैकेज नेमस्पेस तय करना.
• इसमें, सर्विस बंडल की परिभाषाओं का कलेक्शन शामिल होता है.
• VSIDL मॉडल में कस्टम एक्सटेंशन की अनुमति देना.
• इसमें, SOME/IP और VHAL के लिए मैपिंग के नियम शामिल होते हैं.

कंस्ट्रेंट

• पैकेज का नाम (E211): पैकेज का नाम 127 वर्णों से ज़्यादा का नहीं होना चाहिए.
• डैंगलिंग फ़ाइलें (E10B): कैटलॉग में मौजूद सभी फ़ाइलों को Android.bp फ़ाइल ग्रुप में रेफ़र किया जाना चाहिए.

सर्विस बंडल

इस सेक्शन में, सर्विस बंडल मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

ServiceBundle = "{" , { ServiceBundleElement } , "}" ;

ServiceBundleElement =
  "name" , ":" , String |
  "publisher" , Publisher |
  "subscriber" , Subscriber |
  "server" , Server |
  "client" , Client |
  "extension" , ":" , Any |
  "diagnostics_declaration" , DiagnosticsDeclaration |
  "build_cfg" , BuildConfiguration |
  "register_reflection_metadata" , Boolean
;

Proto की परिभाषा

// Defines an SDV service
message ServiceBundle {
  // Required. Name of the service bundle (without the package name).
  string name = 1;
  // List of publications the service bundle provides.
  repeated Publisher publisher = 2;
  // List of publications a service bundle subscribes to.
  repeated Subscriber subscriber = 3;
  // RPC services offered by a service bundle.
  repeated Server server = 4;
  // RPC services consumed by a service bundle.
  repeated Client client = 5;
  // Enables custom extensions beyond the standard VSIDL model.
  repeated google.protobuf.Any extension = 7;

  // Diagnostics declarations
  sdv.diagnostics.v1.DiagnosticsDeclaration diagnostics_declaration = 8;

  // Build Configuration
  optional BuildConfiguration build_cfg = 9;

  // Register metadata for service units provided by this service bundle.
  // Setting this to true will increase the memory footprint
  // and network load significantly.
  bool register_reflection_metadata = 10;
}

इस्तेमाल का उदाहरण

service_bundle {
    name: "SeatController"

    publisher {
      message: "SeatHeating"
      topic: "driver-seat"
      capacity: 10
    }
}

जानकारी

सर्विस बंडल, एक-दूसरे से जुड़ी सेवाओं, पब्लिशर, सब्सक्राइबर, RPC सर्वर, और RPC क्लाइंट के लॉजिकल ग्रुप को तय करता है. सर्विस बंडल, फ़ंक्शनैलिटी के किसी खास सेट और उनके इंटरैक्शन के लिए कंटेनर के तौर पर काम करता है.

कंस्ट्रेंट

• बंडल के नाम से जुड़ी ज़रूरी शर्तें (E209, E20A, E20B, E20C):
  • सर्विस बंडल का कोई नाम होना चाहिए.
  • नाम की शुरुआत, मान्य यूनिकोड आइडेंटिफ़ायर के शुरुआती वर्ण (आम तौर पर, कोई अक्षर) से होनी चाहिए.
  • नाम में मौजूद इसके बाद के वर्ण, मान्य यूनिकोड आइडेंटिफ़ायर के जारी रहने वाले वर्ण (आम तौर पर, अक्षर या संख्याएं) होने चाहिए.
  • नाम, Rust, Java या C++ में रिज़र्व किया गया कीवर्ड नहीं होना चाहिए.
• बंडल की ग्लोबल यूनीकनेस (E309): हर सर्विस बंडल का पूरी तरह क्वालिफ़ाइड यूनीक नाम होना चाहिए. यह नाम, उसके पैकेज और नाम पर आधारित होता है.
• इंटरनल यूनीकनेस (E100, E300, E302, E303, E308):
  • किसी एक सर्विस बंडल में, हर RPC सेवा को ज़्यादा से ज़्यादा एक सर्वर की परिभाषा से दिखाया जा सकता है.
  • किसी एक सर्विस बंडल में, MULTI_PUB पब्लिकेशन टाइप को ज़्यादा से ज़्यादा एक पब्लिशर की परिभाषा से पब्लिश किया जा सकता है.
  • किसी एक सर्विस बंडल में, उपयोगकर्ता की ओर से तय किए गए सभी सर्विस यूनिट के नाम (पब्लिशर या सर्वर के लिए) यूनीक होने चाहिए.
  • किसी एक सर्विस बंडल में, सर्विस यूनिट के सभी नाम (चाहे उपयोगकर्ता की ओर से तय किए गए हों या अपने-आप जनरेट हुए हों) यूनीक होने चाहिए.
• बिल्ड टारगेट के नामकरण के कन्वेंशन (E205, E206, E207, E208): अगर कस्टम बिल्ड टारगेट का नाम (build_cfg.target_name) दिया गया है, तो यह snake case फ़ॉर्मैट में होना चाहिए. जैसे, अंग्रेज़ी के छोटे अक्षर, संख्याएं, और सिंगल अंडरस्कोर. इसकी शुरुआत या आखिर में अंडरस्कोर नहीं होना चाहिए.
• बिल्ड टारगेट के नाम की यूनीकनेस (E301): उपयोगकर्ता की ओर से तय किया गया बिल्ड टारगेट का नाम, अन्य सर्विस बंडल के लिए अपने-आप जनरेट हुए टारगेट के नामों से अलग होना चाहिए.

पब्लिशर

इस सेक्शन में, पब्लिशर मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

Publisher = "{" , { PublisherElement } , "}" ;

PublisherElement =
  "message" , ":" , String |
  "topic" , ":" , String |
  "capacity" , ":" , Integer |
  "service_unit_name" , ":" , String
;

Proto की परिभाषा

// Represents a publisher within a service bundle.
message Publisher {
  // Name of the service unit. Name may only use characters from [a-z0-9\-]+,
  // must start with [a-z], may not end with a hyphen,
  // and may not contain consecutive hyphens.
  string service_unit_name = 3;
  // Required. The type of data being published.
  string message = 4;
  // Required. The number of messages a publication queue can hold.
  // Must be an even number >= 2.
  int64 capacity = 6;
  // Required. Unique identifier for the publication topic.
  // Must be in lowercase dash-case.
  repeated string topic = 7;
}

इस्तेमाल का उदाहरण

publisher {
  message: "SeatHeating"
  topic: "driver-heating"
  capacity: 10
}

जानकारी

Publisher मैसेज टाइप, एक ऐसे डेटा सोर्स को तय करता है जिसे ServiceBundle उपलब्ध कराता है. इस मैसेज टाइप से, पब्लिश किए जा रहे डेटा के टाइप और उस डेटा के खास विषयों और क्षमता के बारे में पता चलता है.

विषय

Publisher के हर इंस्टेंस में एक message फ़ील्ड होता है. यह पब्लिश किए जा रहे proto मैसेज को रेफ़र करता है. इसमें, कोई विषय (जिसे topic से दिखाया जाता है) और क्षमता (जिसे capacity से दिखाया जाता है) तय करना ज़रूरी है.

• विषय: पब्लिकेशन के विषय के लिए यूनीक आइडेंटिफ़ायर. यह लोअरकेस डैश-केस में होना चाहिए. उदाहरण के लिए, my-topic.
• क्षमता: इससे क्यू का साइज़ तय होता है. इसका मतलब है कि क्यू में, बिना पढ़े मैसेज को खारिज करने से पहले कितने मैसेज रखे जा सकते हैं. यह दो या इससे ज़्यादा की कोई सम संख्या होनी चाहिए.

उपयोगकर्ता की ओर से तय किए गए नाम

पब्लिशर के पास, उपयोगकर्ता की ओर से तय किए गए सर्विस यूनिट के नाम हो सकते हैं. ये नाम, अपने-आप चुने गए सर्विस यूनिट के नामों को बदल सकते हैं. इस सुविधा से, छोटे नाम चुने जा सकते हैं. अगर कोई पब्लिशर, उपयोगकर्ता की ओर से तय किए गए सर्विस यूनिट के नाम का इस्तेमाल करता है, तो वह सिर्फ़ एक इंस्टेंस का इस्तेमाल कर सकता है. इससे, सर्विस यूनिट का नाम किसी एक इंस्टेंस को यूनीक तरीके से असाइन किया जाता है.

# VALID: A publisher assigns a user-defined name to a single instance
publisher {
  message: "SeatHeating"
  topic: "seat-heating-status"
  service_unit_name: "heating-is-off"
}

# ERROR: user-defined names are only allowed if there's only a single instance
publisher {
  message: "SeatHeating"
  topic: "seat-heating-status"
  service_unit_name: "heating-status"
}

कंस्ट्रेंट

• पब्लिशर की जगह (E300): एक ही MULTI_PUB टाइप के पब्लिशर को अलग-अलग सर्विस बंडल में तय किया जाना चाहिए.
• लोकल नाम की यूनीकनेस (E302): किसी एक सर्विस बंडल में, सभी पब्लिशर के पास, उपयोगकर्ता की ओर से तय किए गए सर्विस यूनिट के यूनीक नाम होने चाहिए.
• ग्लोबल नाम की यूनीकनेस (E304): एक ही पब्लिकेशन टाइप के पब्लिशर के पास, सभी सर्विस बंडल में उपयोगकर्ता की ओर से तय किए गए सर्विस यूनिट के ग्लोबल तौर पर यूनीक नाम होने चाहिए.
• सिंगल चैनल के नामकरण (E306): उपयोगकर्ता की ओर से तय किए गए सर्विस यूनिट के नाम सिर्फ़ उन पब्लिशर को असाइन किए जा सकते हैं जो सिर्फ़ एक इंस्टेंस को हैंडल करते हैं.
• सिंगल पब्लिशर की सीमा (E307): SINGLE_PUB के तौर पर मार्क किए गए किसी protobuf मैसेज को, पूरे सिस्टम में सिर्फ़ एक पब्लिशर पब्लिश कर सकता है.
• सर्विस यूनिट के नाम की यूनीकनेस (E308): सर्विस यूनिट के सभी नाम (चाहे वे जनरेट किए गए हों या उपयोगकर्ता की ओर से तय किए गए हों) अपने सर्विस बंडल में यूनीक होने चाहिए. जनरेट किए गए नामों के साथ होने वाले टकरावों को हल करने के लिए, उपयोगकर्ता की ओर से तय किए गए नामों का इस्तेमाल किया जाना चाहिए.
• वैरिएंट तय करने की ज़रूरी शर्त (E501): जब कोई पब्लिशर, एक से ज़्यादा वैरिएंट वाले टाइप के लिए, उपयोगकर्ता की ओर से तय किए गए नाम का इस्तेमाल करता है, तो उसे साफ़ तौर पर उस वैरिएंट के बारे में बताना होगा जिसे वह पब्लिश करता है.
• सब्सक्राइबर के लिए पब्लिशर का होना (E504): तय किए गए हर सब्सक्राइबर के लिए, तय किए गए टाइप और वैरिएंट के लिए कम से कम एक पब्लिशर होना ज़रूरी है.
• पब्लिशर का मान्य टाइप (E601): किसी पब्लिशर को ऐसे टाइप को रेफ़र करना होगा जो मौजूदा protobuf मैसेज से मेल खाता हो.
• पब्लिकेशन के एनोटेशन की ज़रूरी शर्त (E602): किसी पब्लिशर के रेफ़र किए गए protobuf मैसेज टाइप में, SdvPublication एनोटेशन शामिल होना चाहिए.
• वैरिएंट का मान्य इस्तेमाल (E606): अगर कोई पब्लिशर, कोई वैरिएंट (इंस्टेंस) तय करता है, तो वह वैरिएंट, protobuf में पब्लिकेशन टाइप के लिए तय किए गए instances_enum में मौजूद होना चाहिए.
• वैरिएंट तय करने की शर्त (E607): कोई पब्लिशर, साफ़ तौर पर कोई वैरिएंट (इंस्टेंस) सिर्फ़ तब तय कर सकता है, जब पब्लिकेशन टाइप, protobuf में instances_enum तय करता हो.
• विषय का नामकरण (E20D, E20F): विषय, लोअरकेस डैश-केस में होने चाहिए और इनमें 127 से ज़्यादा वर्ण नहीं होने चाहिए.
• विषय की यूनीकनेस (E314): सभी पब्लिशर के लिए, विषय ग्लोबल तौर पर यूनीक होने चाहिए.
• क्षमता से जुड़ी ज़रूरी शर्तें (E406, E407): क्षमता तय करना ज़रूरी है. यह दो या इससे ज़्यादा की कोई सम संख्या होनी चाहिए.

सब्सक्राइबर

इस सेक्शन में, सब्सक्राइबर मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

Subscriber = "{" , { SubscriberElement } , "}" ;

SubscriberElement =
  "message" , ":" , String |
  "topic" , ":" , String
;

Proto की परिभाषा

// Represents a subscriber within a service bundle.
message Subscriber {
  // Required. The type of data being subscribed to.
  string message = 4;
  // Required. Specific topic(s) of the message to subscribe to.
  // Must match the publisher's topic.
  repeated string topic = 6;
}

इस्तेमाल का उदाहरण

subscriber {
  message: "SeatHeating"
  topic: "driver-seat"
}

जानकारी

Subscriber मैसेज, पब्लिकेशन के रिसीवर को तय करता है. इसे ServiceBundle उपलब्ध कराता है. इस मैसेज से, सब्सक्राइब किए जा रहे डेटा के टाइप और उस पब्लिकेशन के खास विषयों के बारे में पता चलता है. अगर किसी विषय के लिए एक से ज़्यादा पब्लिशर हैं, तो सब्सक्राइबर को उन सभी के पब्लिश किए गए मैसेज मिलते हैं.

कंस्ट्रेंट

• पब्लिशर का होना (E504): तय किए गए हर सब्सक्राइबर के लिए, कम से कम एक पब्लिशर होना ज़रूरी है. यह पब्लिशर, तय किए गए पब्लिकेशन टाइप और वैरिएंट को पब्लिश करता हो.
• सब्सक्रिप्शन का मान्य टाइप (E608): किसी सब्सक्राइबर को ऐसे टाइप को रेफ़र करना होगा जो SdvPublication एनोटेशन के साथ तय किए गए मौजूदा protobuf मैसेज से मेल खाता हो.
• वैरिएंट का मान्य सब्सक्रिप्शन (E609): अगर कोई सब्सक्राइबर, कोई वैरिएंट (इंस्टेंस) तय करता है, तो वह वैरिएंट, संबंधित protobuf पब्लिकेशन टाइप के instances_enum में तय की गई कोई मान्य वैल्यू होनी चाहिए.
• विषय तय करना ज़रूरी है (E408): सब्सक्राइबर के लिए, विषय तय करना ज़रूरी है.
• विषय को फिर से तय करना (E311): सब्सक्राइबर के विषयों को एक ही सर्विस बंडल में फिर से तय नहीं किया जाना चाहिए.

RPC सर्वर

इस सेक्शन में, RPC सर्वर मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

Server = "{" , { ServerElement } , "}" ;

ServerElement =
  "service" , ":" , String |
  "channel" , ":" , String |
  "service_unit_name" , ":" , String
;

Proto की परिभाषा

// Represents an RPC server within a service bundle.
message Server {
  // Deprecated. Name of the service unit.
  string service_unit_name = 3 [ deprecated = true ];
  // Required. Name of the RPC service.
  string service = 4;
  // Required. Name of the RPC channel.
  // Must be in lowercase dash-case.
  string channel = 5;
}

इस्तेमाल का उदाहरण

server {
  service: "SetTemperature"
  channel: "temp-setter"
}

जानकारी

Server मैसेज, एक ऐसे RPC सर्वर को तय करता है जिसे ServiceBundle उपलब्ध कराता है. इस मैसेज से, उस सेवा के बारे में पता चलता है जिसे सर्वर लागू करता है. साथ ही, इससे RPC चैनल के बारे में भी पता चलता है.

RPC सर्वर, तरीकों का एक सेट दिखाता है. क्लाइंट, इन्हें रिमोट तरीके से शुरू कर सकते हैं. service फ़ील्ड, उस RPC सेवा का नाम तय करता है जिसे सर्वर लागू करता है. इस सेवा को किसी proto फ़ाइल में तय किया जाता है और इसे कस्टम Rust कोड में लागू किया जाता है. protobuf सेवा की परिभाषा में तय किए गए तरीके के मुताबिक, RPC सेवाओं में यूनरी, क्लाइंट-स्ट्रीमिंग, और सर्वर-स्ट्रीमिंग के तरीके शामिल हो सकते हैं. channel फ़ील्ड, कम्यूनिकेशन एंडपॉइंट तय करता है. यह फ़ील्ड ज़रूरी है (E409).

कंस्ट्रेंट

• सेवा की परिभाषा (E603): किसी RPC सर्वर को service की ऐसी वैल्यू तय करनी होगी जो मौजूदा protobuf RPC service की वैल्यू से मेल खाती हो.
• हर सेवा के लिए सर्वर की सीमा (E100): किसी एक सर्विस बंडल में, किसी खास RPC service को ज़्यादा से ज़्यादा एक सर्वर की परिभाषा से दिखाया जा सकता है.
• चैनल का नामकरण (E20E): RPC चैनल, लोअरकेस डैश-केस में होने चाहिए.
• चैनल तय करना ज़रूरी है (E409): RPC चैनल तय करना ज़रूरी है.
• चैनल की यूनीकनेस (E40B): RPC चैनल का इस्तेमाल सिर्फ़ एक सेवा के लिए किया जाना चाहिए.

RPC क्लाइंट

इस सेक्शन में, RPC क्लाइंट मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

Client = "{" , { ClientElement } , "}" ;

ClientElement =
  "service" , ":" , String |
  "channel" , ":" , String
;

Proto की परिभाषा

// Represents an RPC client within a service bundle.
message Client {
  // Required. Name of the RPC service.
  string service = 2;
  // Required. Name of the RPC channel.
  // Must match the server's channel and be in lowercase dash-case.
  string channel = 3;
}

इस्तेमाल का उदाहरण

client {
  service: "SetTemperature"
  channel: "temp-setter"
}

जानकारी

client, एक ऐसे RPC क्लाइंट को तय करता है जिसका इस्तेमाल ServiceBundle करता है. client से, उस सेवा के बारे में पता चलता है जिसके साथ क्लाइंट इंटरैक्ट करता है. साथ ही, इससे कनेक्ट करने के लिए चैनल के बारे में भी पता चलता है. सेवा की परिभाषा के आधार पर, क्लाइंट यूनरी, क्लाइंट-स्ट्रीमिंग, और सर्वर-स्ट्रीमिंग के तरीकों के साथ इंटरैक्ट कर सकता है.

कंस्ट्रेंट

• सेवा की परिभाषा (E60A): किसी RPC क्लाइंट को service की ऐसी वैल्यू तय करनी होगी जो मौजूदा protobuf service की परिभाषा से मेल खाती हो.
• सेवा के सोर्स की यूनीकनेस (E60B): RPC क्लाइंट के service के रेफ़र किए गए protobuf service की परिभाषा, सभी protobuf फ़ाइलों में यूनीक तरीके से तय की जानी चाहिए. इसे एक से ज़्यादा बार तय नहीं किया जाना चाहिए.
• चैनल तय करना ज़रूरी है (E409): RPC चैनल तय करना ज़रूरी है.

बिल्ड कॉन्फ़िगरेशन

इस सेक्शन में, बिल्ड कॉन्फ़िगरेशन मैसेज टाइप के बारे में बताया गया है.

EBNF ग्रामर

BuildConfiguration = "{" , BuildConfigurationElement, "}" ;

BuildConfigurationElement =
  "target_name" , ":" , String |
  "skip_codegen" , ":" , Boolean
;

Proto की परिभाषा

// Defines additional information used to configure build settings
message BuildConfiguration {
  /// Build target name
  optional string target_name = 1;
  // Do not generate code for this service bundle
  optional bool skip_codegen = 2;
}

इस्तेमाल का उदाहरण

build_cfg {
  target_name: "my_custom_target_name"
  skip_codegen: false
}

जानकारी

BuildConfiguration , कोड जनरेट करने के लिए ServiceBundle के नॉन-स्टैंडर्ड पैरामीटर कॉन्फ़िगर करता है. सभी बिल्ड कॉन्फ़िगरेशन ज़रूरी नहीं हैं.

• target_name (ज़रूरी नहीं string): इससे, Android.bp फ़ाइलों में बिल्ड टारगेट का नाम तय होता है. इसका इस्तेमाल, अपने-आप चुने गए नामों के मुकाबले छोटे नामों वाले टारगेट के नाम सेट करने के लिए करें.
• skip_codegen (ज़रूरी नहीं bool): इससे पता चलता है कि इस सर्विस बंडल के लिए कोड जनरेट करने की प्रोसेस को स्किप किया जाना चाहिए या नहीं. अगर इसे true पर सेट किया जाता है, तो इस खास सर्विस बंडल के लिए कोई कोड जनरेट नहीं किया जाता. यह उन सर्विस बंडल के लिए काम का हो सकता है जिन्हें मैन्युअल तरीके से लागू किया जाता है. डिफ़ॉल्ट रूप से, यह false पर सेट होता है.

कंस्ट्रेंट

• टारगेट के नाम का फ़ॉर्मैट (E205, E206, E207, E208): अगर कस्टम बिल्ड टारगेट का नाम (build_cfg.target_name) दिया गया है, तो यह snake case फ़ॉर्मैट में होना चाहिए:
  • इसमें सिर्फ़ अंग्रेज़ी के छोटे अक्षर (a से z), संख्याएं (0 से 9), और अंडरस्कोर (_) शामिल होने चाहिए.
  • इसमें लगातार अंडरस्कोर (__) नहीं होने चाहिए.
  • इसकी शुरुआत में अंडरस्कोर नहीं होना चाहिए.
  • इसके आखिर में अंडरस्कोर नहीं होना चाहिए.
• टारगेट के नाम की यूनीकनेस (E301): उपयोगकर्ता की ओर से तय किया गया build_cfg.target_name, बिल्ड सिस्टम में यूनीक होना चाहिए. साथ ही, यह अन्य सर्विस बंडल की परिभाषाओं से जनरेट हुए टारगेट के नामों से अलग होना चाहिए.