अपने डिवाइस और उत्पाद के लिए मेकफ़ाइलें बनाने के लिए इस पृष्ठ में दी गई जानकारी का उपयोग करें।
प्रत्येक नए एंड्रॉइड मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। एंड्रॉइड सूंग बिल्ड सिस्टम का उपयोग करता है। एंड्रॉइड बिल्ड सिस्टम के बारे में अधिक जानकारी के लिए बिल्डिंग एंड्रॉइड देखें।
परतों के निर्माण को समझें
बिल्ड पदानुक्रम में अमूर्त परतें शामिल होती हैं जो किसी डिवाइस की भौतिक संरचना के अनुरूप होती हैं। इन परतों का वर्णन नीचे दी गई तालिका में किया गया है। प्रत्येक परत एक-से-अनेक संबंध में अपने ऊपर वाले से संबंधित होती है। उदाहरण के लिए, एक आर्किटेक्चर में एक से अधिक बोर्ड हो सकते हैं और प्रत्येक बोर्ड में एक से अधिक उत्पाद हो सकते हैं। आप किसी दिए गए परत में एक तत्व को उसी परत में एक तत्व की विशेषज्ञता के रूप में परिभाषित कर सकते हैं, जो नकल को समाप्त करता है और रखरखाव को सरल बनाता है।
परत | उदाहरण | विवरण |
---|---|---|
उत्पाद | myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk | उत्पाद परत एक शिपिंग उत्पाद के फीचर विनिर्देश को परिभाषित करती है जैसे कि निर्माण के लिए मॉड्यूल, समर्थित स्थान और विभिन्न स्थानों के लिए कॉन्फ़िगरेशन। दूसरे शब्दों में, यह समग्र उत्पाद का नाम है. उत्पाद-विशिष्ट चर को उत्पाद परिभाषा मेकफ़ाइल्स में परिभाषित किया गया है। एक उत्पाद अन्य उत्पाद परिभाषाओं से विरासत में मिल सकता है, जिससे रखरखाव सरल हो जाता है। एक सामान्य तरीका एक आधार उत्पाद बनाना है जिसमें सभी उत्पादों पर लागू होने वाली विशेषताएं शामिल हों, फिर उस आधार उत्पाद के आधार पर उत्पाद प्रकार बनाएं। उदाहरण के लिए, दो उत्पाद जो केवल अपने रेडियो (सीडीएमए बनाम जीएसएम) द्वारा भिन्न होते हैं, एक ही आधार उत्पाद से प्राप्त हो सकते हैं जो रेडियो को परिभाषित नहीं करता है। |
बोर्ड/डिवाइस | मार्लिन, ब्लूलाइन, मूंगा | बोर्ड/डिवाइस परत डिवाइस पर प्लास्टिक की भौतिक परत (यानी, डिवाइस का औद्योगिक डिजाइन) का प्रतिनिधित्व करती है। यह परत किसी उत्पाद की मूल रूपरेखाओं का भी प्रतिनिधित्व करती है। इनमें बोर्ड पर परिधीय उपकरण और उनका विन्यास शामिल है। उपयोग किए गए नाम विभिन्न बोर्ड/डिवाइस कॉन्फ़िगरेशन के लिए केवल कोड हैं। |
मेहराब | आर्म, x86, आर्म64, x86_64 | आर्किटेक्चर परत बोर्ड पर चल रहे प्रोसेसर कॉन्फ़िगरेशन और एप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) का वर्णन करती है। |
बिल्ड वेरिएंट का उपयोग करें
किसी विशेष उत्पाद का निर्माण करते समय, अंतिम रिलीज़ बिल्ड में मामूली बदलाव करना उपयोगी होता है। मॉड्यूल परिभाषा में, मॉड्यूल LOCAL_MODULE_TAGS
के साथ टैग निर्दिष्ट कर सकता है, जो optional
(डिफ़ॉल्ट), debug
और eng
के एक या अधिक मान हो सकते हैं।
यदि कोई मॉड्यूल कोई टैग निर्दिष्ट नहीं करता है ( LOCAL_MODULE_TAGS
द्वारा), तो उसका टैग डिफ़ॉल्ट रूप से optional
हो जाता है। एक वैकल्पिक मॉड्यूल केवल तभी स्थापित किया जाता है जब यह PRODUCT_PACKAGES
वाले उत्पाद कॉन्फ़िगरेशन के लिए आवश्यक हो।
ये वर्तमान में परिभाषित बिल्ड वेरिएंट हैं।
प्रकार | विवरण |
---|---|
eng | यह डिफ़ॉल्ट स्वाद है.
|
user | इस संस्करण का उद्देश्य अंतिम रिलीज़ बिट्स होना था।
|
userdebug | इन अपवादों के साथ user के समान:
|
यूजरडिबग के लिए दिशानिर्देश
परीक्षण में यूजरडीबग बिल्ड चलाने से डिवाइस डेवलपर्स को इन-डेवलपमेंट रिलीज के प्रदर्शन और शक्ति को समझने में मदद मिलती है। उपयोगकर्ता और उपयोगकर्ताडीबग बिल्ड के बीच स्थिरता बनाए रखने के लिए, और डिबगिंग के लिए उपयोग किए जाने वाले बिल्ड में विश्वसनीय मेट्रिक्स प्राप्त करने के लिए, डिवाइस डेवलपर्स को इन दिशानिर्देशों का पालन करना चाहिए:
- यूजरडिबग को रूट एक्सेस सक्षम उपयोगकर्ता बिल्ड के रूप में परिभाषित किया गया है, सिवाय इसके:
- यूजरडिबग-ओनली ऐप्स जो केवल उपयोगकर्ता द्वारा ऑन-डिमांड चलाए जाते हैं
- संचालन जो केवल निष्क्रिय रखरखाव (चार्जर/पूरी तरह से चार्ज होने पर) के दौरान चलते हैं, जैसे पृष्ठभूमि संकलन के लिए
dex2oatd
बनामdex2oat
उपयोग करना
- उन सुविधाओं को शामिल न करें जो बिल्ड प्रकार के आधार पर डिफ़ॉल्ट रूप से सक्षम/अक्षम हैं। डेवलपर्स को किसी भी प्रकार की लॉगिंग का उपयोग करने से हतोत्साहित किया जाता है जो बैटरी जीवन को प्रभावित करती है, जैसे डिबग लॉगिंग या हीप डंपिंग।
- यूजरडीबग में डिफ़ॉल्ट रूप से सक्षम किसी भी डिबगिंग सुविधाओं को स्पष्ट रूप से परिभाषित किया जाना चाहिए और प्रोजेक्ट पर काम कर रहे सभी डेवलपर्स के साथ साझा किया जाना चाहिए। आपको डिबगिंग सुविधाओं को केवल सीमित समय के आधार पर सक्षम करना चाहिए जब तक कि जिस समस्या को आप डिबग करने का प्रयास कर रहे हैं वह हल न हो जाए।
संसाधन ओवरले के साथ बिल्ड को अनुकूलित करें
एंड्रॉइड बिल्ड सिस्टम बिल्ड समय पर किसी उत्पाद को अनुकूलित करने के लिए संसाधन ओवरले का उपयोग करता है। संसाधन ओवरले उन संसाधन फ़ाइलों को निर्दिष्ट करते हैं जो डिफ़ॉल्ट के शीर्ष पर लागू होती हैं। संसाधन ओवरले का उपयोग करने के लिए, अपनी शीर्ष-स्तरीय निर्देशिका से संबंधित पथ पर PRODUCT_PACKAGE_OVERLAYS
सेट करने के लिए प्रोजेक्ट बिल्डफ़ाइल को संशोधित करें। जब बिल्ड सिस्टम संसाधनों की खोज करता है तो वह पथ वर्तमान रूट के साथ खोजा गया छाया रूट बन जाता है।
सबसे सामान्य रूप से अनुकूलित सेटिंग्स फ़ाइल frameworks/base/core/res/res/values/config.xml में समाहित हैं।
इस फ़ाइल पर संसाधन ओवरले सेट करने के लिए, निम्न में से किसी एक का उपयोग करके प्रोजेक्ट बिल्डफ़ाइल में ओवरले निर्देशिका जोड़ें:
PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay
या
PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay
फिर, निर्देशिका में एक ओवरले फ़ाइल जोड़ें, उदाहरण के लिए:
vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml
ओवरले config.xml
फ़ाइल में पाई गई कोई भी स्ट्रिंग या स्ट्रिंग सारणी मूल फ़ाइल में पाई गई स्ट्रिंग को प्रतिस्थापित कर देती है।
एक उत्पाद बनाएं
आप अपने डिवाइस के लिए स्रोत फ़ाइलों को कई अलग-अलग तरीकों से व्यवस्थित कर सकते हैं। यहां पिक्सेल कार्यान्वयन को व्यवस्थित करने के एक तरीके का संक्षिप्त विवरण दिया गया है।
पिक्सेल को marlin
नामक मुख्य डिवाइस कॉन्फ़िगरेशन के साथ कार्यान्वित किया गया है। इस डिवाइस कॉन्फ़िगरेशन से, उत्पाद परिभाषा मेकफ़ाइल के साथ एक उत्पाद बनाया जाता है जो डिवाइस के बारे में नाम और मॉडल जैसी उत्पाद-विशिष्ट जानकारी घोषित करता है। यह सब कैसे सेट किया गया है यह देखने के लिए आप device/google/marlin
निर्देशिका देख सकते हैं।
उत्पाद मेकफ़ाइलें लिखें
निम्नलिखित चरण बताते हैं कि पिक्सेल उत्पाद लाइन के समान उत्पाद मेकफ़ाइल कैसे सेट करें:
- अपने उत्पाद के लिए एक
device/ <company-name> / <device-name>
निर्देशिका बनाएं। उदाहरण के लिए,device/google/marlin
। इस निर्देशिका में आपके डिवाइस के लिए स्रोत कोड के साथ-साथ उन्हें बनाने के लिए मेकफ़ाइलें भी शामिल होंगी। - एक
device.mk
मेकफ़ाइल बनाएं जो डिवाइस के लिए आवश्यक फ़ाइलों और मॉड्यूल की घोषणा करता है। उदाहरण के लिए,device/google/marlin/device-marlin.mk
देखें। - डिवाइस के आधार पर एक विशिष्ट उत्पाद बनाने के लिए उत्पाद परिभाषा मेकफ़ाइल बनाएं। निम्नलिखित मेकफ़ाइल उदाहरण के तौर पर
device/google/marlin/aosp_marlin.mk
से लिया गया है। ध्यान दें कि उत्पाद मेकफ़ाइल के माध्यम सेdevice/google/marlin/device-marlin.mk
औरvendor/google/marlin/device-vendor-marlin.mk
फ़ाइलों से प्राप्त होता है, साथ ही उत्पाद-विशिष्ट जानकारी जैसे नाम, ब्रांड, की घोषणा भी करता है। और मॉडल.# Inherit from the common Open Source product configuration $(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk) $(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk) PRODUCT_NAME := aosp_marlin PRODUCT_DEVICE := marlin PRODUCT_BRAND := Android PRODUCT_MODEL := AOSP on msm8996 PRODUCT_MANUFACTURER := Google PRODUCT_RESTRICT_VENDOR_FILES := true PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin $(call inherit-product, device/google/marlin/device-marlin.mk) $(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk) PRODUCT_PACKAGES += \ Launcher3QuickStep \ WallpaperPicker
अतिरिक्त उत्पाद-विशिष्ट चर के लिए उत्पाद परिभाषा चर सेट करना देखें जिन्हें आप अपनी मेकफ़ाइल में जोड़ सकते हैं।
- एक
AndroidProducts.mk
फ़ाइल बनाएं जो उत्पाद की मेकफ़ाइल्स को इंगित करती है। इस उदाहरण में, केवल उत्पाद परिभाषा मेकफ़ाइल की आवश्यकता है। नीचे दिया गया उदाहरणdevice/google/marlin/AndroidProducts.mk
से है (जिसमें मार्लिन, पिक्सेल और सेलफ़िश, पिक्सेल XL दोनों शामिल हैं, जिसने सबसे अधिक कॉन्फ़िगरेशन साझा किया है):PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/aosp_marlin.mk \ $(LOCAL_DIR)/aosp_sailfish.mk COMMON_LUNCH_CHOICES := \ aosp_marlin-userdebug \ aosp_sailfish-userdebug
- एक
BoardConfig.mk
मेकफ़ाइल बनाएं जिसमें बोर्ड-विशिष्ट कॉन्फ़िगरेशन शामिल हों। उदाहरण के लिए,device/google/marlin/BoardConfig.mk
देखें। - केवल एंड्रॉइड 9 और उससे पहले के संस्करण के लिए , बिल्ड में अपने उत्पाद (एक "लंच कॉम्बो") को डैश द्वारा अलग किए गए बिल्ड वैरिएंट के साथ जोड़ने के लिए एक
vendorsetup.sh
फ़ाइल बनाएं। उदाहरण के लिए:add_lunch_combo <product-name>-userdebug
- इस बिंदु पर, आप एक ही डिवाइस के आधार पर अधिक उत्पाद प्रकार बना सकते हैं।
उत्पाद परिभाषा चर सेट करें
उत्पाद-विशिष्ट चर उत्पाद के मेकफ़ाइल में परिभाषित किए गए हैं। तालिका उत्पाद परिभाषा फ़ाइल में बनाए गए कुछ चर दिखाती है।
चर | विवरण | उदाहरण |
---|---|---|
PRODUCT_AAPT_CONFIG | पैकेज बनाते समय उपयोग करने के लिए aapt कॉन्फ़िगरेशन। | |
PRODUCT_BRAND | सॉफ़्टवेयर जिस ब्रांड (उदाहरण के लिए, वाहक) के लिए अनुकूलित किया गया है। | |
PRODUCT_CHARACTERISTICS | किसी पैकेज में भिन्न-भिन्न संसाधनों को जोड़ने की अनुमति देने के लिए aapt विशेषताएँ। | tablet , nosdcard |
PRODUCT_COPY_FILES | source_path:destination_path जैसे शब्दों की सूची। इस उत्पाद का निर्माण करते समय स्रोत पथ की फ़ाइल को गंतव्य पथ पर कॉपी किया जाना चाहिए। प्रतिलिपि चरणों के नियम config/makefile में परिभाषित हैं। | |
PRODUCT_DEVICE | औद्योगिक डिज़ाइन का नाम. यह बोर्ड का नाम भी है, और बिल्ड सिस्टम इसका उपयोग BoardConfig.mk पता लगाने के लिए करता है। | tuna |
PRODUCT_LOCALES | दो-अक्षर वाले भाषा कोड, दो-अक्षर वाले देश कोड जोड़े की एक स्थान-पृथक सूची जो उपयोगकर्ता के लिए कई सेटिंग्स का वर्णन करती है, जैसे यूआई भाषा और समय, दिनांक और मुद्रा स्वरूपण। PRODUCT_LOCALES में सूचीबद्ध पहला लोकेल उत्पाद के डिफ़ॉल्ट लोकेल के रूप में उपयोग किया जाता है। | en_GB , de_DE , es_ES , fr_CA |
PRODUCT_MANUFACTURER | निर्माता का नाम. | acme |
PRODUCT_MODEL | अंतिम उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम। | |
PRODUCT_NAME | समग्र उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम। सेटिंग्स > अबाउट स्क्रीन में दिखाई देता है। | |
PRODUCT_OTA_PUBLIC_KEYS | उत्पाद के लिए ओवर-द-एयर (OTA) सार्वजनिक कुंजियों की सूची। | |
PRODUCT_PACKAGES | इंस्टॉल करने के लिए एपीके और मॉड्यूल की सूची। | कैलेंडर संपर्क |
PRODUCT_PACKAGE_OVERLAYS | इंगित करता है कि डिफ़ॉल्ट संसाधनों का उपयोग करना है या कोई उत्पाद विशिष्ट ओवरले जोड़ना है। | vendor/acme/overlay |
PRODUCT_SYSTEM_PROPERTIES | सिस्टम विभाजन के लिए "key=value" प्रारूप में सिस्टम प्रॉपर्टी असाइनमेंट की सूची। अन्य विभाजनों के लिए सिस्टम गुण PRODUCT_<PARTITION>_PROPERTIES के माध्यम से सेट किए जा सकते हैं, जैसे विक्रेता विभाजन के लिए PRODUCT_VENDOR_PROPERTIES में हैं। समर्थित विभाजन नाम: SYSTEM , VENDOR , ODM , SYSTEM_EXT , और PRODUCT । |
डिफ़ॉल्ट सिस्टम भाषा और लोकेल फ़िल्टर कॉन्फ़िगर करें
डिफ़ॉल्ट भाषा और सिस्टम लोकेल फ़िल्टर को कॉन्फ़िगर करने के लिए इस जानकारी का उपयोग करें, फिर नए डिवाइस प्रकार के लिए लोकेल फ़िल्टर को सक्षम करें।
गुण
समर्पित सिस्टम गुणों का उपयोग करके डिफ़ॉल्ट भाषा और सिस्टम लोकेल फ़िल्टर दोनों को कॉन्फ़िगर करें:
-
ro.product.locale
: डिफ़ॉल्ट लोकेल सेट करने के लिए। इसे प्रारंभ मेंPRODUCT_LOCALES
वेरिएबल में पहले लोकेल पर सेट किया गया है; आप उस मान को ओवरराइड कर सकते हैं. (अधिक जानकारी के लिए, उत्पाद परिभाषा चर सेट करना तालिका देखें।) -
ro.localization.locale_filter
: स्थानीय नामों पर लागू नियमित अभिव्यक्ति का उपयोग करके, स्थानीय फ़िल्टर सेट करने के लिए। उदाहरण के लिए:- समावेशी फ़िल्टर:
^(de-AT|de-DE|en|uk).*
- केवल जर्मन (ऑस्ट्रिया और जर्मनी वेरिएंट), अंग्रेजी के सभी अंग्रेजी वेरिएंट और यूक्रेनी की अनुमति देता है - विशिष्ट फ़िल्टर:
^(?!de-IT|es).*
- इसमें जर्मन (इटली संस्करण), और स्पैनिश के सभी संस्करण शामिल नहीं हैं।
- समावेशी फ़िल्टर:
स्थानीय फ़िल्टर सक्षम करें
फ़िल्टर को सक्षम करने के लिए, ro.localization.locale_filter
सिस्टम प्रॉपर्टी स्ट्रिंग मान सेट करें।
फ़ैक्टरी अंशांकन के दौरान oem/oem.prop
के माध्यम से फ़िल्टर प्रॉपर्टी मान और डिफ़ॉल्ट भाषा सेट करके आप सिस्टम छवि में फ़िल्टर को बेक किए बिना प्रतिबंधों को कॉन्फ़िगर कर सकते हैं। आप यह सुनिश्चित करते हैं कि इन गुणों को PRODUCT_OEM_PROPERTIES
वेरिएबल में जोड़कर OEM विभाजन से उठाया गया है जैसा कि नीचे बताया गया है:
# Delegation for OEM customization PRODUCT_OEM_PROPERTIES += \ ro.product.locale \ ro.localization.locale_filter
फिर उत्पादन में लक्ष्य आवश्यकताओं को प्रतिबिंबित करने के लिए वास्तविक मान oem/oem.prop
पर लिखे जाते हैं। इस दृष्टिकोण के साथ, फ़ैक्टरी रीसेट के दौरान डिफ़ॉल्ट मान बरकरार रहते हैं, इसलिए प्रारंभिक सेटिंग्स उपयोगकर्ता को बिल्कुल पहले सेटअप की तरह दिखती हैं।
USB पर कनेक्ट करने के लिए ADB_VENDOR_KEYS सेट करें
ADB_VENDOR_KEYS
पर्यावरण चर डिवाइस निर्माताओं को मैन्युअल प्राधिकरण के बिना एडीबी पर डिबग करने योग्य बिल्ड (-userdebug और -eng, लेकिन -user नहीं) तक पहुंचने में सक्षम बनाता है। आम तौर पर एडीबी प्रत्येक क्लाइंट कंप्यूटर के लिए एक अद्वितीय आरएसए प्रमाणीकरण कुंजी उत्पन्न करता है, जिसे वह किसी भी कनेक्टेड डिवाइस पर भेजेगा। यह एडीबी प्राधिकरण संवाद में दिखाई गई आरएसए कुंजी है। एक विकल्प के रूप में आप सिस्टम छवि में ज्ञात कुंजी बना सकते हैं और उन्हें एडीबी क्लाइंट के साथ साझा कर सकते हैं। यह ओएस विकास और विशेष रूप से परीक्षण के लिए उपयोगी है क्योंकि यह एडीबी प्राधिकरण संवाद के साथ मैन्युअल रूप से बातचीत करने की आवश्यकता से बचाता है।
विक्रेता कुंजियाँ बनाने के लिए, एक व्यक्ति (आमतौर पर एक रिलीज़ प्रबंधक) को यह करना चाहिए:
-
adb keygen
उपयोग करके एक कुंजी युग्म उत्पन्न करें। Google उपकरणों के लिए, Google प्रत्येक नए OS संस्करण के लिए एक नई कुंजी जोड़ी बनाता है। - स्रोत वृक्ष में कहीं कुंजी युग्मों की जाँच करें। उदाहरण के लिए, Google उन्हें
vendor/google/security/adb/
में संग्रहीत करता है। - अपनी कुंजी निर्देशिका को इंगित करने के लिए बिल्ड वेरिएबल
PRODUCT_ADB_KEYS
सेट करें। Google कुंजी निर्देशिका में एकAndroid.mk
फ़ाइल जोड़कर ऐसा करता है जो कहती हैPRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub
, जो यह सुनिश्चित करने में मदद करती है कि हम प्रत्येक OS संस्करण के लिए एक नई कुंजी जोड़ी बनाना याद रखें।
यहां वह मेकफ़ाइल है जिसका उपयोग Google उस निर्देशिका में करता है जहां हम प्रत्येक रिलीज़ के लिए हमारे चेक-इन कुंजी जोड़े संग्रहीत करते हैं:
PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),) $(warning ========================) $(warning The adb key for this release) $(warning ) $(warning $(PRODUCT_ADB_KEYS)) $(warning ) $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk) $(warning has changed and a new adb key needs to be generated.) $(warning ) $(warning Please run the following commands to create a new key:) $(warning ) $(warning make -j8 adb) $(warning LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS))) $(warning ) $(warning and upload/review/submit the changes) $(warning ========================) $(error done) endif
इन विक्रेता कुंजियों का उपयोग करने के लिए, एक इंजीनियर को केवल उस निर्देशिका को इंगित करने के लिए ADB_VENDOR_KEYS
पर्यावरण चर सेट करने की आवश्यकता होती है जिसमें कुंजी जोड़े संग्रहीत होते हैं। यह adb
जनरेट की गई होस्ट कुंजी पर वापस जाने से पहले इन कैनोनिकल कुंजियों को आज़माने के लिए कहता है जिसके लिए मैन्युअल प्राधिकरण की आवश्यकता होती है। जब adb
किसी अनधिकृत डिवाइस से कनेक्ट नहीं हो पाता है, तो त्रुटि संदेश सुझाव देगा कि आप ADB_VENDOR_KEYS
सेट करें, यदि यह पहले से सेट नहीं है।