একটি নতুন ডিভাইস যোগ করুন

আপনার ডিভাইস ও পণ্যের জন্য মেকফাইল তৈরি করতে এই পৃষ্ঠার তথ্য ব্যবহার করুন।

প্রতিটি নতুন অ্যান্ড্রয়েড মডিউলের একটি কনফিগারেশন ফাইল থাকা আবশ্যক, যা মডিউল মেটাডেটা, কম্পাইল-টাইম নির্ভরতা এবং প্যাকেজিং নির্দেশাবলী দিয়ে বিল্ড সিস্টেমকে পরিচালনা করে। অ্যান্ড্রয়েড সুং (Soong) বিল্ড সিস্টেম ব্যবহার করে। অ্যান্ড্রয়েড বিল্ড সিস্টেম সম্পর্কে আরও তথ্যের জন্য ‘বিল্ডিং অ্যান্ড্রয়েড’ দেখুন।

বিল্ড লেয়ারগুলো বুঝুন

বিল্ড হায়ারার্কিতে অ্যাবস্ট্রাকশন লেয়ারগুলো অন্তর্ভুক্ত থাকে, যা একটি ডিভাইসের ভৌত গঠনের সাথে সঙ্গতিপূর্ণ। এই লেয়ারগুলো নিচের টেবিলে বর্ণনা করা হয়েছে। প্রতিটি লেয়ার তার উপরের লেয়ারের সাথে এক-থেকে-অনেক (one-to-many) সম্পর্কে সম্পর্কিত। উদাহরণস্বরূপ, একটি আর্কিটেকচারে একাধিক বোর্ড থাকতে পারে এবং প্রতিটি বোর্ডে একাধিক প্রোডাক্ট থাকতে পারে। আপনি একটি নির্দিষ্ট লেয়ারের কোনো এলিমেন্টকে সেই একই লেয়ারের অন্য কোনো এলিমেন্টের স্পেশালাইজেশন হিসেবে সংজ্ঞায়িত করতে পারেন, যা কপি করার প্রয়োজনীয়তা দূর করে এবং রক্ষণাবেক্ষণকে সহজ করে তোলে।

স্তর উদাহরণ বর্ণনা
পণ্য myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk প্রোডাক্ট লেয়ার একটি শিপিং প্রোডাক্টের ফিচার স্পেসিফিকেশন নির্ধারণ করে, যেমন কোন মডিউলগুলো তৈরি করতে হবে, কোন লোকেলগুলো সাপোর্ট করবে এবং বিভিন্ন লোকেলের জন্য কনফিগারেশন। অন্য কথায়, এটিই হলো সামগ্রিক প্রোডাক্টটির নাম । প্রোডাক্ট-নির্দিষ্ট ভ্যারিয়েবলগুলো প্রোডাক্ট ডেফিনিশন মেকফাইলে সংজ্ঞায়িত করা হয়। একটি প্রোডাক্ট অন্য প্রোডাক্ট ডেফিনিশন থেকে ইনহেরিট করতে পারে, যা রক্ষণাবেক্ষণকে সহজ করে তোলে। একটি সাধারণ পদ্ধতি হলো এমন একটি বেস প্রোডাক্ট তৈরি করা যাতে এমন ফিচার থাকে যা সব প্রোডাক্টের জন্য প্রযোজ্য, এবং তারপর সেই বেস প্রোডাক্টের উপর ভিত্তি করে প্রোডাক্ট ভ্যারিয়েন্ট তৈরি করা। উদাহরণস্বরূপ, দুটি প্রোডাক্ট যাদের মধ্যে পার্থক্য শুধু তাদের রেডিওর (সিডিএমএ বনাম জিএসএম) কারণে, তারা একই বেস প্রোডাক্ট থেকে ইনহেরিট করতে পারে, যেটিতে কোনো রেডিও সংজ্ঞায়িত করা নেই।
বোর্ড/ডিভাইস মার্লিন, ব্লুলাইন, কোরাল বোর্ড/ডিভাইস লেয়ারটি ডিভাইসের ওপর থাকা প্লাস্টিকের ভৌত স্তরকে (অর্থাৎ, ডিভাইসটির শিল্প নকশা) বোঝায়। এই লেয়ারটি একটি পণ্যের প্রাথমিক নকশাকেও উপস্থাপন করে। এর মধ্যে বোর্ডের পেরিফেরালগুলো এবং সেগুলোর কনফিগারেশন অন্তর্ভুক্ত থাকে। ব্যবহৃত নামগুলো বিভিন্ন বোর্ড/ডিভাইস কনফিগারেশনের জন্য ব্যবহৃত কোড মাত্র।
খিলান arm, x86, arm64, x86_64 আর্কিটেকচার লেয়ারটি বোর্ডে চলমান প্রসেসর কনফিগারেশন এবং অ্যাপ্লিকেশন বাইনারি ইন্টারফেস (ABI) বর্ণনা করে।

বিল্ড ভ্যারিয়েন্ট ব্যবহার করুন

কোনো নির্দিষ্ট পণ্যের জন্য বিল্ড করার সময়, চূড়ান্ত রিলিজ বিল্ডে সামান্য কিছু ভিন্নতা থাকা সুবিধাজনক। একটি মডিউল সংজ্ঞায়, মডিউলটি LOCAL_MODULE_TAGS ব্যবহার করে ট্যাগ নির্দিষ্ট করতে পারে, যার মান optional (ডিফল্ট), debug , এবং eng এর মধ্যে এক বা একাধিক হতে পারে।

যদি কোনো মডিউল LOCAL_MODULE_TAGS দ্বারা কোনো ট্যাগ নির্দিষ্ট না করে, তাহলে তার ট্যাগ ডিফল্টভাবে optional হয়। একটি ঐচ্ছিক মডিউল কেবল তখনই ইনস্টল করা হয়, যখন PRODUCT_PACKAGES সহ প্রোডাক্ট কনফিগারেশনের জন্য এটির প্রয়োজন হয়।

এগুলো হলো বর্তমানে সংজ্ঞায়িত বিল্ড ভ্যারিয়েন্টগুলো।

ভেরিয়েন্ট বর্ণনা
eng এটিই ডিফল্ট ফ্লেভার।
  • eng বা debug ট্যাগযুক্ত মডিউলগুলো ইনস্টল করে।
  • প্রোডাক্ট ডেফিনিশন ফাইল অনুযায়ী মডিউল ইনস্টল করার পাশাপাশি ট্যাগ করা মডিউলগুলোও ইনস্টল করে।
  • ro.secure=0
  • ro.debuggable=1
  • ro.kernel.android.checkjni=1
  • adb ডিফল্টরূপে সক্রিয় থাকে।
user এই সংস্করণটিই চূড়ান্ত সংস্করণ হিসেবে প্রকাশের জন্য উদ্দিষ্ট।
  • user দ্বারা ট্যাগ করা মডিউলগুলি ইনস্টল করে।
  • প্রোডাক্ট ডেফিনিশন ফাইল অনুযায়ী মডিউল ইনস্টল করার পাশাপাশি ট্যাগ করা মডিউলগুলোও ইনস্টল করে।
  • ro.secure=1
  • ro.debuggable=0
  • ডিফল্টরূপে adb নিষ্ক্রিয় থাকে।
userdebug user মতোই, তবে এই ব্যতিক্রমগুলো রয়েছে:
  • এছাড়াও debug ট্যাগযুক্ত মডিউলগুলো ইনস্টল করে।
  • ro.debuggable=1
  • adb ডিফল্টরূপে সক্রিয় থাকে।

ইউজারডিবাগ এর জন্য নির্দেশিকা

টেস্টিংয়ের সময় ইউজারডিবাগ বিল্ড চালালে ডিভাইস ডেভেলপাররা নির্মাণাধীন রিলিজগুলোর পারফরম্যান্স ও ক্ষমতা বুঝতে পারেন। ইউজার ও ইউজারডিবাগ বিল্ডের মধ্যে সামঞ্জস্য বজায় রাখতে এবং ডিবাগিংয়ের জন্য ব্যবহৃত বিল্ডগুলোতে নির্ভরযোগ্য মেট্রিক্স পেতে, ডিভাইস ডেভেলপারদের নিম্নলিখিত নির্দেশিকাগুলো অনুসরণ করা উচিত:

  • userdebug-কে রুট অ্যাক্সেস সক্ষম করা একটি ইউজার বিল্ড হিসাবে সংজ্ঞায়িত করা হয়, ব্যতিক্রম হলো:
    • ইউজারডিবাগ-অনলি অ্যাপ, যা শুধুমাত্র ব্যবহারকারীর চাহিদামতো চালানো হয়।
    • যেসব অপারেশন শুধুমাত্র নিষ্ক্রিয় রক্ষণাবেক্ষণের সময় (চার্জে থাকা অবস্থায়/সম্পূর্ণ চার্জ থাকা অবস্থায়) চলে, যেমন ব্যাকগ্রাউন্ড কম্পাইলের জন্য 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 ডিরেক্টরিটি দেখতে পারেন।

পণ্যের মেকফাইল লিখুন

নিম্নলিখিত ধাপগুলিতে পিক্সেল প্রোডাক্ট লাইনের অনুরূপভাবে প্রোডাক্ট মেকফাইল সেট আপ করার পদ্ধতি বর্ণনা করা হয়েছে:

  1. আপনার পণ্যের জন্য একটি device/ <company-name> / <device-name> ডিরেক্টরি তৈরি করুন। উদাহরণস্বরূপ, device/google/marlin । এই ডিরেক্টরিতে আপনার ডিভাইসের সোর্স কোড এবং সেগুলোকে বিল্ড করার জন্য মেকফাইলগুলো থাকবে।
  2. একটি device.mk মেকফাইল তৈরি করুন, যেখানে ডিভাইসটির জন্য প্রয়োজনীয় ফাইল ও মডিউলগুলো উল্লেখ থাকবে। উদাহরণের জন্য device/google/marlin/device-marlin.mk দেখুন।
  3. ডিভাইসের উপর ভিত্তি করে একটি নির্দিষ্ট পণ্য তৈরি করার জন্য একটি প্রোডাক্ট ডেফিনিশন মেকফাইল তৈরি করুন। নিচের মেকফাইলটি উদাহরণ হিসেবে 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
    

    আপনার মেকফাইলগুলিতে যোগ করতে পারেন এমন অতিরিক্ত পণ্য-নির্দিষ্ট ভেরিয়েবলগুলির জন্য, "পণ্য সংজ্ঞা ভেরিয়েবল সেট করা" দেখুন।

  4. একটি AndroidProducts.mk ফাইল তৈরি করুন যা প্রোডাক্টের মেকফাইলগুলোকে নির্দেশ করবে। এই উদাহরণে, শুধুমাত্র প্রোডাক্ট ডেফিনিশন মেকফাইলটি প্রয়োজন। নিচের উদাহরণটি device/google/marlin/AndroidProducts.mk থেকে নেওয়া হয়েছে (যেটিতে মার্লিন (পিক্সেল) এবং সেইলফিশ (পিক্সেল এক্সএল) উভয়ই রয়েছে, যাদের বেশিরভাগ কনফিগারেশন একই ছিল):
    PRODUCT_MAKEFILES := \
    	$(LOCAL_DIR)/aosp_marlin.mk \
    	$(LOCAL_DIR)/aosp_sailfish.mk
    
    COMMON_LUNCH_CHOICES := \
    	aosp_marlin-userdebug \
    	aosp_sailfish-userdebug
    
  5. একটি BoardConfig.mk মেকফাইল তৈরি করুন যাতে বোর্ড-নির্দিষ্ট কনফিগারেশন থাকবে। উদাহরণের জন্য, device/google/marlin/BoardConfig.mk দেখুন।
  6. শুধুমাত্র অ্যান্ড্রয়েড ৯ এবং এর নিচের সংস্করণগুলোর জন্য , একটি vendorsetup.sh ফাইল তৈরি করুন এবং আপনার প্রোডাক্ট (একটি 'লাঞ্চ কম্বো') ও ড্যাশ দিয়ে আলাদা করা বিল্ড ভ্যারিয়েন্টটি বিল্ডে যোগ করুন। উদাহরণস্বরূপ:
    add_lunch_combo <product-name>-userdebug
    
  7. এই পর্যায়ে, আপনি একই ডিভাইসের উপর ভিত্তি করে পণ্যের আরও ভ্যারিয়েন্ট তৈরি করতে পারবেন।

পণ্যের সংজ্ঞা ভেরিয়েবল সেট করুন

পণ্য-নির্দিষ্ট ভেরিয়েবলগুলো পণ্যের মেকফাইলে সংজ্ঞায়িত করা হয়। সারণিটিতে একটি পণ্য সংজ্ঞা ফাইলে সংরক্ষিত কিছু ভেরিয়েবল দেখানো হয়েছে।

পরিবর্তনশীল বর্ণনা উদাহরণ
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 দুই-অক্ষরের ভাষা কোড এবং দুই-অক্ষরের দেশের কোডের জোড়া দিয়ে তৈরি একটি তালিকা, যা ব্যবহারকারীর জন্য বিভিন্ন সেটিংস বর্ণনা করে, যেমন UI ভাষা এবং সময়, তারিখ ও মুদ্রার ফরম্যাটিং। 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 এনভায়রনমেন্ট ভেরিয়েবলটি ডিভাইস প্রস্তুতকারকদের ম্যানুয়াল অনুমোদন ছাড়াই adb-এর মাধ্যমে ডিবাগযোগ্য বিল্ড (-userdebug এবং -eng, কিন্তু -user নয়) অ্যাক্সেস করতে সক্ষম করে। সাধারণত adb প্রতিটি ক্লায়েন্ট কম্পিউটারের জন্য একটি অনন্য RSA অথেন্টিকেশন কী তৈরি করে, যা এটি যেকোনো সংযুক্ত ডিভাইসে পাঠাবে। এই RSA কী-টিই adb অথরাইজেশন ডায়ালগে দেখানো হয়। বিকল্প হিসেবে, আপনি সিস্টেম ইমেজে পরিচিত কী-গুলো বিল্ড করে adb ক্লায়েন্টের সাথে শেয়ার করতে পারেন। এটি OS ডেভেলপমেন্ট এবং বিশেষ করে টেস্টিংয়ের জন্য উপযোগী, কারণ এর ফলে adb অথরাইজেশন ডায়ালগের সাথে ম্যানুয়ালি ইন্টারঅ্যাক্ট করার প্রয়োজন হয় না।

ভেন্ডর কী তৈরি করার জন্য, একজন ব্যক্তিকে (সাধারণত একজন রিলিজ ম্যানেজার) নিম্নলিখিত কাজগুলো করতে হবে:

  1. adb keygen ব্যবহার করে একটি কী পেয়ার তৈরি করুন। গুগল ডিভাইসগুলোর জন্য, গুগল প্রতিটি নতুন ওএস সংস্করণের জন্য একটি নতুন কী পেয়ার তৈরি করে।
  2. সোর্স ট্রির কোথাও কী পেয়ারগুলো যাচাই করে দেখুন। উদাহরণস্বরূপ, গুগল এগুলো vendor/google/security/adb/ -এ সংরক্ষণ করে।
  3. আপনার কী ডিরেক্টরি নির্দেশ করার জন্য PRODUCT_ADB_KEYS বিল্ড ভেরিয়েবলটি সেট করুন। গুগল এটি করার জন্য কী ডিরেক্টরিতে একটি Android.mk ফাইল যোগ করে, যেখানে লেখা থাকে PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub । এটি নিশ্চিত করতে সাহায্য করে যে আমরা যেন প্রতিটি OS সংস্করণের জন্য একটি নতুন কী পেয়ার তৈরি করার কথা মনে রাখি।

প্রতিটি রিলিজের জন্য আমাদের চেক-ইন করা কী পেয়ারগুলো যে ডিরেক্টরিতে সংরক্ষণ করা হয়, সেখানে গুগল এই মেকফাইলটি ব্যবহার করে:

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 আগে থেকে সেট করা না থাকে, তবে তা সেট করুন।