এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

সিস্টেম বৈশিষ্ট্য যোগ করুন

এই পৃষ্ঠাটি বিদ্যমান সিস্টেম বৈশিষ্ট্যগুলিকে রিফ্যাক্টর করার জন্য নির্দেশিকা সহ Android-এ সিস্টেম বৈশিষ্ট্যগুলি যোগ বা সংজ্ঞায়িত করার জন্য একটি আদর্শ পদ্ধতি প্রদান করে৷ নিশ্চিত করুন যে আপনি রিফ্যাক্টর করার সময় নির্দেশিকা ব্যবহার করেন, যদি না আপনার কাছে একটি শক্তিশালী সামঞ্জস্যের সমস্যা থাকে যা অন্যথায় নির্দেশ করে।

ধাপ 1: সিস্টেম সম্পত্তি সংজ্ঞায়িত করা

যখন আপনি একটি সিস্টেম সম্পত্তি যোগ করেন, সম্পত্তির জন্য একটি নাম স্থির করুন এবং এটিকে একটি SELinux সম্পত্তি প্রসঙ্গে যুক্ত করুন। যদি কোনও উপযুক্ত বিদ্যমান প্রসঙ্গ না থাকে তবে একটি নতুন তৈরি করুন৷ সম্পত্তি অ্যাক্সেস করার সময় নাম ব্যবহার করা হয়; SELinux-এর পরিপ্রেক্ষিতে অ্যাক্সেসিবিলিটি নিয়ন্ত্রণ করতে সম্পত্তি প্রসঙ্গ ব্যবহার করা হয়। নামগুলি যে কোনও স্ট্রিং হতে পারে, তবে AOSP সুপারিশ করে যে আপনি তাদের পরিষ্কার করার জন্য একটি কাঠামোগত বিন্যাস অনুসরণ করুন৷

সম্পত্তির নাম

snake_case casing সহ এই বিন্যাসটি ব্যবহার করুন:

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

উপাদানের prefix জন্য হয় “” (বাদ দেওয়া), ro (প্রপার্টিগুলির জন্য শুধুমাত্র একবার সেট করার জন্য), অথবা persist (রিবুট জুড়ে থাকা বৈশিষ্ট্যগুলির জন্য) ব্যবহার করুন।

সতর্কতা

ro ব্যবহার করুন শুধুমাত্র যখন আপনি নিশ্চিত হন যে ভবিষ্যতে লেখার জন্য আপনার prefix প্রয়োজন নেই। ** ro উপসর্গটি নির্দিষ্ট করবেন না। ** পরিবর্তে, prefix শুধুমাত্র পঠনযোগ্য করার জন্য সেপলিসির উপর নির্ভর করুন (অন্য কথায়, শুধুমাত্র init দ্বারা লেখার যোগ্য)।

persist যখন আপনি নিশ্চিত হন যে মানটি রিবুট জুড়ে বজায় থাকবে এবং সিস্টেম বৈশিষ্ট্যগুলি ব্যবহার করাই আপনার একমাত্র বিকল্প। (বিশদ বিবরণের জন্য প্রস্তুতি বিভাগে পড়ুন।)

Google কঠোরভাবে সিস্টেমের বৈশিষ্ট্যগুলি পর্যালোচনা করে যেগুলির হয় ro বা persist বৈশিষ্ট্য রয়েছে৷

group শব্দটি সমষ্টি সম্পর্কিত বৈশিষ্ট্য ব্যবহার করা হয়। এটি audio বা telephony মতো একটি সাবসিস্টেম নাম হওয়ার উদ্দেশ্যে করা হয়েছে৷ sys , system , dev , default , বা config এর মত অস্পষ্ট বা ওভারলোড করা পদ ব্যবহার করবেন না ৷

সিস্টেমের বৈশিষ্ট্যগুলিতে একচেটিয়া পড়ার বা লেখার অ্যাক্সেস রয়েছে এমন একটি প্রক্রিয়ার ডোমেন প্রকারের নাম ব্যবহার করা সাধারণ অভ্যাস। উদাহরণস্বরূপ, যে সিস্টেমের বৈশিষ্ট্যগুলিতে vold প্রক্রিয়ার লেখার অ্যাক্সেস রয়েছে, সেখানে গোষ্ঠীর নাম হিসাবে vold (প্রক্রিয়াটির জন্য ডোমেনের প্রকারের নাম) ব্যবহার করা সাধারণ।

প্রয়োজনে, বৈশিষ্ট্যগুলিকে আরও শ্রেণীবদ্ধ করতে subgroup যোগ করুন, তবে এই উপাদানটি বর্ণনা করতে অস্পষ্ট বা ওভারলোড করা পদগুলি এড়িয়ে চলুন। (আপনার একাধিক subgroup থাকতে পারে।)

অনেক দলের নাম ইতিমধ্যে সংজ্ঞায়িত করা হয়েছে. system/sepolicy/private/property_contexts ফাইলটি চেক করুন এবং যেখানে সম্ভব সেখানে বিদ্যমান গ্রুপের নাম ব্যবহার করুন, নতুন নাম না করে। নিম্নলিখিত টেবিলটি প্রায়শই ব্যবহৃত গ্রুপ নামের উদাহরণ প্রদান করে।

ডোমেইন	গ্রুপ (এবং উপগোষ্ঠী)
ব্লুটুথ সম্পর্কিত	`bluetooth`
কার্নেল cmdline থেকে sysprops	`boot`
sysprops যে একটি বিল্ড সনাক্ত	`build`
টেলিফোনি সম্পর্কিত	`telephony`
অডিও সম্পর্কিত	`audio`
গ্রাফিক্স সম্পর্কিত	`graphics`
vold সম্পর্কিত	`vold`

নিম্নলিখিত পূর্ববর্তী regex উদাহরণে name এবং type ব্যবহার সংজ্ঞায়িত করে।

[{prefix}.]{group}[.{subgroup}]*.{name}[.{type}]

name একটি গ্রুপের মধ্যে একটি সিস্টেম সম্পত্তি চিহ্নিত করে।
type একটি ঐচ্ছিক উপাদান যা সিস্টেম সম্পত্তির ধরন বা অভিপ্রায়কে স্পষ্ট করে। উদাহরণস্বরূপ, একটি sysprop কে audio.awesome_feature_enabled বা শুধু audio.awesome_feature হিসাবে নামকরণের পরিবর্তে, সিস্টেমের সম্পত্তির ধরন এবং অভিপ্রায় প্রতিফলিত করতে audio.awesome_feature.enabled হিসাবে এটির নাম পরিবর্তন করুন৷

টাইপ কি হতে হবে সে সম্পর্কে কোন নির্দিষ্ট নিয়ম নেই; এইগুলি ব্যবহারের সুপারিশ:

enabled : ব্যবহার করুন যদি টাইপটি একটি বুলিয়ান সিস্টেম বৈশিষ্ট্য হয় যা একটি বৈশিষ্ট্য চালু বা বন্ধ করতে ব্যবহৃত হয়।
config : যদি উদ্দেশ্যটি স্পষ্ট করা হয় যে সিস্টেমের সম্পত্তি সিস্টেমের গতিশীল অবস্থার প্রতিনিধিত্ব করে না তা ব্যবহার করুন; এটি একটি পূর্ব-কনফিগার করা মান প্রতিনিধিত্ব করে (উদাহরণস্বরূপ, একটি পঠনযোগ্য জিনিস)।
List : এটি একটি সিস্টেম সম্পত্তি যার মান একটি তালিকা হলে ব্যবহার করুন।
Timeoutmillis : ms এর ইউনিটে টাইমআউট মানের জন্য এটি একটি সিস্টেম সম্পত্তি হলে ব্যবহার করুন।

উদাহরণ:

persist.radio.multisim.config
drm.service.enabled

সম্পত্তি প্রসঙ্গ

নতুন SELinux সম্পত্তি প্রসঙ্গ স্কিম সূক্ষ্ম কণিকা এবং আরও বর্ণনামূলক নামের জন্য অনুমতি দেয়। সম্পত্তির নামের জন্য যা ব্যবহার করা হয় তার অনুরূপ, AOSP নিম্নলিখিত বিন্যাসের সুপারিশ করে:

{group}[_{subgroup}]*_prop

শর্তাবলী নিম্নরূপ সংজ্ঞায়িত করা হয়:

group এবং subgroup একই অর্থ রয়েছে যা পূর্ববর্তী নমুনা রেজেক্সের জন্য সংজ্ঞায়িত করা হয়েছিল। উদাহরণস্বরূপ, vold_config_prop বৈশিষ্ট্যগুলিকে বোঝায় যা একটি বিক্রেতার কনফিগারেশন এবং vendor_init দ্বারা সেট করা হয়, যখন vold_status_prop বা শুধু vold_prop বৈশিষ্ট্যগুলিকে বোঝায় যা vold এর বর্তমান অবস্থা প্রকাশ করে।

একটি সম্পত্তি প্রসঙ্গে নামকরণ করার সময়, বৈশিষ্ট্যগুলির সাধারণ ব্যবহার প্রতিফলিত করে এমন নামগুলি চয়ন করুন৷ বিশেষ করে, নিম্নলিখিত ধরনের পদগুলি এড়িয়ে চলুন:

যে পদগুলি খুব সাধারণ এবং অস্পষ্ট দেখায়, যেমন sys , system , default ৷
শর্তাবলী যা সরাসরি অ্যাক্সেসযোগ্যতা এনকোড করে: যেমন exported , apponly , ro , public , private ৷

নাম ব্যবহার পছন্দ করুন যেমন vold_config_prop to exported_vold_prop , অথবা vold_vendor_writable_prop , ইত্যাদি।

টাইপ

সারণীতে তালিকাভুক্ত একটি সম্পত্তির ধরন নিম্নলিখিতগুলির মধ্যে একটি হতে পারে।

টাইপ	সংজ্ঞা
বুলিয়ান	`true` বা সত্যের জন্য `1` , `false` বা মিথ্যার জন্য `0`
পূর্ণসংখ্যা	স্বাক্ষরিত 64-বিট পূর্ণসংখ্যা
স্বাক্ষরবিহীন পূর্ণসংখ্যা	স্বাক্ষরবিহীন 64-বিট পূর্ণসংখ্যা
ডাবল	ডবল নির্ভুল ভাসমান পয়েন্ট
স্ট্রিং	যেকোনো বৈধ UTF-8 স্ট্রিং
enum	মান হোয়াইটস্পেস ছাড়া যেকোন বৈধ UTF-8 স্ট্রিং হতে পারে
উপরের তালিকা	একটি কমা ( `,` ) ডিলিমিটার হিসাবে ব্যবহৃত হয় পূর্ণসংখ্যা তালিকা `[1, 2, 3]` `1,2,3` হিসাবে সংরক্ষণ করা হয়

অভ্যন্তরীণভাবে, সমস্ত বৈশিষ্ট্য স্ট্রিং হিসাবে সংরক্ষণ করা হয়। আপনি এটিকে একটি property_contexts ফাইল হিসাবে নির্দিষ্ট করে টাইপ প্রয়োগ করতে পারেন। আরও তথ্যের জন্য, ধাপ 3 -এ property_contexts দেখুন।

ধাপ 2: প্রয়োজনীয় অ্যাক্সেসিবিলিটি স্তর নির্ধারণ করা

চারটি সাহায্যকারী ম্যাক্রো আছে যা একটি সম্পত্তি সংজ্ঞায়িত করে।

অ্যাক্সেসিবিলিটি প্রকার	অর্থ
`system_internal_prop`	বৈশিষ্ট্য যা শুধুমাত্র `/system` ব্যবহৃত হয়
`system_restricted_prop`	বৈশিষ্ট্য যা `/system` বাইরে পড়া হয়, কিন্তু লেখা হয় না
`system_vendor_config_prop`	প্রপার্টি যা `/system` এর বাইরে পড়া হয় এবং শুধুমাত্র `vendor_init` দ্বারা লেখা হয়
`system_public_prop`	বৈশিষ্ট্য যা পড়া এবং লেখা হয় `/system` বাইরে

যতটা সম্ভব সংকীর্ণভাবে সিস্টেম বৈশিষ্ট্য অ্যাক্সেস সুযোগ. অতীতে, বিস্তৃত অ্যাক্সেসের ফলে অ্যাপ ভাঙ্গা এবং নিরাপত্তা দুর্বলতা দেখা দিয়েছে। স্কোপ করার সময় নিম্নলিখিত প্রশ্নগুলি বিবেচনা করুন:

এই সিস্টেম সম্পত্তি অবিরত করা প্রয়োজন? (যদি তাই হয়, কেন?)
কোন প্রক্রিয়া এই সম্পত্তি পড়ার অ্যাক্সেস থাকা উচিত?
কোন প্রক্রিয়া এই সম্পত্তি লিখতে অ্যাক্সেস থাকা উচিত?

অ্যাক্সেসের জন্য উপযুক্ত সুযোগ নির্ধারণের জন্য পূর্ববর্তী প্রশ্ন এবং নিম্নলিখিত সিদ্ধান্ত ট্রি ব্যবহার করুন।

Decision tree for determining the scope of access

চিত্র 1. সিস্টেম বৈশিষ্ট্য অ্যাক্সেস সুযোগ নির্ধারণের জন্য সিদ্ধান্ত গাছ

ধাপ 3: এটিকে সিস্টেম/সিপলিসিতে যুক্ত করা

sysprop অ্যাক্সেস করার সময়, SELinux প্রক্রিয়াগুলির অ্যাক্সেসযোগ্যতা নিয়ন্ত্রণ করে। আপনি কোন স্তরের অ্যাক্সেসিবিলিটি প্রয়োজন তা নির্ধারণ করার পরে, system/sepolicy এর অধীনে সম্পত্তির প্রসঙ্গ সংজ্ঞায়িত করুন, সাথে অতিরিক্ত অনুমতি দিন এবং কোন প্রক্রিয়াগুলি পড়তে বা লেখার অনুমতি দেওয়া হয় (এবং এটি নেই) সে সম্পর্কে নিয়মাবলীর সাথে।

প্রথমে, system/sepolicy/public/property.te ফাইলে সম্পত্তি প্রসঙ্গ সংজ্ঞায়িত করুন। প্রপার্টি সিস্টেম-অভ্যন্তরীণ হলে, system/sepolicy/private/property.te ফাইলে এটি সংজ্ঞায়িত করুন। system_[accessibility]_prop([context]) ম্যাক্রোগুলির একটি ব্যবহার করুন যা আপনার সিস্টেম সম্পত্তির প্রয়োজনীয় অ্যাক্সেসিবিলিটি প্রদান করে। এটি system/sepolicy/public/property.te ফাইলের একটি উদাহরণ:

system_public_prop(audio_foo_prop)
system_vendor_config_prop(audio_bar_prop)

system/sepolicy/private/property.te ফাইলে যোগ করার উদাহরণ:

system_internal_prop(audio_baz_prop)

দ্বিতীয়ত, সম্পত্তি প্রসঙ্গে পড়তে এবং (বা) লেখার অনুমতি দিন। system/sepolicy/public/{domain}.te বা system/sepolicy/private/{domain}.te ফাইলে অ্যাক্সেস দেওয়ার জন্য set_prop এবং get_prop ম্যাক্রো ব্যবহার করুন। যখনই সম্ভব private ব্যবহার করুন; যদি set_prop বা get_prop ম্যাক্রো মূল ডোমেনের বাইরের কোনো ডোমেনকে প্রভাবিত করে তবেই public উপযুক্ত।

উদাহরণ, system/sepolicy/private/audio.te ফাইলে:

set_prop(audio, audio_foo_prop)
set_prop(audio, audio_bar_prop)

উদাহরণ, system/sepolicy/public/domain.te ফাইলে:

get_prop(domain, audio_bar_prop)

তৃতীয়ত, ম্যাক্রো দ্বারা স্কোপ করা অ্যাক্সেসযোগ্যতাকে আরও কমাতে কিছু কখনও অনুমতি না দেওয়ার নিয়ম যোগ করুন। উদাহরণস্বরূপ, অনুমান করুন যে আপনি system_restricted_prop ব্যবহার করেছেন কারণ আপনার সিস্টেমের বৈশিষ্ট্য অবশ্যই বিক্রেতা প্রক্রিয়া দ্বারা পড়তে হবে। যদি সমস্ত বিক্রেতা প্রক্রিয়াগুলির দ্বারা পঠন অ্যাক্সেসের প্রয়োজন না হয়, এবং এটি শুধুমাত্র একটি নির্দিষ্ট সেট প্রক্রিয়ার (যেমন vendor_init ) দ্বারা প্রয়োজন হয়, তাহলে সেই বিক্রেতা প্রক্রিয়াগুলিকে নিষিদ্ধ করুন যেগুলির পড়ার অ্যাক্সেসের প্রয়োজন নেই৷

লেখা এবং পড়ার অ্যাক্সেস সীমাবদ্ধ করার জন্য নিম্নলিখিত সিনট্যাক্স ব্যবহার করুন:

লেখার অ্যাক্সেস সীমাবদ্ধ করতে:

neverallow [domain] [context]:property_service set;

পড়ার অ্যাক্সেস সীমাবদ্ধ করতে:

neverallow [domain] [context]:file no_rw_file_perms;

system/sepolicy/private/{domain}.te ফাইলে neverallow নিয়মগুলি রাখুন যদি neverallow নিয়মটি একটি নির্দিষ্ট ডোমেনে আবদ্ধ থাকে। বৃহত্তর কখনই অনুমতি না দেওয়া নিয়মগুলির জন্য, যেখানে উপযুক্ত সেখানে সাধারণ ডোমেনগুলি ব্যবহার করুন:

system/sepolicy/private/property.te
system/sepolicy/private/coredomain.te
system/sepolicy/private/domain.te

system/sepolicy/private/audio.te ফাইলে, নিম্নলিখিতগুলি রাখুন:

neverallow {
    domain -init -audio
} {audio_foo_prop audio_bar_prop}:property_service set;

system/sepolicy/private/property.te ফাইলে, নিম্নলিখিতগুলি রাখুন:

neverallow {
    domain -coredomain -vendor_init
} audio_prop:file no_rw_file_perms;

মনে রাখবেন যে {domain -coredomain} সমস্ত বিক্রেতা প্রক্রিয়া ক্যাপচার করে। সুতরাং {domain -coredomain -vendor_init} মানে " vendor_init ছাড়া সমস্ত বিক্রেতা প্রক্রিয়া।"

অবশেষে, সম্পত্তি প্রসঙ্গের সাথে একটি সিস্টেম সম্পত্তি সংযুক্ত করুন। এটি নিশ্চিত করে যে যে অ্যাক্সেস মঞ্জুর করা হয়েছে এবং প্রপার্টি প্রসঙ্গে প্রয়োগ করা হয় না এমন নিয়মগুলি প্রকৃত বৈশিষ্ট্যগুলিতে প্রয়োগ করা হয়। এটি করার জন্য, property_contexts ফাইলে একটি এন্ট্রি যোগ করুন, একটি ফাইল যা সিস্টেমের বৈশিষ্ট্য এবং সম্পত্তি প্রসঙ্গগুলির মধ্যে ম্যাপিং বর্ণনা করে। এই ফাইলটিতে, আপনি হয় একটি একক প্রপার্টি বা প্রেফিক্সের জন্য একটি প্রেফিক্স উল্লেখ করতে পারেন যা একটি প্রসঙ্গে ম্যাপ করা হবে।

এটি একটি একক সম্পত্তি ম্যাপ করার জন্য সিনট্যাক্স:

[property_name] u:object_r:[context_name]:s0 exact [type]

এটি একটি উপসর্গ ম্যাপ করার জন্য সিনট্যাক্স:

[property_name_prefix] u:object_r:[context_name]:s0 prefix [type]

আপনি ঐচ্ছিকভাবে সম্পত্তির ধরন নির্দিষ্ট করতে পারেন, যা নিম্নলিখিতগুলির মধ্যে একটি হতে পারে:

bool
int
uint
double
enum [list of possible values...]
string (তালিকা বৈশিষ্ট্যের জন্য string ব্যবহার করুন।)

নিশ্চিত করুন যে প্রতিটি এন্ট্রিতে যখনই সম্ভব তার মনোনীত টাইপ আছে, যেমন property সেট করার সময় type প্রয়োগ করা হয়। নিম্নলিখিত উদাহরণ দেখায় কিভাবে একটি ম্যাপিং লিখতে হয়:

# binds a boolean property "ro.audio.status.enabled"
# to the context "audio_foo_prop"
ro.audio.status.enabled u:object_r:audio_foo_prop:s0 exact bool

# binds a boolean property "vold.decrypt.status"
# to the context "vold_foo_prop"
# The property can only be set to one of these: on, off, unknown
vold.decrypt.status u:object_r:vold_foo_prop:s0 exact enum on off unknown

# binds any properties starting with "ro.audio.status."
# to the context "audio_bar_prop", such as
# "ro.audio.status.foo", or "ro.audio.status.bar.baz", and so on.
ro.audio.status. u:object_r:audio_bar_prop:s0 prefix

যখন একটি সঠিক এন্ট্রি এবং একটি প্রিফিক্স এন্ট্রি বিরোধ, সঠিক এন্ট্রি অগ্রাধিকার নেয়। আরও উদাহরণের জন্য, দেখুন system/sepolicy/private/property_contexts ।

ধাপ 4: স্থিতিশীলতার প্রয়োজনীয়তা নির্ধারণ করা

স্থিতিশীলতা সিস্টেম বৈশিষ্ট্যের আরেকটি দিক, এবং এটি অ্যাক্সেসযোগ্যতার থেকে পৃথক। স্থিতিশীলতা হল ভবিষ্যতে সিস্টেমের সম্পত্তি পরিবর্তন করা যাবে কি না (উদাহরণস্বরূপ নাম পরিবর্তন করা, বা এমনকি সরানো)। Android OS মডুলার হয়ে যাওয়ার কারণে এটি বিশেষভাবে গুরুত্বপূর্ণ। ট্রেবলের মাধ্যমে, সিস্টেম, বিক্রেতা এবং পণ্য পার্টিশন একে অপরের থেকে স্বাধীনভাবে আপডেট করা যেতে পারে। মেইনলাইনের সাথে, OS এর কিছু অংশ আপডেটযোগ্য মডিউল হিসাবে মডুলারাইজ করা হয় (APEXes বা APKগুলিতে)।

যদি একটি সিস্টেম সম্পত্তি সফ্টওয়্যারের আপডেটযোগ্য টুকরো জুড়ে ব্যবহারের জন্য হয়, উদাহরণস্বরূপ সিস্টেম এবং ভেন্ডর পার্টিশন জুড়ে, এটি অবশ্যই স্থিতিশীল হতে হবে। যাইহোক, যদি এটি শুধুমাত্র একটি নির্দিষ্ট মেইনলাইন মডিউলের মধ্যে ব্যবহার করা হয়, তাহলে আপনি এর নাম, প্রকার বা সম্পত্তির প্রসঙ্গ পরিবর্তন করতে পারেন এবং এমনকি এটিকে সরিয়ে দিতে পারেন।

একটি সিস্টেম সম্পত্তির স্থায়িত্ব নির্ধারণ করতে নিম্নলিখিত প্রশ্ন জিজ্ঞাসা করুন:

এই সিস্টেম সম্পত্তি কি অংশীদারদের দ্বারা কনফিগার করার উদ্দেশ্যে (বা ডিভাইস প্রতি আলাদাভাবে কনফিগার করা হয়েছে)? যদি হ্যাঁ, এটি অবশ্যই স্থিতিশীল হতে হবে।
এই AOSP-সংজ্ঞায়িত সিস্টেম প্রপার্টিটি কি vendor.img বা product.img এর মতো নন-সিস্টেম পার্টিশনে বিদ্যমান কোড (প্রক্রিয়া নয়) থেকে লেখা বা পড়ার উদ্দেশ্যে? যদি হ্যাঁ, এটি অবশ্যই স্থিতিশীল হতে হবে।
এই সিস্টেম সম্পত্তি কি মেইনলাইন মডিউল জুড়ে বা একটি মেইনলাইন মডিউল এবং প্ল্যাটফর্মের অ-আপডেটযোগ্য অংশ জুড়ে অ্যাক্সেস করা হয়েছে? যদি হ্যাঁ, এটি অবশ্যই স্থিতিশীল হতে হবে।

স্থিতিশীল সিস্টেম বৈশিষ্ট্যের জন্য, প্রতিটিকে একটি API হিসাবে আনুষ্ঠানিকভাবে সংজ্ঞায়িত করুন এবং সিস্টেম সম্পত্তি অ্যাক্সেস করতে API ব্যবহার করুন, যেমন ধাপ 6 এ ব্যাখ্যা করা হয়েছে।

দ্রষ্টব্য: AOSP সুপারিশ করে যে আপনি একটি এপিআই হিসাবে একটি সিস্টেম সম্পত্তি সংজ্ঞায়িত করুন এমনকি যদি এটি স্থিতিশীল হওয়ার প্রয়োজন না হয়। এটি করার ফলে আপনার মডিউলের মালিকানাধীন সমস্ত সিস্টেম বৈশিষ্ট্যগুলিকে একটি একক দৃশ্যে পরিষ্কারভাবে গণনা করা হয় এবং একটি অস্থির সিস্টেম সম্পত্তিকে একটি স্থিতিশীল একটিতে উন্নীত করার প্রক্রিয়াটিকে সহজ করে। (স্থিতিশীল এবং অস্থির সিস্টেম সম্পত্তি সংজ্ঞার মধ্যে পার্থক্য করার প্রক্রিয়াটি ধাপ 6 এ ব্যাখ্যা করা হয়েছে।)

ধাপ 5: নির্মাণের সময় বৈশিষ্ট্য সেট করা

মেকফাইল ভেরিয়েবল সহ বিল্ড টাইমে বৈশিষ্ট্য সেট করুন। প্রযুক্তিগতভাবে, মানগুলি {partition}/build.prop এ বেক করা হয়। তারপর বৈশিষ্ট্য সেট করতে init {partition}/build.prop পড়ে। এই ধরনের ভেরিয়েবলের দুটি সেট আছে: PRODUCT_{PARTITION}_PROPERTIES এবং TARGET_{PARTITION}_PROP ।

PRODUCT_{PARTITION}_PROPERTIES সম্পত্তির মানগুলির একটি তালিকা রয়েছে৷ সিনট্যাক্স হল {prop}={value} বা {prop}?={value} ।

{prop}={value} হল একটি সাধারণ অ্যাসাইনমেন্ট যা নিশ্চিত করে যে {prop} সেট করা আছে {value} ; একটি একক সম্পত্তি প্রতি শুধুমাত্র একটি এসাইনমেন্ট সম্ভব.

{prop}?={value} একটি ঐচ্ছিক অ্যাসাইনমেন্ট; যদি কোনো { {prop} {prop}={value} অ্যাসাইনমেন্ট না থাকে তবেই {prop} { {value} এ সেট করে। একাধিক ঐচ্ছিক অ্যাসাইনমেন্ট বিদ্যমান থাকলে, প্রথমটি জিতবে।

# sets persist.traced.enable to 1 with system/build.prop
PRODUCT_SYSTEM_PROPERTIES += persist.traced.enable=1

# sets ro.zygote to zygote32 with system/build.prop
# but only when there are no other assignments to ro.zygote
# optional are useful when giving a default value to a property
PRODUCT_SYSTEM_PROPERTIES += ro.zygote?=zygote32

# sets ro.config.low_ram to true with vendor/build.prop
PRODUCT_VENDOR_PROPERTIES += ro.config.low_ram=true

TARGET_{PARTITION}_PROP ফাইলগুলির একটি তালিকা রয়েছে, যা সরাসরি {partition}/build.prop এ নির্গত হয়। প্রতিটি ফাইলে {prop}={value} জোড়ার একটি তালিকা রয়েছে।

# example.prop

ro.cp_system_other_odex=0
ro.adb.secure=0
ro.control_privapp_permissions=disable

# emits example.prop to system/build.prop
TARGET_SYSTEM_PROP += example.prop

আরও বিস্তারিত জানার জন্য, build/make/core/sysprop.mk দেখুন।

ধাপ 6: রানটাইমে বৈশিষ্ট্য অ্যাক্সেস করুন

অবশ্যই, বৈশিষ্ট্য রানটাইমে পড়া এবং লেখা যেতে পারে।

Init স্ক্রিপ্ট

Init স্ক্রিপ্ট ফাইলগুলি (সাধারণত *.rc ফাইলগুলি) ${prop} বা ${prop:-default} দ্বারা একটি প্রপার্টি পড়তে পারে, একটি অ্যাকশন সেট করতে পারে যা চলে যখনই একটি প্রপার্টি একটি নির্দিষ্ট মান হয়ে যায়, এবং setprop ব্যবহার করে বৈশিষ্ট্যগুলি লিখতে পারে আদেশ

# when persist.device_config.global_settings.sys_traced becomes 1,
# set persist.traced.enable to 1
on property:persist.device_config.global_settings.sys_traced=1
    setprop persist.traced.enable 1

# when security.perf_harden becomes 0,
# write /proc/sys/kernel/sample_rate to the value of
# debug.sample_rate. If it's empty, write -100000 instead
on property:security.perf_harden=0
    write /proc/sys/kernel/sample_rate ${debug.sample_rate:-100000}

getprop এবং setprop শেল কমান্ড

বৈশিষ্ট্যগুলি পড়তে বা লিখতে আপনি যথাক্রমে getprop বা setprop শেল কমান্ড ব্যবহার করতে পারেন। আরও বিশদ বিবরণের জন্য, getprop --help অথবা setprop --help আহ্বান করুন।

$ adb shell getprop ro.vndk.version
$
$ adb shell setprop security.perf_harden 0

C++/Java/Rust-এর জন্য API হিসেবে Sysprop

sysprop-কে API হিসাবে, আপনি সিস্টেমের বৈশিষ্ট্যগুলিকে সংজ্ঞায়িত করতে পারেন এবং স্বয়ংক্রিয়-উত্পন্ন API ব্যবহার করতে পারেন যা কংক্রিট এবং টাইপ করা হয়। Public সাথে scope সেট করার ফলে সীমানা জুড়ে মডিউলগুলিতে জেনারেট করা APIগুলি উপলব্ধ করে এবং API স্থায়িত্ব নিশ্চিত করে। এখানে একটি .sysprop ফাইলের একটি নমুনা, একটি Android.bp মডিউল এবং C++, জাভা এবং রাস্ট কোড সেগুলি ব্যবহার করে৷

# AudioProps.sysprop
# module becomes static class (Java) / namespace (C++) for serving API
module: "android.sysprop.AudioProps"
# owner can be Platform or Vendor or Odm
owner: Platform
# one prop defines one property
prop {
    prop_name: "ro.audio.volume.level"
    type: Integer
    scope: Public
    access: ReadWrite
    api_name: "volume_level"
}
…

// Android.bp
sysprop_library {
    name: "AudioProps",
    srcs: ["android/sysprop/AudioProps.sysprop"],
    property_owner: "Platform",
}

// Rust, Java and C++ modules can link against the sysprop_library
rust_binary {
    rustlibs: ["libaudioprops_rust"],
    …
}

java_library {
    static_libs: ["AudioProps"],
    …
}

cc_binary {
    static_libs: ["libAudioProps"],
    …
}

// Rust code accessing generated API.
// Get volume. Use 50 as the default value.
let vol = audioprops::volume_level()?.unwrap_or_else(50);

// Java codes accessing generated API
// get volume. use 50 as the default value.
int vol = android.sysprop.AudioProps.volume_level().orElse(50);
// add 10 to the volume level.
android.sysprop.AudioProps.volume_level(vol + 10);

// C++ codes accessing generated API
// get volume. use 50 as the default value.
int vol = android::sysprop::AudioProps::volume_level().value_or(50);
// add 10 to the volume level.
android::sysprop::AudioProps::volume_level(vol + 10);

আরও তথ্যের জন্য, এপিআই হিসাবে সিস্টেম বৈশিষ্ট্য বাস্তবায়ন দেখুন।

C/C++, Java এবং Rust নিম্ন-স্তরের সম্পত্তি ফাংশন এবং পদ্ধতি

যখন সম্ভব হয়, নিম্ন-স্তরের C/C++ বা মরিচা ফাংশন বা নিম্ন-স্তরের জাভা পদ্ধতিগুলি আপনার কাছে উপলব্ধ থাকলেও API হিসাবে Sysprop ব্যবহার করুন।

libc , libbase , এবং libcutils C++ সিস্টেম প্রপার্টি ফাংশন অফার করে। libc এর অন্তর্নিহিত API রয়েছে, যখন libbase এবং libcutils ফাংশনগুলি হল wrappers। যদি সম্ভব হয়, libbase sysprop ফাংশন ব্যবহার করুন; তারা সবচেয়ে সুবিধাজনক, এবং হোস্ট বাইনারি libbase ফাংশন ব্যবহার করতে পারে। আরো বিস্তারিত জানার জন্য, sys/system_properties.h ( libc ), android-base/properties.h ( libbase ), এবং cutils/properties.h ( libcutils ) দেখুন।

android.os.SystemProperties ক্লাস জাভা সিস্টেম সম্পত্তি পদ্ধতি অফার করে।

rustutils::system_properties মডিউল মরিচা সিস্টেম সম্পত্তি ফাংশন এবং প্রকার অফার করে।

পরিশিষ্ট: বিক্রেতা-নির্দিষ্ট বৈশিষ্ট্য যোগ করা

অংশীদাররা (Pixel ডেভেলপমেন্টের প্রেক্ষাপটে কাজ করা Googlers সহ) হার্ডওয়্যার-নির্দিষ্ট (বা ডিভাইস-নির্দিষ্ট) সিস্টেম বৈশিষ্ট্যগুলি সংজ্ঞায়িত করতে চায়। বিক্রেতা-নির্দিষ্ট বৈশিষ্ট্য হল অংশীদার-মালিকানাধীন বৈশিষ্ট্য যা তাদের নিজস্ব হার্ডওয়্যার বা ডিভাইসের জন্য অনন্য, প্ল্যাটফর্মের জন্য নয়। যেহেতু এগুলি হার্ডওয়্যার বা ডিভাইস নির্ভর, তাই এগুলিকে /vendor বা /odm পার্টিশনের মধ্যে ব্যবহার করতে হবে।

প্রজেক্ট ট্রেবলের পর থেকে, প্ল্যাটফর্মের বৈশিষ্ট্য এবং বিক্রেতার বৈশিষ্ট্যগুলিকে সম্পূর্ণরূপে বিভক্ত করা হয়েছে যাতে সেগুলিকে পরস্পরবিরোধী না করা যায়৷ নিম্নলিখিত বর্ণনা করে কিভাবে বিক্রেতার বৈশিষ্ট্যগুলিকে সংজ্ঞায়িত করতে হয় এবং কোন বিক্রেতার বৈশিষ্ট্যগুলি সর্বদা ব্যবহার করা উচিত তা বলে৷

সম্পত্তি এবং প্রসঙ্গ নামের নেমস্পেস

সমস্ত বিক্রেতার বৈশিষ্ট্যগুলিকে নিম্নলিখিত উপসর্গগুলির মধ্যে একটি দিয়ে শুরু করতে হবে যাতে তাদের এবং অন্যান্য পার্টিশনের বৈশিষ্ট্যগুলির মধ্যে সংঘর্ষ রোধ করা যায়।

ctl.odm.
ctl.vendor.
ctl.start$odm.
ctl.start$vendor.
ctl.stop$odm.
ctl.stop$vendor.
init.svc.odm.
init.svc.vendor.
ro.odm.
ro.vendor.
odm.
persist.odm.
persist.vendor.
vendor.

নোট করুন যে ro.hardware. একটি উপসর্গ হিসাবে অনুমোদিত, কিন্তু শুধুমাত্র সামঞ্জস্যের জন্য। সাধারণ বৈশিষ্ট্যের জন্য এটি ব্যবহার করবেন না।

নিম্নলিখিত উদাহরণগুলি পূর্ববর্তী তালিকাভুক্ত উপসর্গগুলির একটি ব্যবহার করে:

vendor.display.primary_red
persist.vendor.faceauth.use_disk_cache
ro.odm.hardware.platform

সমস্ত বিক্রেতার সম্পত্তি প্রসঙ্গে অবশ্যই vendor_ দিয়ে শুরু করতে হবে। এটি সামঞ্জস্যের জন্যও। নিম্নলিখিত উদাহরণ:

vendor_radio_prop
vendor_faceauth_prop .
vendor_usb_prop ।

সম্পত্তির নামকরণ এবং রক্ষণাবেক্ষণ করা বিক্রেতার দায়িত্ব, তাই বিক্রেতার নেমস্পেসের প্রয়োজনীয়তা ছাড়াও ধাপ 2 এ প্রস্তাবিত বিন্যাসটি অনুসরণ করুন।

বিক্রেতা-নির্দিষ্ট এসইপলিসি নিয়ম এবং সম্পত্তি_প্রসঙ্গ

বিক্রেতার বৈশিষ্ট্য vendor_internal_prop ম্যাক্রো দ্বারা সংজ্ঞায়িত করা যেতে পারে। BOARD_VENDOR_SEPOLICY_DIRS ডিরেক্টরিতে আপনার সংজ্ঞায়িত বিক্রেতা-নির্দিষ্ট নিয়মগুলি রাখুন৷ উদাহরণস্বরূপ, ধরুন আপনি প্রবালের মধ্যে একটি বিক্রেতা faceauth সম্পত্তি সংজ্ঞায়িত করছেন৷

BoardConfig.mk ফাইলে (অথবা যেকোনো BoardConfig.mk অন্তর্ভুক্ত), নিম্নলিখিতগুলি রাখুন:

BOARD_VENDOR_SEPOLICY_DIRS := device/google/coral-sepolicy

device/google/coral-sepolicy/private/property.te ফাইলে, নিম্নলিখিতগুলি রাখুন:

vendor_internal_prop(vendor_faceauth_prop)

device/google/coral-sepolicy/private/property_contexts ফাইলে, নিম্নলিখিতগুলি রাখুন:

vendor.faceauth.trace u:object_r:vendor_faceauth_prop:s0 exact bool

বিক্রেতার বৈশিষ্ট্যের সীমাবদ্ধতা

যেহেতু সিস্টেম এবং পণ্য পার্টিশনগুলি বিক্রেতার উপর নির্ভর করতে পারে না, তাই কখনই বিক্রেতার বৈশিষ্ট্যগুলিকে system , system-ext বা product পার্টিশন থেকে অ্যাক্সেস করার অনুমতি দেবেন না।

পরিশিষ্ট: বিদ্যমান বৈশিষ্ট্যের নাম পরিবর্তন করা

যখন আপনাকে অবশ্যই একটি সম্পত্তির অবমূল্যায়ন করতে হবে এবং একটি নতুনটিতে যেতে হবে, তখন আপনার বিদ্যমান বৈশিষ্ট্যগুলিকে পুনঃনামকরণ করতে API হিসাবে Sysprop ব্যবহার করুন৷ এটি উত্তরাধিকার নাম এবং নতুন সম্পত্তি নাম উভয় নির্দিষ্ট করে পশ্চাদপদ সামঞ্জস্য বজায় রাখে। বিশেষভাবে, আপনি .sysprop ফাইলে legacy_prop_name ক্ষেত্র দ্বারা উত্তরাধিকার নাম সেট করতে পারেন। জেনারেট করা API prop_name পড়ার চেষ্টা করে এবং যদি prop_name বিদ্যমান না থাকে তাহলে legacy_prop_name ব্যবহার করে।

উদাহরণ স্বরূপ, নিম্নলিখিত ধাপগুলি awesome_feature_foo_enabled নাম পরিবর্তন করে foo.awesome_feature.enabled করুন।

foo.sysprop ফাইলে

module: "android.sysprop.foo"
owner: Platform
prop {
    api_name: "is_awesome_feature_enabled"
    type: Boolean
    scope: Public
    access: Readonly
    prop_name: "foo.awesome_feature.enabled"
    legacy_prop_name: "awesome_feature_foo_enabled"
}

C++ কোডে

// is_awesome_feature_enabled() reads "foo.awesome_feature.enabled".
// If it doesn't exist, reads "awesome_feature_foo_enabled" instead
using android::sysprop::foo;

bool enabled = foo::is_awesome_feature_enabled().value_or(false);

নিম্নলিখিত সতর্কতা নোট করুন:

প্রথমত, আপনি sysprop এর ধরন পরিবর্তন করতে পারবেন না। উদাহরণস্বরূপ, আপনি একটি string প্রপ মধ্যে একটি int প্রপ করতে পারবেন না. আপনি শুধুমাত্র নাম পরিবর্তন করতে পারেন.
দ্বিতীয়ত, শুধুমাত্র পঠিত API উত্তরাধিকার নামে ফিরে আসে। লেখার API ফিরে আসে না। যদি sysprop একটি লেখার যোগ্য হয় তবে আপনি এটির নাম পরিবর্তন করতে পারবেন না।