গুগল কালো সম্প্রদায়ের জন্য জাতিগত সমতা উন্নয়নে প্রতিশ্রুতিবদ্ধ। দেখ কিভাবে.
This page was translated by the Cloud Translation API.
Switch to English

সেলইনাক্স অনুকূলিতকরণ

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

উত্পাদনকারীদের বিদ্যমান SELinux নীতিটি সরানো উচিত নয়। অন্যথায়, তারা Android SELinux বাস্তবায়ন এবং এটি পরিচালনা করে এমন অ্যাপ্লিকেশনগুলি ভঙ্গ করে। এর মধ্যে তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি অন্তর্ভুক্ত রয়েছে যা সম্ভবত অনুগত এবং কার্যকর হওয়ার জন্য উন্নত করা দরকার। অ্যাপ্লিকেশনগুলিতে SELinux- সক্ষম ডিভাইসগুলিতে কাজ চালিয়ে যেতে কোনও পরিবর্তনের প্রয়োজন নেই।

SELinux কাস্টমাইজ করার সময়, মনে রাখবেন:

  • সমস্ত নতুন ডেমনগুলির জন্য SELinux নীতি লিখুন
  • যখনই উপযুক্ত হবে পূর্বনির্ধারিত ডোমেনগুলি ব্যবহার করুন
  • যে কোনও init পরিষেবা হিসাবে প্রবর্তিত কোনও প্রক্রিয়াতে একটি ডোমেন বরাদ্দ করুন
  • নীতি লেখার আগে ম্যাক্রোগুলির সাথে পরিচিত হন
  • মূল নীতিতে পরিবর্তন এওএসপিতে জমা দিন

এবং মনে রাখবেন না:

  • বেমানান নীতি তৈরি করুন
  • শেষ ব্যবহারকারী নীতি কাস্টমাইজেশনের অনুমতি দিন
  • MDM নীতি কাস্টমাইজেশন অনুমতি দিন
  • নীতি লঙ্ঘন সহ ব্যবহারকারীদের ভয় পান
  • পিছনের ঘরে যুক্ত করুন

নির্দিষ্ট প্রয়োজনীয়তার জন্য অ্যান্ড্রয়েড সামঞ্জস্যতা সংজ্ঞা নথির কর্নেল সুরক্ষা বৈশিষ্ট্য বিভাগটি দেখুন।

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

  1. সর্বশেষতম অ্যান্ড্রয়েড কার্নেলটি ব্যবহার করুন।
  2. ন্যূনতম সুবিধার নীতি গ্রহণ করুন।
  3. অ্যান্ড্রয়েডে কেবলমাত্র নিজের সংযোজনগুলির ঠিকানা দিন। ডিফল্ট নীতিটি অ্যান্ড্রয়েড ওপেন সোর্স প্রকল্প কোডবেস স্বয়ংক্রিয়ভাবে কাজ করে।
  4. একক কার্য সম্পাদনকারী মডিউলগুলিতে সফ্টওয়্যার উপাদানগুলিকে বিভাগযুক্ত করুন।
  5. এসিলিনাক্স নীতিগুলি তৈরি করুন যা এই কার্যগুলিকে সম্পর্কযুক্ত ফাংশন থেকে আলাদা করে দেয়।
  6. এই নীতিগুলিকে *.te ফাইলগুলিতে ( *.te নীতি উত্স ফাইলগুলির জন্য এক্সটেনশন) /device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে রাখুন এবং আপনার বিল্ডে অন্তর্ভুক্ত করতে BOARD_SEPOLICY ভেরিয়েবল ব্যবহার করুন।
  7. নতুন ডোমেইনগুলিকে প্রাথমিকভাবে অনুমতি দিন। এটি ডোমেনের .te ফাইলটিতে .te ঘোষণা ব্যবহার করে করা হয়।
  8. ফলাফল বিশ্লেষণ করুন এবং আপনার ডোমেন সংজ্ঞাগুলি পরিমার্জন করুন।
  9. ব্যবহারকারীদেবগ বিল্ডগুলিতে আর কোনও অস্বীকৃতি না উপস্থিত হলে অনুমোদনযোগ্য ঘোষণাটি সরিয়ে ফেলুন।

আপনার SELinux নীতি পরিবর্তনটি সংহত করার পরে, SELinux সামঞ্জস্যতা এগিয়ে চলেছে তা নিশ্চিত করতে আপনার বিকাশ কর্মপ্রবাহে একটি পদক্ষেপ যুক্ত করুন। একটি আদর্শ সফ্টওয়্যার বিকাশ প্রক্রিয়াতে, সেলইনাক্স নীতিটি তখনই পরিবর্তন হয় যখন সফ্টওয়্যার মডেলটি পরিবর্তিত হয় এবং প্রকৃত বাস্তবায়ন হয় না।

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

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

উদাহরণ নীতি বিবৃতি

সেলইনাক্স এম 4 কম্পিউটার ভাষার উপর ভিত্তি করে এবং তাই সময় বাঁচাতে বিভিন্ন ম্যাক্রো সমর্থন করে।

নিম্নলিখিত উদাহরণে, সমস্ত ডোমেনগুলি /dev/null থেকে পড়তে এবং /dev/zero থেকে পড়তে এবং অ্যাক্সেসের অনুমতি দেওয়া /dev/zero

# Allow read / write access to /dev/null
allow domain null_device:chr_file { getattr open read ioctl lock append write};

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file { getattr open read ioctl lock };

এই একই বিবৃতিটি *_file_perms ম্যাক্রোস (শর্টহ্যান্ড) দিয়ে লেখা যেতে পারে:

# Allow read / write access to /dev/null
allow domain null_device:chr_file rw_file_perms;

# Allow read-only access to /dev/zero
allow domain zero_device:chr_file r_file_perms;

উদাহরণ নীতি

ডিএইচসিপির জন্য এখানে একটি সম্পূর্ণ উদাহরণ নীতি, যা আমরা নীচে পরীক্ষা করি:

type dhcp, domain;
permissive dhcp;
type dhcp_exec, exec_type, file_type;
type dhcp_data_file, file_type, data_file_type;

init_daemon_domain(dhcp)
net_domain(dhcp)

allow dhcp self:capability { setgid setuid net_admin net_raw net_bind_service
};
allow dhcp self:packet_socket create_socket_perms;
allow dhcp self:netlink_route_socket { create_socket_perms nlmsg_write };
allow dhcp shell_exec:file rx_file_perms;
allow dhcp system_file:file rx_file_perms;
# For /proc/sys/net/ipv4/conf/*/promote_secondaries
allow dhcp proc_net:file write;
allow dhcp system_prop:property_service set ;
unix_socket_connect(dhcp, property, init)

type_transition dhcp system_data_file:{ dir file } dhcp_data_file;
allow dhcp dhcp_data_file:dir create_dir_perms;
allow dhcp dhcp_data_file:file create_file_perms;

allow dhcp netd:fd use;
allow dhcp netd:fifo_file rw_file_perms;
allow dhcp netd:{ dgram_socket_class_set unix_stream_socket } { read write };
allow dhcp netd:{ netlink_kobject_uevent_socket netlink_route_socket
netlink_nflog_socket } { read write };

উদাহরণটি বিচ্ছিন্ন করুন:

প্রথম লাইনে, টাইপ ডিক্লেয়ারেশন, ডিএইচসিপি ডেমন বেস সুরক্ষা নীতি ( domain ) থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হয়। পূর্ববর্তী বিবৃতি উদাহরণ থেকে, ডিএইচসিপি /dev/null থেকে পড়তে এবং লিখতে পারে।

দ্বিতীয় লাইনে, ডিএইচসিপি একটি অনুমতিপ্রাপ্ত ডোমেন হিসাবে চিহ্নিত করা হয়েছে।

init_daemon_domain(dhcp) লাইনে নীতিতে DHCP টি init থেকে তৈরি করা হয়েছে এবং এর সাথে যোগাযোগের অনুমতি দেওয়া হয়েছে।

net_domain(dhcp) লাইনে, নীতিটি DHCP কে net ডোমেন থেকে সাধারণ নেটওয়ার্ক কার্যকারিতা যেমন TCP প্যাকেটগুলি পড়া এবং লেখার জন্য, সকেটের উপরে যোগাযোগ করে এবং DNS অনুরোধগুলি পরিচালনা করার অনুমতি দেয়।

লাইনে allow dhcp proc_net:file write; , নীতিটি জানিয়েছে যে ডিএইচসিপি /proc নির্দিষ্ট ফাইলগুলিতে লিখতে পারে। এই লাইনটি সেলইনাক্সের সূক্ষ্ম-দানাযুক্ত ফাইল লেবেলিং প্রদর্শন করে। এটি /proc/sys/net অধীনে কেবল ফাইলগুলিতে লেখার অ্যাক্সেসকে সীমাবদ্ধ করতে proc_net লেবেল ব্যবহার করে।

উদাহরণস্বরূপ চূড়ান্ত ব্লকটি allow dhcp netd:fd use; দিয়ে শুরু করুন allow dhcp netd:fd use; অ্যাপ্লিকেশনগুলিকে কীভাবে একে অপরের সাথে ইন্টারঅ্যাক্ট করার অনুমতি দেওয়া যেতে পারে তা চিত্রিত করে। নীতিটিতে বলা হয়েছে যে ডিএইচসিপি এবং নেটড একে অপরের সাথে ফাইল বর্ণনাকারী, ফিফো ফাইল, ডেটাগ্রাম সকেট এবং ইউনিক্স স্ট্রিম সকেটের মাধ্যমে যোগাযোগ করতে পারে। ডিএইচসিপি কেবল ডেটাগ্রাম সকেট এবং ইউনিক্স স্ট্রিম সকেটগুলি থেকে পড়তে এবং লিখতে পারে এবং সেগুলি তৈরি বা খুলতে পারে না।

উপলব্ধ নিয়ন্ত্রণ

শ্রেণী অনুমতি
ফাইল
ioctl read write create getattr setattr lock relabelfrom relabelto append
unlink link rename execute swapon quotaon mounton
ডিরেক্টরি
add_name remove_name reparent search rmdir open audit_access execmod
সকেট
ioctl read write create getattr setattr lock relabelfrom relabelto append bind
connect listen accept getopt setopt shutdown recvfrom sendto recv_msg send_msg
name_bind
নথি ব্যবস্থা
mount remount unmount getattr relabelfrom relabelto transition associate
quotamod quotaget
প্রক্রিয়া
fork transition sigchld sigkill sigstop signull signal ptrace getsched setsched
getsession getpgid setpgid getcap setcap share getattr setexec setfscreate
noatsecure siginh setrlimit rlimitinh dyntransition setcurrent execmem
execstack execheap setkeycreate setsockcreate
নিরাপত্তা
compute_av compute_create compute_member check_context load_policy
compute_relabel compute_user setenforce setbool setsecparam setcheckreqprot
read_policy
সামর্থ্য
chown dac_override dac_read_search fowner fsetid kill setgid setuid setpcap
linux_immutable net_bind_service net_broadcast net_admin net_raw ipc_lock
ipc_owner sys_module sys_rawio sys_chroot sys_ptrace sys_pacct sys_admin
sys_boot sys_nice sys_resource sys_time sys_tty_config mknod lease audit_write
audit_control setfcap

আরও

এবং আরও

নিউভারেলো বিধি

neverallow বিধিগুলি এমন আচরণকে নিষিদ্ধ করে যা কখনই ঘটে না। সামঞ্জস্যতা পরীক্ষা সহ, neverallow নিয়মগুলি এখন ডিভাইস জুড়ে প্রয়োগ করা হয়েছে।

নিম্নলিখিত নির্দেশিকাগুলি নির্মাতাদের কাস্টমাইজেশনের সময় neverallow নিয়মের সাথে সম্পর্কিত ত্রুটিগুলি এড়াতে সহায়তা করার উদ্দেশ্যে তৈরি করা হয়েছে। এখানে ব্যবহৃত নিয়ম সংখ্যা অ্যান্ড্রয়েড 5.1 এর সাথে সামঞ্জস্যপূর্ণ এবং প্রকাশের দ্বারা পরিবর্তিত হতে পারে।

বিধি 48: neverallow { domain -debuggerd -vold -dumpstate -system_server } self:capability sys_ptrace;
ptrace জন্য ম্যান পৃষ্ঠা দেখুন। sys_ptrace সামর্থ্য যে কোনও প্রক্রিয়া ptrace করার ক্ষমতা দেয়, যা অন্যান্য প্রক্রিয়াগুলির উপর নিয়ন্ত্রণের অনেক বেশি সুযোগ দেয় এবং নিয়মে বর্ণিত বর্ণিত সিস্টেম উপাদানগুলির sys_ptrace হওয়া উচিত। এই সক্ষমতার প্রয়োজনীয়তা প্রায়শই এমন কোনও কিছুর উপস্থিতি নির্দেশ করে যা ব্যবহারকারীর মুখোমুখি বিল্ড বা কার্যকারিতা নয় যা প্রয়োজন হয় না। অপ্রয়োজনীয় উপাদান সরান।

neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute; 76 বিধি: neverallow { domain -appdomain -dumpstate -shell -system_server -zygote } { file_type -system_file -exec_type }:file execute;
এই বিধিটি সিস্টেমটিতে স্বেচ্ছাচারিত কোড প্রয়োগ করা রোধ করার উদ্দেশ্যে। বিশেষত, এটি দৃser়ভাবে জানায় যে কেবলমাত্র /system কোড কার্যকর করা হয় যা সুরক্ষার নিশ্চয়তা দেয় যেমন যাচাই করা বুটের মতো প্রক্রিয়াগুলিকে ধন্যবাদ জানায়। প্রায়শই, এই neverallow নিয়মের কোনও সমস্যার মুখোমুখি হওয়ার সেরা সমাধান neverallow আপত্তিজনক neverallow /system পার্টিশনে স্থানান্তর করা।

অ্যান্ড্রয়েড 8.0+ এ এসপোলিসি অনুকূলিতকরণ

এই বিভাগটি অ্যান্ড্রয়েড ওপেন সোর্স প্রজেক্ট (এওএসপি) এসইপলিসি এবং এসইপলিসি এক্সটেনশনের বিশদ সহ অ্যান্ড্রয়েড 8.0 এবং উচ্চতর উইন্ডোজ সেলিনাক্স নীতিমালার জন্য গাইডলাইন সরবরাহ করে। পার্টিশন এবং অ্যান্ড্রয়েড সংস্করণ জুড়ে কীভাবে SELinux নীতি সামঞ্জস্যপূর্ণ রাখা হয়েছে সে সম্পর্কে আরও তথ্যের জন্য, সামঞ্জস্যতা দেখুন

নীতি স্থান

অ্যান্ড্রয়েড BOARD_SEPOLICY_DIRS এবং তার আগে, ডিভাইস নির্মাতারা BOARD_SEPOLICY_DIRS নীতি যুক্ত করতে BOARD_SEPOLICY_DIRS , যার সাথে বিভিন্ন ডিভাইসের ধরণের জুড়ে AOSP নীতি BOARD_SEPOLICY_DIRS হয় BOARD_SEPOLICY_DIRS অ্যান্ড্রয়েড ৮.০ এবং উচ্চতর ক্ষেত্রে, BOARD_SEPOLICY_DIRS একটি নীতি যুক্ত করা BOARD_SEPOLICY_DIRS নীতিটি বিক্রেতা চিত্রের মধ্যে রাখে।

অ্যান্ড্রয়েড 8.0 এবং উচ্চতরতে, নীতিটি এওএসপিতে নিম্নলিখিত অবস্থানগুলিতে বিদ্যমান:

  • সিস্টেম / সিপিলিস / পাবলিক । বিক্রেতা-নির্দিষ্ট নীতিতে ব্যবহারের জন্য রফতানি করা নীতি অন্তর্ভুক্ত করে। সবকিছু অ্যান্ড্রয়েড 8.0 সামঞ্জস্যপূর্ণ অবকাঠামোতে যায় । পাবলিক পলিসি রিলিজ জুড়েই বজায় রাখা বোঝায় যাতে আপনি নিজের কাস্টমাইজড নীতিতে কোনও কিছু /public অন্তর্ভুক্ত করতে পারেন। এ কারণে, /public মধ্যে যে ধরণের নীতিমালা স্থাপন করা যায় তা আরও সীমাবদ্ধ। এই প্ল্যাটফর্মের রফতানি করা নীতি API এ বিবেচনা করুন: /system এবং /vendor মধ্যে ইন্টারফেসের সাথে যে কোনও কিছুই হ'ল এখানে belongs
  • সিস্টেম / সিপিলিসি / প্রাইভেট । সিস্টেম চিত্রের কাজ করার জন্য প্রয়োজনীয় নীতি অন্তর্ভুক্ত করে তবে এর মধ্যে বিক্রেতার চিত্র নীতিটির কোনও জ্ঞান থাকা উচিত নয়।
  • সিস্টেম / সিপোলিসি / বিক্রেতার যে উপাদানগুলিতে /vendor তবে মূল প্ল্যাটফর্ম ট্রিতে উপস্থিত (ডিভাইস-নির্দিষ্ট ডিরেক্টরি নয়) এর জন্য নীতি অন্তর্ভুক্ত। এটি ডিভাইস এবং বৈশ্বিক উপাদানগুলির মধ্যে বিল্ড সিস্টেমের পার্থক্যের একটি নিদর্শন; ধারণামূলকভাবে এটি নীচে বর্ণিত ডিভাইস-নির্দিষ্ট নীতিটির একটি অংশ।
  • ডিভাইস / manufacturer / device-name / সেলপোলিস । ডিভাইস-নির্দিষ্ট নীতি অন্তর্ভুক্ত। এছাড়াও নীতিতে ডিভাইস কাস্টমাইজেশন অন্তর্ভুক্ত রয়েছে, যা অ্যান্ড্রয়েড 8.0 এবং এর চেয়ে বেশি বিক্রেতার চিত্রের উপাদানগুলির জন্য নীতিটির সাথে মিলে যায়।

সমর্থিত নীতি পরিস্থিতি

অ্যান্ড্রয়েড ৮.০ এবং তার থেকেও উচ্চতর ডিভাইসগুলিতে প্রবর্তনকারী ডিভাইসে, বিক্রেতার চিত্রটি অবশ্যই OEM সিস্টেম চিত্র এবং Google এর সরবরাহিত রেফারেন্স এওএসপি সিস্টেম চিত্রের সাথে কাজ করবে (এবং এই রেফারেন্স চিত্রটিতে সিটিএস পাস করবে)। এই প্রয়োজনীয়তাগুলি ফ্রেমওয়ার্ক এবং বিক্রেতা কোডের মধ্যে একটি পরিষ্কার বিচ্ছিন্নতা নিশ্চিত করে। এই জাতীয় ডিভাইসগুলি নিম্নলিখিত পরিস্থিতিতে সমর্থন করে।

বিক্রেতা-চিত্র-কেবল এক্সটেনশান

উদাহরণ : বিক্রেতার চিত্র থেকে vndservicemanager একটি নতুন পরিষেবা যুক্ত করা যা বিক্রেতা ইমেজ থেকে প্রক্রিয়াগুলি সমর্থন করে।

পূর্ববর্তী অ্যান্ড্রয়েড সংস্করণগুলির সাথে ডিভাইসগুলি চালু করার সাথে সাথে, device/ manufacturer / device-name /sepolicy ডিভাইস-নির্দিষ্ট কাস্টমাইজেশন যুক্ত করুন। নতুন নীতি নিয়ন্ত্রন করে যে কীভাবে বিক্রেতার উপাদানগুলি (কেবলমাত্র) অন্যান্য বিক্রেতাদের উপাদানগুলির সাথে কেবল device/ manufacturer / device-name /sepolicy এখানে লিখিত নীতিটি বিক্রেতার কোডকে কাজ করার অনুমতি দেয়, কেবলমাত্র ফ্রেমওয়ার্ক-ওটিএর অংশ হিসাবে আপডেট হবে না এবং রেফারেন্স এওএসপি সিস্টেম চিত্র সহ একটি ডিভাইসে সম্মিলিত নীতিতে উপস্থিত হবে।

AOSP এর সাথে কাজ করার জন্য বিক্রেতা-চিত্র সমর্থন support

উদাহরণ : একটি এওএসপি-সংজ্ঞায়িত এইচএএল প্রয়োগ করে এমন একটি নতুন প্রক্রিয়া (বিক্রেতার চিত্র থেকে hwservicemanager সাথে নিবন্ধিত) যুক্ত করা।

পূর্ববর্তী অ্যান্ড্রয়েড সংস্করণগুলির সাথে ডিভাইসগুলি চালু করার সাথে সাথে, device/ manufacturer / device-name /sepolicy ডিভাইস-নির্দিষ্ট কাস্টমাইজেশন device/ manufacturer / device-name /sepolicysystem/sepolicy/public/ অংশ হিসাবে রফতানি করা ব্যবহারের জন্য উপলভ্য, এবং বিক্রেতার নীতিটির অংশ হিসাবে পাঠানো হয়। পাবলিক পলিসি থেকে প্রকার এবং বৈশিষ্ট্যগুলি নতুন বিক্রেতার-নির্দিষ্ট বিটের সাথে ইন্টারঅ্যাকশন নির্দেশ করে নতুন বিধিগুলিতে ব্যবহার করা যেতে পারে, সরবরাহিত neverallow নিষেধাজ্ঞার neverallow । কেবলমাত্র বিক্রেতার ক্ষেত্রে যেমন, এখানে নতুন নীতিটি কেবলমাত্র ফ্রেমওয়ার্ক-ওটিএর অংশ হিসাবে আপডেট হবে না এবং রেফারেন্স এওএসপি সিস্টেম চিত্রের সাথে একটি ডিভাইসে সম্মিলিত নীতিতে উপস্থিত হবে।

সিস্টেম-চিত্র-কেবল এক্সটেনশান

উদাহরণ : একটি নতুন পরিষেবা যুক্ত করা (সার্ভিস ম্যানেজারের সাথে নিবন্ধিত) যা কেবল সিস্টেম ইমেজ থেকে অন্যান্য প্রক্রিয়া দ্বারা অ্যাক্সেস করা যায়।

এই নীতিটি system/sepolicy/private । অংশীদার সিস্টেমের ছবিতে কার্যকারিতা সক্ষম করার জন্য আপনি অতিরিক্ত প্রক্রিয়া বা অবজেক্ট যুক্ত করতে পারেন, তবে সেই নতুন বিটদের বিক্রেতার চিত্রটিতে নতুন উপাদানগুলির সাথে যোগাযোগের প্রয়োজন না হয় (বিশেষত, এই জাতীয় প্রক্রিয়াগুলি বা অবজেক্টগুলি অবশ্যই বিক্রেতার চিত্রের নীতি ছাড়াই পুরোপুরি কাজ করতে পারে) । system/sepolicy/public দ্বারা রফতানি করা নীতিটি কেবল বিক্রেতার-চিত্র-চিত্র এক্সটেনশনের জন্য যেমন এখানে উপলব্ধ। এই নীতিটি সিস্টেম ইমেজের অংশ এবং এটি কেবলমাত্র একটি ফ্রেমওয়ার্ক ওটিএতে আপডেট হতে পারে তবে রেফারেন্স এওএসপি সিস্টেম চিত্র ব্যবহার করার সময় উপস্থিত হবে না।

বিক্রেতার-চিত্র এক্সটেনশানগুলি যা বর্ধিত AOSP উপাদানগুলি সরবরাহ করে

উদাহরণ: বর্ধিত ক্লায়েন্টদের ব্যবহারের জন্য একটি নতুন, নন-এওএসপি এইচএল যা এওএসপি সিস্টেম ইমেজেও রয়েছে (যেমন প্রসারিত সিস্টেম_সার্ভার হিসাবে)।

সিস্টেম এবং বিক্রেতার মধ্যে মিথস্ক্রিয়াটির নীতি অবশ্যই বিক্রেতার পার্টিশনে প্রেরিত device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে অন্তর্ভুক্ত থাকতে হবে। এটি রেফারেন্স এওএসপি চিত্রের সাথে কাজ করার জন্য ভেন্ডর-ইমেজ সমর্থন যুক্ত করার উপরের দৃশ্যের অনুরূপ, পরিবর্তিত এওএসপি উপাদানগুলি ছাড়াও অন্যান্য সিস্টেম পার্টিশনটি সঠিকভাবে পরিচালনা করার জন্য অতিরিক্ত নীতিের প্রয়োজন হতে পারে (যা তারা এখনও যতক্ষণ না ঠিক আছে) সর্বজনীন এওএসপি টাইপের লেবেল রয়েছে)।

সিস্টেম-ইমেজ-কেবল এক্সটেনশানগুলির সাথে সর্বজনীন এওএসপি উপাদানগুলির ইন্টারঅ্যাক্ট করার নীতিটি system/sepolicy/private

সিস্টেম-চিত্রের এক্সটেনশানগুলি যা কেবল এওএসপি ইন্টারফেসগুলিতে অ্যাক্সেস করে

উদাহরণ: একটি নতুন, নন-এওএসপি সিস্টেম প্রক্রিয়া অবশ্যই এমন একটি এইচএল অ্যাক্সেস করতে হবে যার উপরে এওএসপি নির্ভর করে।

এটি সিস্টেম-ইমেজ-কেবল এক্সটেনশনের উদাহরণের মতো , নতুন সিস্টেমের উপাদানগুলি system/vendor ইন্টারফেস জুড়ে ইন্টারেক্ট করতে পারে except নতুন সিস্টেমের উপাদানগুলির জন্য নীতি অবশ্যই system/sepolicy/private যেতে হবে, এটি গ্রহণযোগ্য provided তবে এটি system/sepolicy/public মধ্যে ইতিমধ্যে এওএসপি দ্বারা প্রতিষ্ঠিত একটি ইন্টারফেসের মাধ্যমে (যেমন কার্যকারিতার জন্য প্রয়োজনীয় প্রকার ও বৈশিষ্ট্যগুলি রয়েছে)। যদিও নীতিটি ডিভাইস-নির্দিষ্ট নীতিতে অন্তর্ভুক্ত করা যেতে পারে তবে এটি কেবলমাত্র ফ্রেমওয়ার্ক-আপডেটের ফলে অন্যান্য system/sepolicy/private প্রকার বা কোনও পরিবর্তন (কোনও নীতি-প্রভাবিত পদ্ধতিতে) পরিবর্তন করতে অক্ষম। নীতিটি কেবল ফ্রেমওয়ার্ক-ওটিএ-তে পরিবর্তিত হতে পারে, তবে এওএসপি সিস্টেম চিত্র ব্যবহার করার সময় উপস্থিত হবে না (যার মধ্যে নতুন সিস্টেমের উপাদান নেই) component

নতুন সিস্টেম উপাদান পরিবেশনকারী বিক্রেতা-চিত্র এক্সটেনশনগুলি

উদাহরণ: কোনও এওএসপি অ্যানালগ ছাড়াই ক্লায়েন্ট প্রক্রিয়া দ্বারা ব্যবহারের জন্য একটি নতুন, নন-এওএসপি এইচএল যুক্ত করা (এবং এটির নিজস্ব ডোমেন প্রয়োজন)।

এওএসপি-এক্সটেনশনের উদাহরণের অনুরূপ, সিস্টেম এবং বিক্রেতার মধ্যে মিথস্ক্রিয়া সংক্রান্ত নীতিটি অবশ্যই বিক্রেতার পার্টিশনে device/ manufacturer / device-name /sepolicy ডিরেক্টরিতে যেতে হবে (সিস্টেম নীতিটি বিক্রেতার-নির্দিষ্ট বিশদ সম্পর্কিত কোনও জ্ঞান নেই তা নিশ্চিত করতে)। আপনি নতুন পাবলিক প্রকারগুলি যুক্ত করতে পারেন যা system/sepolicy/public ক্ষেত্রে নীতি প্রসারিত করে; এটি কেবল বিদ্যমান এওএসপি নীতি ছাড়াও করা উচিত, অর্থাৎ এওএসপি পাবলিক পলিসি অপসারণ করবেন না। এরপরে নতুন পাবলিক প্রকারগুলি system/sepolicy/private এবং device/ manufacturer / device-name /sepolicy নীতি হিসাবে ব্যবহার করা যেতে পারে।

মনে রাখবেন যে system/sepolicy/public প্রতিটি সংযোজন একটি নতুন সামঞ্জস্যের গ্যারান্টি প্রকাশের মাধ্যমে জটিলতা যুক্ত করে যা অবশ্যই ম্যাপিং ফাইলে ট্র্যাক করা উচিত এবং যা অন্যান্য বিধিনিষেধের সাপেক্ষে। system/sepolicy/public কেবলমাত্র নতুন ধরণের এবং সংশ্লিষ্ট অনুমতি বিধি যুক্ত করা যেতে পারে; বৈশিষ্ট্য এবং অন্যান্য নীতি বিবৃতিগুলি সমর্থন করে না। তদ্ব্যতীত, নতুন পাবলিক প্রকারগুলি /vendor নীতিতে সরাসরি লেবেলগুলিতে ব্যবহার করা যায় না।

অসমর্থিত নীতি পরিস্থিতি

অ্যান্ড্রয়েড 8.0 এবং উচ্চতর সহ প্রবর্তনকারী ডিভাইসগুলি নীচের নীতি পরিস্থিতি এবং উদাহরণগুলি সমর্থন করে না।

সিস্টেম-ইমেজের অতিরিক্ত এক্সটেনশানগুলির জন্য কেবলমাত্র ফ্রেমওয়ার্ক-ওটিএর পরে নতুন বিক্রেতা-চিত্র উপাদানগুলির অনুমতি প্রয়োজন

উদাহরণ: একটি নতুন নন-এওএসপি সিস্টেম প্রক্রিয়া, যার নিজস্ব ডোমেন প্রয়োজন, পরবর্তী অ্যান্ড্রয়েড রিলিজে যুক্ত করা হয় এবং একটি নতুন, এওএসপি এইচএল অ্যাক্সেসের প্রয়োজন needs

নতুন ( টাইপ -ও-ওএসপি) সিস্টেম এবং বিক্রেতার উপাদানগুলির মিথস্ক্রিয়ার অনুরূপ, নতুন সিস্টেমের ধরণ ব্যতীত কেবল একটি ফ্রেমওয়ার্ক-ওটিএ-তে প্রবর্তিত। যদিও system/sepolicy/public নতুন ধরণের যোগ করা যেতে পারে তবে বিদ্যমান বিক্রেতার system/sepolicy/public নতুন ধরণের কোনও জ্ঞান নেই কারণ এটি কেবল অ্যান্ড্রয়েড 8.0 সিস্টেমের জন নীতি অনুসরণ করছে। এওএসপি কোনও অ্যাট্রিবিউট (উদাহরণস্বরূপ hal_foo বৈশিষ্ট্য) এর মাধ্যমে বিক্রেতার দ্বারা সরবরাহিত সংস্থানগুলি প্রকাশ করে এটি পরিচালনা করে তবে বৈশিষ্ট্য অংশীদার এক্সটেনশানগুলি system/sepolicy/public সমর্থিত না system/sepolicy/public এই পদ্ধতিটি বিক্রেতা নীতিটির জন্য অনুপলব্ধ। অ্যাক্সেস অবশ্যই পূর্বে বিদ্যমান জনসাধারণের দ্বারা সরবরাহ করা উচিত।

উদাহরণ: একটি সিস্টেম প্রক্রিয়াতে পরিবর্তনের (এওএসপি বা নন-এওএসপি) অবশ্যই নতুন, অ-এওএসপি বিক্রেতার উপাদানটির সাথে এটি কীভাবে যোগাযোগ করে তা পরিবর্তন করতে হবে।

সিস্টেম চিত্রের নীতিটি অবশ্যই নির্দিষ্ট বিক্রেতার কাস্টমাইজেশনের জ্ঞান ছাড়াই লিখতে হবে। এওএসপি-তে নির্দিষ্ট ইন্টারফেস সম্পর্কিত নীতিটি সিস্টেম / সেপোলিসি / পাবলিকের বৈশিষ্ট্যগুলির মাধ্যমে প্রকাশিত হয় যাতে বিক্রেতার নীতি এই বৈশিষ্ট্যগুলি ব্যবহার করে ভবিষ্যতের সিস্টেম নীতিতে বেছে নিতে পারে। তবে, system/sepolicy/public এ্যাট্রিবিউট এক্সটেনশনগুলি সমর্থিত নয় , সুতরাং সিস্টেমের উপাদানগুলি কীভাবে নতুন বিক্রেতার উপাদানগুলির সাথে ইন্টারেক্ট করে (এবং যা ইতিমধ্যে এওএসপি system/sepolicy/public মধ্যে উপস্থিত বৈশিষ্ট্যগুলি দ্বারা পরিচালিত হয় না) অবশ্যই device/ manufacturer / device-name /sepolicy এ থাকতে হবে device/ manufacturer / device-name /sepolicy । এর অর্থ হ'ল কেবলমাত্র ফ্রেমওয়ার্কের ওটিএর অংশ হিসাবে সিস্টেম প্রকারগুলি বিক্রেতার ধরণের অ্যাক্সেস পরিবর্তন করতে পারে না।