This works around a build-system limitation where it does not know
which jars to feed r8 to resolve all classes during proguarding.
Bug: 160453030
Bug: 169931783
Test: build_mainline_modules.sh (with prebuilt sdk)
Change-Id: I3d9f2049cf898b5e551a5c5764df423abaa5e92d
Merged-In: I3d9f2049cf898b5e551a5c5764df423abaa5e92d
This package is using some common utilities from
a library that used to live in the network stack.
A better home for these utilities is frameworks/libs,
so this topic moves the files ther and also changes
the package of some utilities.
See aosp/1350222 and aosp/1350182 for a detailed
description of the specific files that moved.
Test: checkbuild
Change-Id: I76a9b7790f3997e3e6b3c2f75ba6308286457cde
Development branches should use the -unstable version of the
NetworkStack AIDLs so that refreezing is not necessary for each
modification.
The versions will be re-frozen before each release instead.
Bug: 157534516
Test: m
Merged-In: I74b4a16266bda7b8ac740b3a0193268da260fc2f
Change-Id: I1c2fe707d865e6a1953b4ab82194d4b9132258f9
Tethering package.
Tethering needs StatsEvent and StatsLog which are in
framework-statsd.stubs.module_lib to write metrics.
Bug: 153942334
Test: make
Change-Id: I8ba142a9b3678de36e6c4880a64e992e00680f38
Development branches should use the -unstable version of the
NetworkStack AIDLs so that refreezing is not necessary for each
modification.
The versions will be re-frozen before each release instead.
Bug: 157534516
Change-Id: I74b4a16266bda7b8ac740b3a0193268da260fc2f
Test: m
This is required to use the new BPF tethering APIs that set data
usage limits.
AOSP and master are already using -unstable instead of -V3.
In order not to change master, the Merged-In tag is set to the CL
that switched AOSP (and master) to -unstable.
Test: m
Bug: 150736748
Merged-In: I2d2cedf560319653f67f6b06f7abb0bf66eba91a
Change-Id: Idba29b0fe428ac6552a025dcbe15729739088e9e
Removes use of the special framework-modules naming scheme.
Bug: 155164730
Test: m java
Exempt-From-Owner-Approval: Build cleanup.
Change-Id: I3b78fcbcacc3df787e171d6eedeef1e51b087615
Merged-In: I0c31e2183353dfb5bd49f04f3455cb7b10be6866
(cherry picked from 8b864fb45ce79051437f13c2a19510718ea3b7aa)
Use unstable aidl for new api tetherOffload* and modified
parcel TetherStatsParcel in BpfCoordinator{, Test}.
Bug: 150736748
Test: m
Change-Id: I2d2cedf560319653f67f6b06f7abb0bf66eba91a
The names of the individual modules do not quite follow the pattern
that java_sdk_library uses so this temporarily sets the following:
naming_scheme: "frameworks-modules"
That causes java_sdk_library to use a naming scheme that matches the
one used by the individual modules of this. It will be cleaned up
later.
Part of the purpose of the java_sdk_library is to hide the
implementation code and force users of the library to depend on stubs
for a well defined API. Ideally, it would allow access to the
implementation in those cases where it is safe, e.g. from within the
same APEX, or from tests for the implementation. Unfortunately, due to
limitations in the build it does not yet have enough information to
make that decision correctly which means that any code that needs to
compile against the implementation is broken which would prevent us
from converting the module to java_sdk_library.
However, the only way to provide the additional information to allow
the implementation to be correctly exposed is to convert the modules
to java_sdk_library; a cycle.
In order to break that cycle the java_sdk_library creates a special
<module>.impl target which is used directly by tests and any other code
that needs it. Once all the modules have been converted to a
java_sdk_library then we can resolve the limitations in the build and
remove the direct references to <module>.impl.
Test: m update-api
Bug: 155164730
Merged-In: If5c115f482751f9f4b5f047e9e401a18e36799ef
Merged-In: Id1c2e848430c49a2da7402244814cd084f5da77c
Change-Id: Id1c2e848430c49a2da7402244814cd084f5da77c
The names of the individual modules do not quite follow the pattern
that java_sdk_library uses so this temporarily sets the following:
naming_scheme: "frameworks-modules"
That causes java_sdk_library to use a naming scheme that matches the
one used by the individual modules of this. It will be cleaned up
later.
Part of the purpose of the java_sdk_library is to hide the
implementation code and force users of the library to depend on stubs
for a well defined API. Ideally, it would allow access to the
implementation in those cases where it is safe, e.g. from within the
same APEX, or from tests for the implementation. Unfortunately, due to
limitations in the build it does not yet have enough information to
make that decision correctly which means that any code that needs to
compile against the implementation is broken which would prevent us
from converting the module to java_sdk_library.
However, the only way to provide the additional information to allow
the implementation to be correctly exposed is to convert the modules
to java_sdk_library; a cycle.
In order to break that cycle the java_sdk_library creates a special
<module>.impl target which is used directly by tests and any other code
that needs it. Once all the modules have been converted to a
java_sdk_library then we can resolve the limitations in the build and
remove the direct references to <module>.impl.
Test: m Tethering InProcessTethering checkapi
Bug: 155164730
Merged-In: If5c115f482751f9f4b5f047e9e401a18e36799ef
Change-Id: Id1c2e848430c49a2da7402244814cd084f5da77c
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
InProcessTethering is a part of com.android.tethering.inprocess,
therefore min_sdk_version is set.
Exempt-From-Owner-Approval: CP from AOSP
Bug: 145796956
Bug: 150999716
Test: m
Merged-In: I655211e0b9aa4bd7cb3718b6f567f0aa1a0176a5
Change-Id: I655211e0b9aa4bd7cb3718b6f567f0aa1a0176a5
(cherry picked from commit ace605ef568fecfe148d2785f4681c9c858487aa)
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 145796956
Bug: 150999716
Test: m
Merged-In: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
Change-Id: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
(cherry picked from commit 33aa294e96f13906f596e427b96652fe80cf199b)
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
InProcessTethering is a part of com.android.tethering.inprocess,
therefore min_sdk_version is set.
Bug: 145796956
Bug: 150999716
Test: m
Change-Id: I655211e0b9aa4bd7cb3718b6f567f0aa1a0176a5
Modules contributing mainline modules (APK/APEX) should set
min_sdk_version as well as apex_available.
For now setting min_sdk_version doesn't change build outputs.
But build-time checks will be added soon.
Bug: 145796956
Bug: 150999716
Test: m
Change-Id: Ifaecb49a47a1f43edea3ea06e1cf704a177d1044
Since it's not used for now.
Test: TH
Bug: 153304048
Merged-in: I1812818c3d49463c3840a98212bbab58a110359a
Change-Id: I1812818c3d49463c3840a98212bbab58a110359a
Link against the stubs of other modules and the implementation
of the tethering module jar.
Bug: 146757305
Test: m Tethering
Change-Id: I7c93b60654e21a4a27d21cbf0c2a6cb21f813529
Merged-In: I7c93b60654e21a4a27d21cbf0c2a6cb21f813529
(cherry picked from commit aaeaa195b8)
Link against the stubs of other modules and the implementation
of the tethering module jar.
Bug: 146757305
Test: m Tethering
Change-Id: I7c93b60654e21a4a27d21cbf0c2a6cb21f813529
The build system collects transtive deps from jni_libs for APKs.
No need to list them explicitly in android_app definition.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
unzip apex/priv-app/Tethering/Tethering.apk -u apk
ls apk/lib/arm64-v8a
Merged-In: Icba6ea3611c443cbf22ad6363d0239377d16ac9e
Change-Id: Icba6ea3611c443cbf22ad6363d0239377d16ac9e
(cherry picked from commit 9618b66f285ad5baa50b004b788d60272958a04d)
The build system collects transtive deps from jni_libs for APKs.
No need to list them explicitly in android_app definition.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
unzip apex/priv-app/Tethering/Tethering.apk -u apk
ls apk/lib/arm64-v8a
Change-Id: Icba6ea3611c443cbf22ad6363d0239377d16ac9e
Tethering's JNI libraries use the NDK version of liblog, it should
not package the platform version of liblog into the APK.
Bug: 149591340
Test: m checkbuild
Change-Id: If208c1078d2755907f57d7853a5c545bf12458c2
The callbacks are fired when the list of connected clients or their IP
addresses / hostname change.
Test: flashed, connected 2 devices, verified callbacks
Test: atest TetheringTests
Bug: 135411507
Change-Id: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Merged-In: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Annotations such as @SystemApi cannot be jarjared to a different
package, as the members would not match the system API declarations.
Instead, only build against the annotations from
framework-annotations-lib, but do not include them as classes in the
output jar; annotations are not required to be available to the
classloader at runtime.
Test: builds, boots, tethering working
Bug: 147812912
Fixes: 148609988
Change-Id: I1fae97a1c1e0ba07fa3e2d64cde7650cd26d0acd
Merged-In: I1fae97a1c1e0ba07fa3e2d64cde7650cd26d0acd
The callbacks are fired when the list of connected clients or their IP
addresses / hostname change.
Test: flashed, connected 2 devices, verified callbacks
Test: atest TetheringTests
Bug: 135411507
Change-Id: I96291038cf7b39a67547a5f74fcd7cbedc1ca002
Annotations such as @SystemApi cannot be jarjared to a different
package, as the members would not match the system API declarations.
Instead, only build against the annotations from
framework-annotations-lib, but do not include them as classes in the
output jar; annotations are not required to be available to the
classloader at runtime.
Test: builds, boots, tethering working
Bug: 147812912
Fixes: 148609988
Change-Id: I1fae97a1c1e0ba07fa3e2d64cde7650cd26d0acd
TetheringUtil JNI is too big that it statically linking hidl and its
dependency library. To remove these static libraries, calling hidl in java
directly instead of using JNI.
Bug: 148984662
Test: -build, flash, boot
-manually ON/OFF tethering
Change-Id: Id5a9759eb453fddaf0c3b7a31da17224e35e963e
This library is empty, and its functionality has moved
into libbinder/libhwbinder.
Bug: 148692216
Test: N/A
Change-Id: I3ee973cef68281cb57b4912b4b66c798b5d9d715
This is used to generate java APIs used by tethering module
Bug: 145490751
Test: m com.android.tethering RUN_ERROR_PRONE=true
Change-Id: I97c26e3dcdf4f4c5017f1df582a16335c613f8dd
The non-updatable part of the platform shouldn't directly link to the
boot jars in APEXes. Ensure this by
1) setting the visibility property for the boot jars so that they are
not visible to non-APEX modules and
2) setting the apex_available property so that the boot jars are only
built for the corresponding APEXes, but not for others.
Bug: b/146167933
Bug: b/146218515
Bug: b/147200698
Test: m
Change-Id: I251fabd773bc31f46d572d143c72dd9162f3f0a6
Merged-In: I251fabd773bc31f46d572d143c72dd9162f3f0a6
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Merged-In: I288969b0c22fa3a63bc2e71bb5009fe4a927e154