הוספת מאפייני מערכת

בדף הזה מפורטת שיטה קנונית להוספה או להגדרה של מאפייני מערכת ב-Android, עם הנחיות לשיפור מבנה של מאפייני מערכת קיימים. חשוב להשתמש בהנחיות כשמבצעים רפאקציה, אלא אם יש בעיית תאימות משמעותית שמחייבת אחרת.

שלב 1: מגדירים את מאפיין המערכת

כשמוסיפים מאפיין מערכת, צריך לבחור שם למאפיין ולשייך אותו להקשר של מאפיין SELinux. אם אין הקשר קיים מתאים, צריך ליצור הקשר חדש. משתמשים בשם הזה כשניגשים לנכס. ההקשר של המאפיין משמש לשליטה בנגישות במונחים של SELinux. השמות יכולים להיות כל מחרוזת, אבל AOSP ממליץ להשתמש בפורמט מובנה כדי שיהיה ברור.

שם המאפיין

צריך להשתמש בפורמט הזה עם אותיות רישיות ב-snake_case:

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

עבור האלמנט prefix, אפשר להשתמש ב-"" (לא מצוין), ב-ro (לנכסים שמוגדרים רק פעם אחת) או ב-persist (לנכסים שנשמרים אחרי הפעלות מחדש).

נקודות שצריך לשים לב אליהן:

צריך להשתמש ב-ro רק אם אתם בטוחים שלא תצטרכו לכתוב ב-prefix בעתיד. ** לא מציינים את הקידומת ro.** במקום זאת, אפשר להשתמש ב-sepolicy כדי להגדיר את prefix כקובץ לקריאה בלבד (כלומר, רק init יכול לכתוב בו).

משתמשים ב-persist רק אם אתם בטוחים שהערך צריך להישמר אחרי הפעלות מחדש, וששימוש במאפייני המערכת הוא האפשרות היחידה שלכם.

Google בודקת בקפידה את מאפייני המערכת שיש להם מאפייני ro או persist.

המונח group משמש לצבירת נכסים קשורים. הוא מיועד להיות שם של מערכת משנה שדומה לשמות של audio או telephony. אסור להשתמש במונחים לא ברורים או עמוסים מדי, כמו sys, system, dev, default או config.

נהוג להשתמש בשם של סוג הדומיין של תהליך שיש לו גישה בלעדית לקריאה או לכתיבה למאפייני המערכת. לדוגמה, במאפייני המערכת שבהם יש לתהליך vold גישת כתיבה, מקובל להשתמש ב-vold (השם של סוג הדומיין של התהליך) בתור שם הקבוצה.

אם צריך, מוסיפים את subgroup כדי לסווג את הנכסים לקטגוריות נוספות, אבל כדאי להימנע משימוש במונחים לא ברורים או עמוסים מדי כדי לתאר את הרכיב הזה. (אפשר גם להגדיר יותר מ-subgroup אחד).

שמות רבים של קבוצות כבר הוגדרו. בודקים את הקובץ system/sepolicy/private/property_contexts ומשתמשים בשמות של קבוצות קיימות כשהדבר אפשרי, במקום ליצור שמות חדשים. בטבלה הבאה מפורטות דוגמאות לשמות של קבוצות נפוצות.

דומיין קבוצה (וקבוצת משנה)
קשור ל-Bluetooth bluetooth
sysprops מ-cmdline של הליבה boot
sysprops שמזהים build build
קשור לטלפוניה telephony
קשור לאודיו audio
קשורים לגרפיקה graphics
קשור ל-vold 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: יש להשתמש אם זהו מאפיין מערכת של ערך של זמן קצוב לתפוגה ביחידות של אלפיות השנייה.

לדוגמה:

  • 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 לציון True, false או 0 ל-False
מספר שלם מספר שלם בסימן של 64 ביט
מספר שלם ללא סימן מספר שלם ללא סימן ב-64 ביט
כפול נקודה צפה (floating-point) בעלת דיוק כפול
מחרוזת כל מחרוזת UTF-8 חוקית
טיפוסים בני מנייה (enum) הערכים יכולים להיות כל מחרוזת UTF-8 תקינה ללא רווחים לבנים
רשימה של האפשרויות שלמעלה פסיק (,) משמש כמפריד
רשימת המספרים השלמים [1, 2, 3] מאוחסנת כ-1,2,3

באופן פנימי, כל המאפיינים מאוחסנים כמחרוזות. כדי לאכוף את הסוג, צריך לציין אותו כקובץ property_contexts. מידע נוסף זמין בקטע property_contexts בשלב 3.

שלב 2: קובעים את רמות הנגישות הנדרשות

יש ארבעה מאקרו-עזר שמגדירים נכס.

סוג הנגישות משמעות
system_internal_prop מאפיינים שנעשה בהם שימוש רק ב-/system
system_restricted_prop מאפיינים שנקראים מחוץ ל-/system, אבל לא כתובים
system_vendor_config_prop מאפיינים שנקראו מחוץ ל-/system ונכתבו רק על ידי vendor_init
system_public_prop מאפיינים שקוראים להם ומשתמשים בהם מחוץ ל-/system

כדאי לצמצם את היקף הגישה לנכסי המערכת ככל האפשר. בעבר, גישה רחבה גרמה לשיבושים באפליקציות ולנקודות חולשה באבטחה. כשמגדירים את ההיקף, כדאי להביא בחשבון את השאלות הבאות:

  • האם צריך לשמור את מאפיין המערכת הזה? (אם כן, למה?)
  • לאיזה תהליך צריכה להיות גישה לקריאה לנכס הזה?
  • לאיזה תהליך צריכה להיות הרשאת כתיבה לנכס הזה?

אתם יכולים להשתמש בשאלות שלמעלה ובעץ ההחלטות הבא כדי לקבוע את היקף הגישה המתאים.

עץ החלטות שנועד לקבוע את היקף הגישה

איור 1. עץ החלטות שנועד לקבוע את היקף הגישה למאפייני המערכת

שלב 3: הוספה לקובץ system/sepolicy

בעת גישה ל-syspro, SELinux שולט בנגישות של תהליכים. אחרי שקובעים את רמת הנגישות הנדרשת, מגדירים הקשרים בנכס בקטע system/sepolicy, יחד עם כללי Allow ואף פעם נוספים לגבי קריאה או כתיבה של תהליכים.

קודם כול, מגדירים את ההקשר של הנכס בקובץ 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)

שנית, צריך להעניק גישה לקריאה ו (או) לכתיבה להקשר של הנכס. משתמשים בפקודות המאקרו 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)

שלישית, מוסיפים כמה כללי 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.

לבסוף, משייכים נכס מערכת להקשר של הנכס. כך מוודאים שהגישה שמוענקת וכללי neverallow שחלים על הקשרי הנכסים חלים על הנכסים בפועל. כדי לעשות זאת, מוסיפים רשומה לקובץ 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 הופכת למבוססת-מודולים. באמצעות טרבל אפשר לעדכן את מחיצות המערכת, הספק והמוצרים בנפרד. ב-Mainline, חלקים מסוימים של מערכת ההפעלה מחולקים למודולים שניתן לעדכן (ב-APEX או ב-APK).

אם מאפיין מערכת מיועד לשימוש בחלקים שונים של תוכנה שניתן לעדכן, למשל במחיצות של מערכת ושל ספק, הוא חייב להיות יציב. עם זאת, אם הוא משמש רק בתוך, למשל, מודול Mainline ספציפי, אפשר לשנות את השם, הסוג או ההקשרים של הנכס שלו, ואפילו להסיר אותו.

כדי לקבוע את היציבות של נכס מערכת, צריך לשאול את השאלות הבאות:

  • האם שותפים אמורים להגדיר את מאפיין המערכת הזה (או להגדיר אותו באופן שונה לכל מכשיר)? אם כן, היא צריכה להיות יציבה.
  • האם מאפיין המערכת הזה שמוגדר ב-AOSP מיועד לכתיבה או לקריאה מקוד (לא מתהליך) שנמצא במחיצות שאינן של המערכת, כמו vendor.img או product.img? אם כן, הוא חייב להיות יציב.
  • האם מתבצעת גישה לנכס המערכת הזה דרך מודולים של Minline או דרך מודול ראשי ושל החלק שלא ניתן לעדכון? אם כן, הוא חייב להיות יציב.

בשביל מאפייני המערכת היציבים צריך להגדיר באופן רשמי כל אחד מהם כ-API ולהשתמש ב-API כדי לגשת למאפיין המערכת, כפי שמוסבר בשלב 6.

שלב 5: הגדרת מאפיינים בזמן ה-build

הגדרת מאפיינים בזמן ה-build באמצעות משתני makefile. מבחינה טכנית, הערכים מובנים ב-{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} מוגדר ל-{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}

פקודות shell של getprop ו-setprop

אפשר להשתמש בפקודות המעטפת getprop או setprop, בהתאמה, כדי לקרוא או לכתוב את המאפיינים. לפרטים נוספים, אפשר להפעיל את getprop --help או את setprop --help.

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

Syspro כ-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. אם אפשר, כדאי להשתמש בפונקציות sysprop של libbase. הן הכי נוחות, וקבצים בינאריים של המארח יכולים להשתמש בפונקציות libbase. למידע נוסף, אפשר לעיין במאמרים sys/system_properties.h (libc), android-base/properties.h (libbase) ו-cutils/properties.h (libcutils).

המחלקה android.os.SystemProperties כוללת שיטות של מאפייני מערכת Java.

המודול rustutils::system_properties כולל פונקציות וסוגים של מאפייני מערכת Rust.

נספח: הוספת נכסים ספציפיים לספק

שותפים (כולל גוגלרים שעובדים בהקשר של פיתוח 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 as APIs כדי לשנות את השם של הנכסים הקיימים. כך אפשר לשמור על תאימות לאחור, על ידי ציון השם הקודם וגם השם החדש של הנכס. באופן ספציפי, אפשר להגדיר את השם מהדור הקודם באמצעות השדה 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. אפשר לשנות רק את השם.

  • שנית, רק ה-API לקריאה חוזר לשם הקודם. ממשק ה-API לכתיבה לא עובר לחלופה. אם ה-syspro ניתן לכתיבה, לא ניתן לשנות את שמו.