เพิ่มพร็อพเพอร์ตี้ของระบบ

หน้านี้มีวิธี Canonical สำหรับการเพิ่มหรือกำหนดพร็อพเพอร์ตี้ของระบบ ใน Android ด้วยหลักเกณฑ์ในการเปลี่ยนโครงสร้างภายในพร็อพเพอร์ตี้ของระบบที่มีอยู่ ตรวจสอบให้แน่ใจว่าคุณใช้หลักเกณฑ์เมื่อคุณเปลี่ยนโครงสร้างภายในโค้ด ยกเว้นในกรณีที่คุณมี ปัญหาความเข้ากันได้ที่เป็นตัวกำหนดเนื้อหาอื่นๆ

ขั้นตอนที่ 1: กำหนดพร็อพเพอร์ตี้ของระบบ

เมื่อเพิ่มพร็อพเพอร์ตี้ของระบบ ให้เลือกชื่อพร็อพเพอร์ตี้และเชื่อมโยงกับบริบทพร็อพเพอร์ตี้ SELinux หากไม่มีบริบทที่เหมาะสม สร้างใหม่ ระบบจะใช้ชื่อเมื่อเข้าถึงพร็อพเพอร์ตี้ ส่วนพร็อพเพอร์ตี้บริบทจะใช้เพื่อควบคุมการเข้าถึงในแง่ของ SELinux ชื่ออาจเป็นสตริงใดก็ได้ แต่ AOSP ขอแนะนำให้คุณใช้รูปแบบที่มีโครงสร้างเพื่อให้ชื่อชัดเจน

ชื่อพร็อพเพอร์ตี้

ใช้รูปแบบนี้กับรูปแบบตัวพิมพ์ snake_case

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

ใช้ "" (ไม่ระบุ), ro (สำหรับพร็อพเพอร์ตี้ที่ตั้งค่าเพียงครั้งเดียว) หรือ persist (สำหรับพร็อพเพอร์ตี้ที่มีค่าเดิมอยู่หลังจากการรีบูต) สำหรับองค์ประกอบ prefix

ข้อจำกัด

ใช้ ro เฉพาะเมื่อคุณแน่ใจว่าไม่จำเป็นต้องเขียน prefix ในอนาคต ** อย่าระบุคำนำหน้า ro** แต่ให้ใช้ sepolicy แทน กำหนดให้ prefix เป็นแบบอ่านอย่างเดียว (กล่าวคือ เขียนได้โดย init เท่านั้น)

ใช้ persist เฉพาะในกรณีที่คุณแน่ใจว่าค่าต้องคงอยู่หลังจากการรีบูต และการใช้พร็อพเพอร์ตี้ของระบบเป็นตัวเลือกเดียวของคุณ

Google จะตรวจสอบพร็อพเพอร์ตี้ของระบบที่มี ro หรือ persist อย่างเคร่งครัด พร็อพเพอร์ตี้

คำว่า group ใช้เพื่อรวบรวมพร็อพเพอร์ตี้ที่เกี่ยวข้อง วัตถุประสงค์ของชื่อนี้คือเพื่อเป็นชื่อระบบย่อยที่ใช้งานคล้ายกับ audio หรือ telephony อย่าใช้คำที่คลุมเครือหรือมีความหมายหลายอย่าง เช่น sys, system, dev, default หรือ config

โดยทั่วไปแล้วมักจะใช้ชื่อประเภทโดเมนของ กระบวนการที่มีสิทธิ์อ่านหรือเขียนพิเศษในคุณสมบัติของระบบ สำหรับ เช่น สำหรับพร็อพเพอร์ตี้ระบบที่กระบวนการ vold มีสิทธิ์เขียน เป็นเรื่องปกติที่จะใช้ vold (ชื่อของประเภทโดเมนสำหรับกระบวนการนี้) เป็น ชื่อกลุ่ม

หากจำเป็น ให้เพิ่ม subgroup เพื่อจัดหมวดหมู่ที่พักเพิ่มเติม แต่ให้หลีกเลี่ยง คำกำกวมหรือมากเกินไปที่จะอธิบายองค์ประกอบนี้ (คุณยังสามารถ มากกว่า 1 subgroup)

มีการกำหนดชื่อกลุ่มไว้แล้วหลายชื่อ ตรวจสอบไฟล์ system/sepolicy/private/property_contexts และใช้ชื่อกลุ่มที่มีอยู่เมื่อเป็นไปได้แทนการสร้างชื่อใหม่ ตารางต่อไปนี้แสดง ตัวอย่างชื่อกลุ่มที่ใช้บ่อย

โดเมน	กลุ่ม (และกลุ่มย่อย)
เกี่ยวกับบลูทูธ	bluetooth
sysprops จากเคอร์เนล cmdline	boot
sysprops ที่ระบุบิลด์	build
เกี่ยวกับโทรศัพท์	telephony
เกี่ยวกับเสียง	audio
เกี่ยวข้องกับกราฟิก	graphics
เกี่ยวข้องกับ vold	vold

ตัวอย่างต่อไปนี้จะกำหนดการใช้ name และ type ในตัวอย่างนิพจน์ทั่วไปก่อนหน้า

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

• name ระบุพร็อพเพอร์ตี้ของระบบภายในกลุ่ม

• type เป็นองค์ประกอบที่ไม่บังคับซึ่งชี้แจงประเภทหรือ Intent ของ พร็อพเพอร์ตี้ของระบบ ตัวอย่างเช่น แทนที่จะตั้งชื่อ sysprop เป็น audio.awesome_feature_enabled หรือเพียง audio.awesome_feature เปลี่ยนชื่อเป็น audio.awesome_feature.enabled เพื่อแสดงประเภทพร็อพเพอร์ตี้ของระบบและ Intent

เราไม่มีข้อกำหนดที่เจาะจงเกี่ยวกับประเภทของไฟล์ ต่อไปนี้เป็นคำแนะนำในการใช้งาน

• enabled: ใช้ในกรณีที่ประเภทเป็นพร็อพเพอร์ตี้ระบบบูลีนที่ใช้เปลี่ยน เปิดหรือปิดฟีเจอร์
• config: ใช้ในกรณีที่ต้องการชี้แจงว่าพร็อพเพอร์ตี้ของระบบไม่ได้แสดงสถานะแบบไดนามิกของระบบ แต่แสดงค่าที่กำหนดค่าไว้ล่วงหน้า (เช่น สิ่งต่างๆ ที่อ่านอย่างเดียว)
• List: ใช้ในกรณีที่เป็นพร็อพเพอร์ตี้ของระบบซึ่งมีค่าเป็นลิสต์
• Timeoutmillis: ใช้ในกรณีที่เป็นพร็อพเพอร์ตี้ของระบบสำหรับค่าระยะหมดเวลาในหน่วย ของมิลลิวินาที

ตัวอย่าง

• 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 ถึง 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 ดูข้อมูลเพิ่มเติมได้ที่property_contexts ในขั้นตอนที่ 3

ขั้นตอนที่ 2: ระบุระดับการช่วยเหลือพิเศษที่จำเป็น

มาโครตัวช่วยที่กําหนดพร็อพเพอร์ตี้มี 4 รายการ

ประเภทการช่วยเหลือพิเศษ	ความหมาย
system_internal_prop	พร็อพเพอร์ตี้ที่ใช้ใน /system เท่านั้น
system_restricted_prop	พร็อพเพอร์ตี้ที่อ่านนอก /system แต่ไม่ได้เขียน
system_vendor_config_prop	พร็อพเพอร์ตี้ที่อ่านนอก /system และเขียนโดย vendor_init เท่านั้น
system_public_prop	พร็อพเพอร์ตี้ที่อ่านและเขียนนอก /system

จำกัดขอบเขตการเข้าถึงพร็อพเพอร์ตี้ของระบบให้แคบที่สุด ที่ผ่านมาการเข้าถึงแบบกว้างส่งผลให้แอปเสียหายและเกิดช่องโหว่ด้านความปลอดภัย พิจารณา คำถามต่อไปนี้เมื่อกำหนดขอบเขต

• พร็อพเพอร์ตี้ระบบนี้ต้องเก็บไว้ไหม (หากใช่ เพราะเหตุใด)
• กระบวนการใดควรมีสิทธิ์อ่านพร็อพเพอร์ตี้นี้
• กระบวนการใดควรมีสิทธิ์เขียนในพร็อพเพอร์ตี้นี้

ใช้คำถามก่อนหน้าและแผนผังการตัดสินใจต่อไปนี้เป็นเครื่องมือสำหรับ กำหนดขอบเขตที่เหมาะสมในการเข้าถึง

รูปที่ 1 แผนผังการตัดสินใจสำหรับการกำหนดขอบเขตการเข้าถึงพร็อพเพอร์ตี้ของระบบ

ขั้นตอนที่ 3: เพิ่มลงใน system/sepolicy

เมื่อเข้าถึง sysprop นั้น SELinux จะควบคุมการเข้าถึงได้ หลังจากกำหนดระดับการเข้าถึงที่จําเป็นแล้ว ให้กําหนดบริบทพร็อพเพอร์ตี้ในส่วน system/sepolicy พร้อมกับกฎ allow และ neverallow เพิ่มเติมเกี่ยวกับสิ่งที่กระบวนการได้รับอนุญาตให้อ่านหรือเขียน (และไม่ได้รับอนุญาตให้อ่านหรือเขียน)

ก่อนอื่น ให้กำหนดบริบทของพร็อพเพอร์ตี้ใน 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)

ประการที่ 2 ให้สิทธิ์การอ่านและ (หรือ) เขียนในบริบทพร็อพเพอร์ตี้ ใช้มาโคร set_prop และ get_prop เพื่อให้สิทธิ์เข้าถึงในไฟล์ system/sepolicy/public/{domain}.te หรือ system/sepolicy/private/{domain}.te ใช้ private เมื่อเป็นไปได้ ส่วน public จะใช้ได้ก็ต่อเมื่อมาโคร set_prop หรือ get_prop ส่งผลต่อโดเมนภายนอกโดเมนหลักเท่านั้น

ตัวอย่างเช่น ในไฟล์ 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)

ข้อ 3 เพิ่มกฎ ไม่อนุญาตบางอย่างเพื่อลดการเข้าใช้งาน ที่กำหนดขอบเขตโดยมาโคร ตัวอย่างเช่น สมมติว่าคุณเคยใช้ system_restricted_prop เนื่องจากผู้ให้บริการต้องอ่านพร็อพเพอร์ตี้ระบบของคุณ กระบวนการ หากกระบวนการของผู้ให้บริการบางรายการไม่จําเป็นต้องใช้สิทธิ์การอ่าน และกระบวนการบางชุดเท่านั้นที่จําเป็นต้องใช้สิทธิ์ดังกล่าว (เช่น vendor_init) ให้ปฏิเสธกระบวนการของผู้ให้บริการที่ไม่จําเป็นต้องใช้สิทธิ์การอ่าน

ใช้ไวยากรณ์ต่อไปนี้เพื่อจำกัดการเข้าถึงการเขียนและการอ่าน

หากต้องการจำกัดการเข้าถึงการเขียน ให้ทำดังนี้

neverallow [domain] [context]:property_service set;

หากต้องการจำกัดการเข้าถึงการอ่าน ให้ทำดังนี้

neverallow [domain] [context]:file no_rw_file_perms;

วางกฎ Neverallow ในไฟล์ system/sepolicy/private/{domain}.te หาก กฎ notallow จะถูกเชื่อมโยงกับโดเมนที่ระบุ สำหรับกฎ 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 สำหรับพร็อพเพอร์ตี้รายการ)

ตรวจสอบว่าทุกรายการมีประเภทที่กําหนดไว้ทุกครั้งที่เป็นไปได้ เนื่องจากระบบจะบังคับใช้ type เมื่อตั้งค่า property ตัวอย่างต่อไปนี้แสดงวิธีเขียนการแมป

# 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 กลายเป็นแบบโมดูล ระบบเสียง Treble ผู้ให้บริการ และพาร์ติชันผลิตภัณฑ์สามารถอัปเดตแยกกันได้ เมื่อใช้ Mainline ระบบปฏิบัติการบางส่วนจะแยกเป็นโมดูลที่อัปเดตได้ (ใน APEX หรือ APK)

เช่น หากพร็อพเพอร์ตี้ของระบบมีไว้สำหรับใช้ในซอฟต์แวร์ส่วนต่างๆ ที่อัปเดตได้ เช่น ข้ามพาร์ติชันของระบบและผู้ให้บริการ ตัวแปรนี้ต้องมีความเสถียร อย่างไรก็ตาม หากมีการใช้ภายใน เช่น โมดูล Mainline ที่เฉพาะเจาะจง คุณจะเปลี่ยนชื่อ ประเภท หรือบริบทพร็อพเพอร์ตี้ของโมดูลนั้น รวมถึงนําออกได้

ถามคําถามต่อไปนี้เพื่อดูความเสถียรของพร็อพเพอร์ตี้ระบบ

• พร็อพเพอร์ตี้ของระบบนี้มีไว้เพื่อกำหนดค่าโดยพาร์ทเนอร์ (หรือกำหนดค่าไว้หรือไม่) แตกต่างกันในแต่ละอุปกรณ์) หากใช่ ไฟล์ต้องเสถียร
• พร็อพเพอร์ตี้ระบบที่ AOSP กำหนดนี้มีไว้เพื่อเขียนหรืออ่านจากโค้ด (ไม่ใช่กระบวนการ) ที่อยู่ในพาร์ติชันที่ไม่ใช่ระบบ เช่น vendor.img หรือ product.img ใช่ไหม หากใช่ ไฟล์ต้องเสถียร
• เข้าถึงพร็อพเพอร์ตี้ของระบบนี้จากโมดูลเมนไลน์หรือข้ามเมนไลน์ และส่วนที่ไม่สามารถอัปเดตได้ของแพลตฟอร์ม หากใช่ ไฟล์ต้องเสถียร

สำหรับพร็อพเพอร์ตี้ของระบบที่เสถียร ให้กำหนดแต่ละรายการเป็น API อย่างเป็นทางการและใช้ API เพื่อเข้าถึงพร็อพเพอร์ตี้ของระบบ ตามที่อธิบายไว้ใน ขั้นตอนที่ 6

ขั้นตอนที่ 5: ตั้งค่าพร็อพเพอร์ตี้ในเวลาบิลด์

ตั้งค่าพร็อพเพอร์ตี้เมื่อสร้างด้วยตัวแปร makefile ในทางเทคนิคแล้ว ค่าต่างๆ จะฝังอยู่ใน {partition}/build.prop จากนั้น init การอ่าน {partition}/build.prop เพื่อตั้งค่าพร็อพเพอร์ตี้ โดยตัวแปรดังกล่าวมี 2 ชุด ได้แก่ PRODUCT_{PARTITION}_PROPERTIES และ TARGET_{PARTITION}_PROP

PRODUCT_{PARTITION}_PROPERTIES มีรายการค่าของพร็อพเพอร์ตี้ ไวยากรณ์คือ {prop}={value} หรือ {prop}?={value}

{prop}={value} เป็นการกำหนดปกติซึ่งช่วยให้มั่นใจว่ามีการตั้งค่า {prop} เป็น {value}; แต่ละพร็อพเพอร์ตี้ 1 รายการใช้การมอบหมายดังกล่าวได้เพียง 1 รายการเท่านั้น

{prop}?={value} เป็นงานที่ไม่บังคับ {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 (โดยทั่วไปคือไฟล์ *.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}

คำสั่ง Shell getprop และ setprop

คุณสามารถใช้คำสั่งเชลล์ getprop หรือ setprop ตามลำดับเพื่ออ่านหรือเขียนพร็อพเพอร์ตี้ ดูรายละเอียดเพิ่มเติมได้ที่ getprop --help หรือ setprop --help

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

Sysprop เป็น API สําหรับ C++/Java/Rust

เมื่อใช้ Sysprop ในฐานะ API คุณจะกำหนดพร็อพเพอร์ตี้ของระบบและใช้ API ที่สร้างขึ้นโดยอัตโนมัติได้ ที่เป็นรูปธรรมและพิมพ์ไป การตั้งค่า scope ด้วย Public ยังสร้าง API ที่พร้อมใช้งานสำหรับโมดูลในทุกขอบเขต และทำให้ API มีความเสถียร ต่อไปนี้เป็นตัวอย่างไฟล์ .sysprop, โมดูล Android.bp และโค้ด C++, Java และ Rust ที่ใช้

# 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);

ดูข้อมูลเพิ่มเติมได้ที่ใช้พร็อพเพอร์ตี้ระบบเป็น API

ฟังก์ชันและวิธีการของพร็อพเพอร์ตี้ระดับ C/C++, Java และ Rust

หากเป็นไปได้ ให้ใช้ Sysprop เป็น API แม้ว่าจะมีฟังก์ชัน C/C++ หรือ Rust ระดับต่ำ หรือเมธอด Java ระดับต่ำก็ตาม

libc, libbase และ libcutils เสนอฟังก์ชันพร็อพเพอร์ตี้ของระบบ C++ libc มี API ที่สำคัญ ขณะที่ฟังก์ชัน libbase และ libcutils Wrapper หากเป็นไปได้ ให้ใช้ฟังก์ชัน libbase sysprop เนื่องจากสะดวกที่สุดและไบนารีของโฮสต์สามารถใช้ฟังก์ชัน libbase ได้ สำหรับข้อมูลเพิ่มเติม ดูรายละเอียดได้ที่ sys/system_properties.h (libc), android-base/properties.h (libbase) และ cutils/properties.h (libcutils)

คลาส android.os.SystemProperties มีเมธอดพร็อพเพอร์ตี้ระบบ Java

โมดูล rustutils::system_properties มีฟังก์ชันและประเภทพร็อพเพอร์ตี้ของระบบ Rust

ภาคผนวก: เพิ่มพร็อพเพอร์ตี้เฉพาะผู้ให้บริการ

พาร์ทเนอร์ (รวมถึง Googler ที่ทำงานในบริบทการพัฒนา Pixel) ต้องการกำหนดพร็อพเพอร์ตี้ของระบบสำหรับฮาร์ดแวร์ (หรืออุปกรณ์) ที่เฉพาะเจาะจง พร็อพเพอร์ตี้เฉพาะผู้ให้บริการคือพร็อพเพอร์ตี้ที่พาร์ทเนอร์เป็นเจ้าของและไม่ซ้ำกัน ฮาร์ดแวร์หรืออุปกรณ์ ไม่ใช่สำหรับแพลตฟอร์ม เนื่องจากเป็นฮาร์ดแวร์หรืออุปกรณ์ แต่มีไว้เพื่อใช้ภายในพาร์ติชัน /vendor หรือ /odm

ตั้งแต่ Project Treble พร็อพเพอร์ตี้แพลตฟอร์มและพร็อพเพอร์ตี้ของผู้ให้บริการได้รับการแยกออกจากกันอย่างสมบูรณ์เพื่อป้องกันไม่ให้ขัดแย้งกัน เนื้อหาต่อไปนี้อธิบายวิธี กำหนดพร็อพเพอร์ตี้ของผู้ให้บริการ และบอกพร็อพเพอร์ตี้ของผู้ให้บริการที่ต้องใช้เสมอ

เนมสเปซในชื่อพร็อพเพอร์ตี้และชื่อบริบท

พร็อพเพอร์ตี้ของผู้ให้บริการทั้งหมดต้องขึ้นต้นด้วยคำนำหน้าอย่างใดอย่างหนึ่งต่อไปนี้เพื่อป้องกันไม่ให้พร็อพเพอร์ตี้ของผู้ให้บริการทับซ้อนกับพร็อพเพอร์ตี้ของพาร์ติชันอื่นๆ

• 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 นอกเหนือจากข้อกำหนดของเนมสเปซของผู้ให้บริการ

กฎ SEPolicy เฉพาะผู้ให้บริการและ property_contexts

มาโคร vendor_internal_prop จะกำหนดพร็อพเพอร์ตี้ผู้ให้บริการได้ ใส่กฎเฉพาะผู้ให้บริการที่คุณกำหนดไว้ในไดเรกทอรี BOARD_VENDOR_SEPOLICY_DIRS ตัวอย่างเช่น สมมติว่าคุณกําลังกําหนดพร็อพเพอร์ตี้ faceauth ของผู้ให้บริการใน Coral

ในไฟล์ 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

ภาคผนวก: เปลี่ยนชื่อพร็อพเพอร์ตี้ที่มีอยู่

เมื่อต้องเลิกใช้งานพร็อพเพอร์ตี้และเปลี่ยนไปใช้พร็อพเพอร์ตี้ใหม่ ให้ใช้ Sysprop เป็น API เพื่อเปลี่ยนชื่อพร็อพเพอร์ตี้ที่มีอยู่ วิธีนี้จะช่วยรักษาความเข้ากันได้แบบย้อนหลังโดยระบุทั้งชื่อเดิมและชื่อพร็อพเพอร์ตี้ใหม่ กล่าวโดยละเอียดคือ คุณสามารถตั้งชื่อเดิมตามช่อง legacy_prop_name ในไฟล์ .sysprop API ที่สร้างขึ้นจะพยายามอ่าน prop_name และใช้ legacy_prop_name หาก ไม่มี 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 ไม่ได้ ตัวอย่างเช่น คุณไม่สามารถเปลี่ยน อุปกรณ์เสริม int เป็นอุปกรณ์ประกอบ string คุณเปลี่ยนแปลงได้เฉพาะชื่อ

• ประการที่ 2 มีเพียง API การอ่านเท่านั้นที่จะใช้ชื่อเดิม Write API ไม่ สำรอง หากเป็น sysprop ที่เขียนได้ คุณจะเปลี่ยนชื่อไม่ได้