शर्त के हिसाब से कंपाइल किए गए कोड को फिर से फ़ैक्टर किया जा सकता है, ताकि HAL इंटरफ़ेस से डाइनैमिक तौर पर वैल्यू पढ़ी जा सकें. उदाहरण के लिए:
#ifdef TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS // some code fragment #endif
इसके बाद, फ़्रेमवर्क कोड, <configstore/Utils.h>
में तय किए गए सही यूटिलिटी फ़ंक्शन को कॉल कर सकता है. यह फ़ंक्शन, फ़्रेमवर्क कोड के टाइप पर निर्भर करता है.
ConfigStore का उदाहरण
इस उदाहरण में, ConfigStore HAL में forceHwcForVirtualDisplays()
के तौर पर तय की गई TARGET_FORCE_HWC_FOR_VIRTUAL_DISPLAYS
को पढ़ने का तरीका दिखाया गया है. इसका रिटर्न टाइप OptionalBool
है:
#include <configstore/Utils.h> using namespace android::hardware::configstore; using namespace android::hardware::configstore::V1_0; static bool vsyncPhaseOffsetNs = getBool<ISurfaceFlingerConfigs, ISurfaceFlingerConfigs::forceHwcForVirtualDisplays>(false);
यूटिलिटी फ़ंक्शन (ऊपर दिए गए उदाहरण में getBool
), इंटरफ़ेस फ़ंक्शन के प्रॉक्सी के लिए हैंडल पाने के लिए configstore
सेवा से संपर्क करता है. इसके बाद, HIDL/hwbinder के ज़रिए हैंडल को लागू करके वैल्यू वापस पाता है.
उपयोगिता फ़ंक्शन
<configstore/Utils.h>
(configstore/1.0/include/configstore/Utils.h
) हर प्रिमिटिव रिटर्न टाइप के लिए यूटिलिटी फ़ंक्शन उपलब्ध कराता है. इनमें Optional[Bool|String|Int32|UInt32|Int64|UInt64]
भी शामिल है. इनकी सूची यहां दी गई है:
टाइप | फ़ंक्शन (टेंप्लेट पैरामीटर शामिल नहीं हैं) |
---|---|
OptionalBool |
bool getBool(const bool defValue) |
OptionalInt32 |
int32_t getInt32(const int32_t defValue) |
OptionalUInt32 |
uint32_t getUInt32(const uint32_t defValue) |
OptionalInt64 |
int64_t getInt64(const int64_t defValue) |
OptionalUInt64 |
uint64_t getUInt64(const uint64_t defValue) |
OptionalString |
std::string getString(const std::string &defValue) |
defValue
एक डिफ़ॉल्ट वैल्यू है. यह तब दिखती है, जब HAL लागू करने वाला व्यक्ति कॉन्फ़िगरेशन आइटम के लिए कोई वैल्यू तय नहीं करता. हर फ़ंक्शन में दो टेंप्लेट पैरामीटर होते हैं:
I
इंटरफ़ेस क्लास का नाम है.Func
, कॉन्फ़िगरेशन आइटम पाने के लिए मेंबर फ़ंक्शन पॉइंटर है.
कॉन्फ़िगरेशन वैल्यू को सिर्फ़ पढ़ा जा सकता है और इसमें बदलाव नहीं किया जा सकता. इसलिए, यूटिलिटी फ़ंक्शन, कॉन्फ़िगरेशन वैल्यू को इंटरनल तौर पर कैश मेमोरी में सेव करता है. इसके बाद के कॉल को, उसी लिंकिंग यूनिट में कैश मेमोरी में सेव की गई वैल्यू का इस्तेमाल करके ज़्यादा बेहतर तरीके से मैनेज किया जाता है.
configstore-utils का इस्तेमाल करना
ConfigStore HAL को, माइनर वर्शन के अपग्रेड के साथ काम करने के लिए डिज़ाइन किया गया है. इसका मतलब है कि जब HAL में बदलाव किया जाता है और कुछ फ़्रेमवर्क कोड, नए आइटम का इस्तेमाल करता है, तब भी /vendor
में पुराने माइनर वर्शन वाली ConfigStore सेवा का इस्तेमाल किया जा सकता है.
यह पक्का करने के लिए कि यह सुविधा नए वर्शन के साथ काम करती है, पक्का करें कि आपने इन दिशा-निर्देशों का पालन किया हो:
- जब सिर्फ़ पुराने वर्शन की सेवा उपलब्ध होती है, तब नए आइटम के लिए डिफ़ॉल्ट वैल्यू का इस्तेमाल किया जाता है. उदाहरण:
service = V1_1::IConfig::getService(); // null if V1_0 is installed value = DEFAULT_VALUE; if(service) { value = service->v1_1API(DEFAULT_VALUE); }
- क्लाइंट, उस पहले इंटरफ़ेस का इस्तेमाल करता है जिसमें ConfigStore आइटम शामिल था.
उदाहरण:
V1_1::IConfig::getService()->v1_0API(); // NOT ALLOWED V1_0::IConfig::getService()->v1_0API(); // OK
- नए वर्शन की सेवा को पुराने वर्शन के इंटरफ़ेस के लिए वापस लाया जा सकता है. यहां दिए गए उदाहरण में, अगर इंस्टॉल किया गया वर्शन v1_1 है, तो
getService()
के लिए v1_1 सेवा को वापस लाना होगा:V1_0::IConfig::getService()->v1_0API();
जब configstore-utils
लाइब्रेरी में मौजूद ऐक्सेस फ़ंक्शन का इस्तेमाल ConfigStore आइटम को ऐक्सेस करने के लिए किया जाता है, तब #1 को लागू करने से और #2 को कंपाइलर की गड़बड़ियों से सुरक्षित किया जाता है. इन वजहों से, हमारा सुझाव है कि जहां भी हो सके वहां configstore-utils
का इस्तेमाल करें.