參考：Google文檔 在 Android 8.0 及更高版本中自定義 SEPolicy

在 Android 源碼的 system/sepolicy 目錄中，區分 public、private 和 vendor 是為了模塊化 SELinux 策略，并明確不同部分的訪問權限和接口邊界。這種設計主要基于以下原因：

---

1. public 目錄

• 目的：定義 公開的 SELinux 策略接口，供其他模塊（如廠商代碼或第三方組件）直接調用。
• 特點：
  • 包含策略中允許外部訪問的類型（type）、屬性（attribute）和接口（interface）。
  • 例如，hal_foo_client 可能被聲明為 public，允許廠商實現的 HAL 服務與之交互。
  • 這些策略是穩定的，Google 會保證其兼容性，避免在 Android 版本升級時破壞依賴它的代碼。

---

2. private 目錄

• 目的：定義 系統內部使用的私有策略，禁止外部模塊直接依賴。
• 特點：
  • 包含僅限 AOSP 系統核心組件（如 system_server、zygote）使用的類型和規則。
  • 例如，system_app 的某些權限可能被標記為 private，禁止廠商應用直接訪問。
  • Google 可能在不同版本中隨時修改這些策略，無需考慮兼容性。

---

3. vendor 目錄

• 目的：為 廠商（OEM/SoC 供應商） 提供擴展策略的入口。
• 特點：
  • 包含廠商自定義的 SELinux 策略（如設備特定的硬件 HAL、內核模塊等）。
  • 允許廠商在 vendor 分區添加自己的策略文件（如 vendor/foo/sepolicy），并通過 vendor 目錄下的規則與 AOSP 策略交互。
  • Google 通過 vendor 目錄明確劃分策略邊界，避免廠商直接修改 AOSP 核心策略。

---

為什么需要這種劃分？

1. 兼容性控制

   • public 策略是穩定的，確保廠商代碼在 Android 版本升級后仍能正常工作。
   • private 策略可以靈活調整，不影響外部模塊。

2. 安全邊界

   • 防止廠商或第三方濫用系統權限（例如，禁止廠商應用訪問 private 的系統服務）。

3. 模塊化設計

   • 分離核心策略（AOSP）和廠商擴展策略，降低耦合性。

---

實際示例

• public/foo.te
  定義 hal_foo_service 類型，并允許廠商 HAL 進程通過 hal_foo_client 訪問它。
• private/system_server.te
  限制只有 system_server 可以訪問某些敏感資源（如 user_data_file）。
• vendor/hal_foo.te
  廠商在此文件中為自家 HAL 實現添加自定義規則。

---

總結

這種劃分是 Android 保護核心系統安全、維護兼容性，同時允許廠商靈活定制的重要設計。開發者需遵守以下原則：

• 如果需要擴展策略，優先使用 public 接口。
• 避免直接依賴 private 內容。
• 廠商自定義策略應放在 vendor 目錄或設備特定的 sepolicy 路徑。