一、先看兩組代碼的直觀區別

Android 14方案（PRODUCT_COPY_FILES）：

核心邏輯：直接把文件從源碼目錄拷貝到系統分區（如/system/bin），像“復制粘貼”一樣簡單。

Android 15方案（PRODUCT_PACKAGES）：

核心邏輯：先通過Android.bp定義“模塊”（如canconfig是一個預構建可執行程序模塊），再把模塊名加入打包清單，由構建系統統一管理。

終端路徑：

二、為什么Android 15要“淘汰”直接拷貝？

這不是“功能刪減”，而是Android系統安全、構建效率、硬件適配三重進化的必然結果：

1.安全升級：從“放養”到“強監管”

?Android 14時代：直接拷貝文件，系統不會校驗“這個程序能不能在設備上運行”（比如x86程序拷貝到ARM設備），也不管“程序有沒有危險權限”（比如偷偷讀寫系統文件）。

?Android 15時代：強制要求模塊化聲明，構建系統會自動檢查：

?架構兼容性：程序必須是設備支持的架構（如RK3576的arm64）；

?權限合法性：通過SELinux上下文配置，限制程序能做什么（比如只允許訪問串口）；

?依賴完整性：如果程序依賴其他庫（如libcan.so），必須明確聲明，否則編譯報錯。

2.構建系統進化：Soong取代傳統Make

Android 15全面擁抱Soong構建系統（用Android.bp替代Android.mk），它像“智能管家”：

?傳統方式（PRODUCT_COPY_FILES）：只管拷貝，不管“程序是否能運行”“依賴是否完整”，出問題全靠開發者人肉排查；

?模塊方式（PRODUCT_PACKAGES）：通過cc_prebuilt_binary等規則，自動處理權限、依賴、架構問題，甚至能幫你發現“程序是x86格式，設備是arm64”這種低級錯誤。

3.硬件適配：瑞芯微等芯片廠商的倒逼

以瑞芯微RK3576為例：

?芯片的ISP、串口、攝像頭等硬件，對驅動和工具的依賴管理要求更嚴格；

?直接拷貝的程序，可能因“沒加載依賴庫”“權限不夠”導致硬件功能失效；

?模塊化聲明能強制關聯驅動、庫、權限，確保硬件功能正常工作。

三、開發者必須注意的3個核心點

1.必須學會寫Android.bp（模塊聲明）

以cansend為例，需在同級目錄創建Android.bp：

?關鍵作用：告訴構建系統“這個程序是誰、能裝在哪、該有什么權限”。

2.SELinux配置是“必答題”

Android 15的SELinux會嚴格攔截未授權操作，必須為程序配置上下文：

?若程序要訪問串口（如/dev/ttyS8），還需額外添加SELinux策略（如allow cansend serial_device:chr_file write;），否則會報avc: denied錯誤。

3.動態庫依賴要“明明白白”

如果cansend依賴libcan.so，不能只拷貝cansend，還需：

1.用cc_prebuilt_library_shared聲明libcan.so模塊；

2.在cansend的Android.bp中通過shared_libs關聯：

?否則設備運行時會報錯cannot load library: libcan.so。

四、實戰建議：從Android 14遷移到15的步驟

1.整理可執行程序：把canconfig、candump等程序放到統一目錄（如device/rockchip/cantools）。

2.為每個程序寫Android.bp：按模塊規則聲明，配置架構、權限、SELinux。

3.修改PRODUCT_PACKAGES：替換原來的文件路徑，改為模塊名。

4.編譯驗證：

若報錯，優先檢查架構是否匹配、SELinux策略是否缺失、依賴是否聲明。

結語：系統越嚴，開發越規范

Android 15對可執行程序的“模塊化”要求，本質是系統安全和開發效率的雙向奔赴：

?對用戶：避免非法程序破壞系統；

?對開發者：減少“運行時崩潰”的Debug成本。

跟上這個變化，你會發現：曾經的“野路子”雖然快，但“正規軍”的方式更穩、更可持續。

（覺得有用？歡迎轉發給需要適配Android 15的同行～）