इंटरफ़ेस हैश

इस दस्तावेज़ में, HIDL इंटरफ़ेस हैशिंग के बारे में बताया गया है. यह एक ऐसा तरीका है जिससे इंटरफ़ेस में अनचाहे बदलावों को रोका जा सकता है. साथ ही, यह भी पक्का किया जा सकता है कि इंटरफ़ेस में किए गए बदलावों की पूरी तरह से जांच की गई है. यह तरीका ज़रूरी है, क्योंकि HIDL इंटरफ़ेस के वर्शन होते हैं. इसका मतलब है कि किसी इंटरफ़ेस के रिलीज़ होने के बाद, उसमें बदलाव नहीं किया जाना चाहिए. हालांकि, ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) को बनाए रखने के लिए, उसमें बदलाव किया जा सकता है. जैसे, टिप्पणी में सुधार करना.

लेआउट

हर पैकेज की रूट डायरेक्ट्री (जैसे, android.hardware से hardware/interfaces पर मैप करना या vendor.foo से vendor/foo/hardware/interfaces पर मैप करना) में एक current.txt फ़ाइल होनी चाहिए. इसमें, रिलीज़ की गई सभी HIDL इंटरफ़ेस फ़ाइलों की सूची होनी चाहिए.

# current.txt files support comments starting with a '#' character
# this file, for instance, would be vendor/foo/hardware/interfaces/current.txt

# Each line has a SHA-256 hash followed by the name of an interface.
# They have been shortened in this doc for brevity but they are
# 64 characters in length in an actual current.txt file.
d4ed2f0e...995f9ec4 vendor.awesome.foo@1.0::IFoo # comments can also go here

# types.hal files are also noted in current.txt files
c84da9f5...f8ea2648 vendor.awesome.foo@1.0::types

# Multiple hashes can be in the file for the same interface. This can be used
# to note how ABI sustaining changes were made to the interface.
# For instance, here is another hash for IFoo:

# Fixes type where "FooCallback" was misspelled in comment on "FooStruct"
822998d7...74d63b8c vendor.awesome.foo@1.0::IFoo

ध्यान दें: Google, HIDL current.txt फ़ाइलों को अलग-अलग सेक्शन में बांटता है, ताकि यह पता लगाया जा सके कि कौनसे हैश कहां से आए हैं: पहला सेक्शन Android 8 में रिलीज़ किया गया है; अगला सेक्शन Android 8 MR1 में रिलीज़ किया गया होगा. हमारा सुझाव है कि आप अपनी current.txt फ़ाइल में मिलते-जुलते लेआउट का इस्तेमाल करें.

hidl-gen की मदद से हैश करना

current.txt फ़ाइल में मैन्युअल तरीके से या hidl-gen का इस्तेमाल करके हैश जोड़ा जा सकता है. नीचे दिए गए कोड स्निपेट में, उन निर्देशों के उदाहरण दिए गए हैं जिनका इस्तेमाल करके hidl-gen फ़ाइल को मैनेज किया जा सकता है. इसमें हैश को छोटा किया गया है:current.txt

hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::types
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0::INfc
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0
9626fd18...f9d298a6 vendor.awesome.nfc@1.0::types
07ac2dc9...11e3cf57 vendor.awesome.nfc@1.0::INfc
f2fe5442...72655de6 vendor.awesome.nfc@1.0::INfcClientCallback
hidl-gen -L hash -r vendor.awesome:vendor/awesome/hardware/interfaces -r android.hardware:hardware/interfaces -r android.hidl:system/libhidl/transport vendor.awesome.nfc@1.0 >> vendor/awesome/hardware/interfaces/current.txt

चेतावनी: पहले से रिलीज़ किए गए इंटरफ़ेस के लिए, हैश को बदलें इस तरह के इंटरफ़ेस को बदलते समय, current.txt फ़ाइल के आखिर में नया हैश जोड़ें. ज़्यादा जानकारी के लिए, एबीआई की स्थिरता देखें.

hidl-gen के ज़रिए जनरेट की गई हर इंटरफ़ेस डेफ़िनिशन लाइब्रेरी में हैश शामिल होते हैं. इन्हें IBase::getHashChain को कॉल करके वापस पाया जा सकता है. जब hidl-gen किसी इंटरफ़ेस को संकलित कर रहा होता है, तो वह एचएएल पैकेज की रूट डायरेक्ट्री में मौजूद current.txt फ़ाइल की जांच करता है. इससे यह पता चलता है कि एचएएल में बदलाव हुआ है या नहीं:

  • अगर एचएएल के लिए कोई हैश नहीं मिलता है, तो इंटरफ़ेस को रिलीज़ नहीं किया गया (डिवेलपमेंट में है) माना जाता है और कंपाइलेशन जारी रहता है.
  • अगर हैश मिलते हैं, तो उन्हें मौजूदा इंटरफ़ेस के हिसाब से जांचा जाता है:
    • अगर इंटरफ़ेस हैश से मेल खाता है, तो कंपाइलेशन शुरू हो जाता है.
    • अगर इंटरफ़ेस किसी हैश से मेल नहीं खाता है, तो कंपाइलेशन रोक दिया जाता है. इसका मतलब है कि पहले रिलीज़ किए गए इंटरफ़ेस में बदलाव किया जा रहा है.
      • एबीआई को बनाए रखने वाले बदलाव (एबीआई के स्थिर होने के बारे में जानें) के लिए, कंपाइल करने से पहले current.txt फ़ाइल में बदलाव करना ज़रूरी है.
      • इंटरफ़ेस के छोटे या बड़े वर्शन के अपग्रेड में ही अन्य सभी बदलाव किए जाने चाहिए.

ABI की स्थिरता

एबीआई में बाइनरी लिंकेज/कॉल करने के तरीके वगैरह शामिल होते हैं. अगर एबीआई या एपीआई में बदलाव होता है, तो इंटरफ़ेस अब उस सामान्य system.img के साथ काम नहीं करता जो आधिकारिक इंटरफ़ेस के साथ कॉम्पाइल किया गया था.

यह पक्का करना कि इंटरफ़ेस के वर्शन हों और एबीआई स्थिर हो, कई वजहों से ज़रूरी है:

  • इससे यह पक्का होता है कि आपका लागू किया गया तरीका, वेंडर टेस्ट सुइट (वीटीएस) की जांच में पास हो सकता है. इससे आपको सिर्फ़ फ़्रेमवर्क के लिए ओटीए करने में मदद मिलती है.
  • OEM के तौर पर, इससे आपको बोर्ड सपोर्ट पैकेज (बीएसपी) उपलब्ध कराने में मदद मिलती है. यह पैकेज इस्तेमाल करने में आसान और नियमों के मुताबिक होता है.
  • इससे आपको यह ट्रैक करने में मदद मिलती है कि कौनसे इंटरफ़ेस रिलीज़ किए जा सकते हैं. current.txt को इंटरफ़ेस डायरेक्ट्री का मैप माना जा सकता है. इसकी मदद से, पैकेज रूट में दिए गए सभी इंटरफ़ेस का इतिहास और स्थिति देखी जा सकती है.

किसी ऐसे इंटरफ़ेस के लिए नया हैश जोड़ते समय जिसकी जानकारी पहले से ही current.txt में मौजूद है, पक्का करें कि सिर्फ़ ऐसे हैश जोड़े जाएं जो उन इंटरफ़ेस को दिखाते हों जिनमें एबीआई की स्थिरता बनी रहती है. यहां दिए गए बदलावों की समीक्षा करें:

बदलाव करने की अनुमति है
  • टिप्पणी में बदलाव करना (जब तक कि इससे किसी तरीके का मतलब न बदले).
  • किसी पैरामीटर का नाम बदलना.
  • रिटर्न पैरामीटर का नाम बदलना.
  • एनोटेशन बदलना.
बदलाव करने की अनुमति नहीं है
  • आर्ग्युमेंट, तरीकों वगैरह का क्रम बदलना.
  • किसी इंटरफ़ेस का नाम बदलना या उसे किसी नए पैकेज में ले जाना.
  • पैकेज का नाम बदलना.
  • इंटरफ़ेस में कहीं भी कोई तरीका/स्ट्रक्चर फ़ील्ड वगैरह जोड़ना.
  • ऐसा कोई भी कॉन्टेंट जिससे C++ vtable में गड़बड़ी हो.
  • इत्यादि.