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

หน้านี้แสดงวิธีการมาตรฐานในการเพิ่มหรือกําหนดพร็อพเพอร์ตี้ของระบบใน 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 เพื่อจัดหมวดหมู่พร็อพเพอร์ตี้เพิ่มเติม แต่หลีกเลี่ยงการใช้คําที่คลุมเครือหรือมีความหมายหลายอย่างในการอธิบายองค์ประกอบนี้ (คุณมี subgroup ได้มากกว่า 1 รายการ)

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

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

ตัวอย่างต่อไปนี้จะกำหนดการใช้ 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 แทน 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 ให้เพิ่มกฎ "neverallow" บางรายการเพื่อลดการช่วยเหลือพิเศษที่แมโครกําหนดขอบเขตไว้ ตัวอย่างเช่น สมมติว่าคุณใช้ 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 หากกฎ 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 สำหรับรายการพร็อพเพอร์ตี้)

ตรวจสอบว่าทุกรายการมีประเภทที่กําหนดไว้ทุกครั้งที่เป็นไปได้ เนื่องจากระบบจะบังคับใช้ 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 ใช่ไหม หากมี การเชื่อมต่อต้องเสถียร
  • พร็อพเพอร์ตี้ระบบนี้เข้าถึงได้ผ่านโมดูล Mainline หรือผ่านโมดูล Mainline และส่วนที่อัปเดตไม่ได้ของแพลตฟอร์ม หากใช่ ไฟล์ต้องเสถียร

สําหรับพร็อพเพอร์ตี้ของระบบที่เสถียร ให้กําหนดแต่ละรายการเป็น 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} โดยคุณกําหนดค่าดังกล่าวได้เพียงรายการเดียวต่อพร็อพเพอร์ตี้เดียว

{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: เข้าถึงพร็อพเพอร์ตี้ขณะรันไทม์

อ่านและเขียนพร็อพเพอร์ตี้ได้เมื่อรันไทม์

สคริปต์เริ่มต้น

ไฟล์สคริปต์เริ่มต้น (โดยปกติคือไฟล์ *.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 ใน Shell

คุณสามารถใช้คำสั่งเชลล์ 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 ของผู้ให้บริการในปะการัง

ในไฟล์ 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 การอ่านเท่านั้นที่จะใช้ชื่อเดิม แต่ API การเขียนจะไม่ใช้การสำรอง หากเป็น sysprop ที่เขียนได้ คุณจะเปลี่ยนชื่อไม่ได้