This CL is largely an adaptation of Change-Id
I16175933cebd9ec665d190cc5d564b5414a91827 . I also used the same way for
testing the change.
This CL will support the followings.
- installing a RRO package for framework from /product-services/overlay
- installing apps from /product-services/app
- installing priv-apps from /product-services/priv-app
- installing permissions from
/product-services/etc/[default-permissions|permissions|sysconfig]
Bug: 80741439
Test: `mm` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.product_services library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.product_services
=> confirmed that the package is a priv-app
And I moved vendor/overlay/framework-res__auto_generated_rro.apk
into system/product-services/overlay/ on taimen, and I confirmed that the
RRO was installed properly.
Change-Id: I7a6a30bf8e8db9f2738594d187bb9148f138b8da
(cherry picked from commit a4af41736894bd3bf5bdc2a279acbeed2a24dd3d)
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: I4233b9091d9066c4fa69f3d24aaf367ea500f760
This CL will support the followings.
- installing a RRO package for framework from /product/overlay
- installing apps from /product/app
- installing priv-apps from /product/priv-app
- installing permissions from
/product/etc/[default-permissions|permissions|sysconfig]
Bug: 64195575
Test: `mm` under frameworks/base/tests/[libs|privapp]-permissions
adb sync && adb reboot
adb shell cmd package list libraries
=> confirmed com.android.test.libs.product library
adb shell cmd package dump \
com.android.framework.permission.privapp.tests.product
=> confirmed that the package is a priv-app
And I moved vendor/overlay/framework-res__auto_generated_rro.apk into
system/product/overlay/ on sailfish, and I confirmed that the RRO was
installed properly.
Change-Id: I16175933cebd9ec665d190cc5d564b5414a91827
Privileged apps can now be located in the vendor partition. This is
mainly to move SoC-dependent apks to the vendor partition so that the
system partition becomes more generic.
Like existing privileged apps in the system partition, the list of
privileged apps in the vendor partition and the permissions they are
using must be white-listed. The whitelist can be specified via
<privapp-permissions> tags in one of /vendor/etc/permissions/*.xml
files. Note: vendors can only white-list the apps in vendor partition,
but not the apps in system partition.
This change also introduces a new flag 'vendor-privileged' to the
permission protection level. It is used to expose platform-defined
permissions to the privileged vendor apps. If a platform permission does
not have this flag, it is not granted to vendor apps even when the app
is privileged and white-listed.
Bug: 35301609
Test: `mm` under frameworks/base/tests/privapp-permissions
adb sync && adb reboot
adb shell cmd package \
com.android.framework.permission.privapp.tests.vendor
shows that the app is installed.
android.permission.BIND_IMS_SERVICE is in the installed permissions list
android.permission.MANAGE_USE is not in the installed permissions list,
but is in the requested permissions list.
Change-Id: I196375aaaa9ea3a2ba15686ef08cf3f70ade7046
