Build tethering package which is running the same process as system
server.
Since tethering still have some dependency with system server which
need to run in system server process(e.g. use LocalService), we
need to use InProcessTethering for all first. After cutting off
the dependency, Go devices would keep use "InProcessTethering" and
other non-Go devices would be switched to use "Tethering" package.
Bug: 136040414
Test: -build, flash, boot
Change-Id: I680273a3ee8fed3af843a829da17ca84b130f475
Merged-In: I680273a3ee8fed3af843a829da17ca84b130f475
Migrate PRODUCT_UPDATABLE_BOOT_MODULES &
PRODUCT_UPDATABLE_BOOT_LOCATIONS to a new PRODUCT_UPDATABLE_BOOT_JARS.
This new variable uses the same format as
PRODUCT_UPDATABLE_SYSTEM_SERVER_JARS, i.e <apex>:<jar> pair.
Test: Compiles & flashed device. Ensured that the bootclasspath & system_server class
paths remain the same.
Change-Id: I1cb26d5ec825cd1f5282a6e0255094ddf2fe046a
Originally, GSI forced disable APEX and always contains apex
packages in flattern format. This patch remove the enforcement,
and APEX updateble is enabled according to ro.apex.updatable in
vendor.
Bug: 145245545
Test: build aosp_arm64-userdebug, check the property in system
Change-Id: I9cc943d7b2a30d037a2c1c137dad1233c1e3f57e
Extra VNDKs are now installed under /system_ext in APEX format with
a phony target "vndk_apex_snapshot_package".
There are still files remained in /system/etc(*.libraries.<VER>.txt)
which are installed with "vndk_snapshot_packages".
These files are already packaged into VNDK APEXes, but linkerconfig and
libnativeloader still use them from /system/etc.(b/145184886)
Bug: 137802149
Test: lunch aosp_arm64
&& flash system.img on Q device
&& boot
Change-Id: I94c340d6f1c1af6ab1ae93c22b0a98fd4c10262e
Allow system_server jars delivered via apex. Regular system_server
jars are located in /system/framework folder. But, jars delivered via
apex are mounted at /apex/<module_name>/javalib. Also, not all the
libraries in /apex/<module_name>/javalib will be a system_server jar,
so adding a mechanism to list out the jar file explicitly within the
apex module.
Bug: 144722612
Bug: 141785760
Test: Compiles (both with empty & non-empty PRODUCT_SYSTEM_SERVER_APEX_JARS
value set)
Change-Id: Ia181ab22fdf2da575bfd532c1cd90a2f54742528
IKE will be a mainline module. This commit adds ike.jar to
bootpathclass so that IKE API is accessible to apps.
Bug: 143983419
Test: make update-api && make
Change-Id: I1dbb249f3109f45ce32c34bcb398108d61bc06cc
com.android.ipsec will be shipped as a mainline
module in APEX format
Bug: 143905344
Test: Built and installed apex on device
Change-Id: I70da069146e8d9a7be38ab603c6bdaa9d6d9ba84
Make aosp targets inherit handheld_system_ext.mk and
telephony_system_ext.mk files.
Devices that have /system_ext or /system/system_ext must inherit any
of *_system_ext.mk files to install mandatory packages for system_ext
partition.
Bug: 144542478
Test: Build aosp targets
Change-Id: Ibdbf0000ac4aa98c8485d67827f52208f9a827c5
Necessary after moving it into the Runtime APEX, as several framework
libraries loaded during early boot depends on it, e.g. libvndksupport.so,
libvulkan.so, and libgraphicsenv.so.
Test: build & boot
Bug: 135753770
Bug: 144343305
Change-Id: Ia95349e377605d709fae74d966bd4f2324eaf604
Since /persist is a SoC specfic symlink, it must not be included in
the root directory. For this reason, we already moved the directory
under /mnt/vendor. However, there are still many modules that are
using the old path /persist.
Until we clear all these violations, we need to have the symlink in
the root directory.
Bug: 143732851
Test: build and check boot and basic functions
Change-Id: Iaee28ba29f79f1c286e090f97173e3196d2fc823
Test: push V6 to device and check audio works fine
Bug: 134940862
Change-Id: I761d05708d99287b9fe255c55724f92c8a3388e7
Merged-In: I761d05708d99287b9fe255c55724f92c8a3388e7
Signed-off-by: Kevin Rocard <krocard@google.com>
There is no reason for these scripts to continue to exist in /, when
they are better suited for /system/etc. There are problems keeping
them at / as well, particularly that they cannot be updated with
overlayfs.
Bug: 131087886
Bug: 140313207
Test: build/boot
Merged-In: I5aa0332e7f0e3fb6840b60e3d099c2b28d38b7ea
Change-Id: I5aa0332e7f0e3fb6840b60e3d099c2b28d38b7ea
Necessary after moving it into the Runtime APEX, as several framework
libraries loaded during early boot depends on it, e.g. libvndksupport.so,
libvulkan.so, and libgraphicsenv.so.
Test: build & boot
Bug: 135753770
Change-Id: I5862ba57485bdaffd452aac47c5931863823075d
NetworkStackNext is the build of the network stack targeted at the
next API, e.g. system_current and not system_29.
While NetworkStack is a mainline module that needs to be built with a
stable SDK (system_29), NetworkStackNext is necessary to test
functionalities that require the in-development SDK (system_current).
Using NetworkStackNext preinstalled on development builds allows for
testing the new APIs and functionalities.
NetworkStackNext is also configured with a mainline module package name
on targets that use mainline modules; but it is not intended to receive
mainline updates.
Once system_current is finalized (system_30 ?), NetworkStack can start
using it, and the system image should switch back to NetworkStack
instead of NetworkStackNext.
Bug: 139269711
Test: Built, phone boots, WiFi working
Change-Id: I885b2c441b99daa3165a4a365738682958478291
Bug: 135956699
Test: m -j30 (verify that build includes CellBroadcastServiceModule)
Change-Id: Ib2d734ba2ed3608a4255164e6e50dac349eb9a18
Merged-In: Ib2d734ba2ed3608a4255164e6e50dac349eb9a18
