When the build system flag RELEASE_MOVE_VCN_TO_MAINLINE is true,
VCN framework and service jars will be built into Tethering module.
Otherwise, VCN framework jar will be directly installed on the
device and the service jar will be included into the platform
services.jar
Bug: 375213246
Test: atest CtsVcnTestCases && atest FrameworksVcnTests; verified
with the flag on and off
Flag: RELEASE_MOVE_VCN_TO_MAINLINE
Change-Id: If2651f1ede34220172c419f8bf4afb0fe09c0789
This patch migrates VCN framework code from framework-minus-apex
to framework-connectivity-b, and VCN service code to
service-connectivity-b-pre-jarjar. This patch is part of the work
to move VCN to the Tethering module.
Design doc: go/mainline-vcn-eng-design
Bug: 369703242
Test: FrameworksVcnTests, CtsVcnTestCases, CtsStrictJavaPackagesTestCases
Flag: EXEMPT code refactoring; no functional change
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:5abd00b03916d15495a96b25f17f98e6e9a5317b)
Change-Id: I747556281db2efab7115761147842d241fe283de
Merged-In: I747556281db2efab7115761147842d241fe283de
VCN will be moved to Tetherig module eventually. This patch updates
the VCN flag host container to the module and updates the framework.jar
to access the flags via "exported" mode.
Followup CLs will move VCN to a seperate java_sdk_library and the
aconfig lib will be removed from
framework-minus-apex-aconfig-declarations and moved to that
java_sdk_library. A build system flag will control whether the VCN
will be in platform or the tethering module.
Bug: 376339506
Test: presubmit
Flag: EXEMPT flag container value change
Change-Id: I0434abce40dbadeec20f373f46484c41a08947ff
To mainline VCN, we need to first change the VCN flag host
container to be the tethering module and then use a buid flag to
control whether to include VCN in the non-updatable platform or
the module. After the container changes, when VCN is still in the
platform, the VCN code can only access flags via "exported" mode,
and only API flags are exportable and accessible. Thus the
fix_config_garbage_collection flag needs to be handled
It is safe to clean up this flag because it is a low risk bug fix
and it has been in teamfood for a week with no issue being seen.
Bug: 370862489
Test: FrameworksVcnTests; CtsVcnTestCases
Flag: EXEMPT flag clean up
Change-Id: If38b46735e7b20d918b7483c16b30101416b0a6c
The garbageCollectAndWriteVcnConfigsLocked is for removing
configs whose subgroups do not have any subscriptions. This
patch fixes the issue of it in handling race condition when
subscription changes.
Previously the garbage collection checks a subGroup's
subscriptions based on SubscriptionManager. When
SubscriptionManager and TelephonySubscriptionSnapshot are
out-of-synced, the config of an active VCN instance will be
removed. It can cause NPE in getUnderlyingNetworkPolicy. This
patch fixes it by checking subscriptions against the snapshot.
This patch also fixes the safety check in
getUnderlyingNetworkPolicy so that if VCN instance exists but
its config does not, it will not attempt querying data from
the VcnConfig
Bug: 370862489
Test: FrameworksVcnTests(new tests); CtsVcnTestCases
Flag: android.net.vcn.fix_config_garbage_collection
Change-Id: Id54adabcc1910102a2ab20c432b693a8f52c5c95
Require VCN to be used by a "main user" instead of a "system user"
since "system user" will no longer be a full user on HSUM devices
Bug: 310310661
Test: FrameworksVcnTests, CtsVcnTestCases on non-hsum and hsum devices
Flag: android.net.vcn.enforce_main_user
Change-Id: I5abfa7ba82055cd953083b1ab3f83e61bafd8a55
Set the container field of aconfig flags
Test: printflags --format='{package}:{container}:' | grep "::"
Bug: 312769710
Flag: NONE
Change-Id: I84fda0d5e9813940609436d825738ff786908ff0
Oriol Prieto Gascoauthored and Oriol Prieto Gascócommited 2024-05-03 11:42:54 +00:00
This pacth enables IPsec packet loss detector to handle the case when
there is an intentional sequence number leap on the server's downlink.
Previously the detector assumes that sequence number will always
increase consecutively, which is not true. During load balancing the
server might add a big leap on the sequence number intentionally. In
such case a high packet loss rate does not always indicate a lossy
network. At the same time, a low loss rate does mean the network is
not lossy
Bug: 332598276
Test: atest FrameworksVcnTests (new tests) && atest CtsVcnTestCases
Change-Id: I163cb274d293a305499fd60f7ad6eed394af5a4d
Before calling a flagged API, client code must check the value of the flag
which gates it. Those flags must be exported in order to be accessible from
containers other than the container where the flag and the API are hosted.
Bug: 320984775
Bug: 322839671
Test: m all_aconfig_declarations
Test: printflags --format='{fully_qualified_name}:{is_exported}' | grep true
Change-Id: Ie5af316c327208b52b3afd74502ca66c41bb6f70
This CL creates an abstract class NetworkMetricMonitor and a
subclass IpSecPacketLossDetector. IpSecPacketLossDetector
is responsible for continuously monitoring IPsec packet loss
and reporting to the caller when the data loss rate surpass
a threshold. This detector allows the VCN to switch from
the underlying network that has bad quality.
This CL also defines new carrier configs that specify the
data loss threshold and detecting frequency
Bug: 282996138
Test: atest FrameworksVcnTests(new tests), CtsVcnTestCases
Change-Id: I5f4b8e1821bdbb37f0a6de6e1584f8e3c87273f3
Add aconfig for VCN feature flags and the flag for VCN
safe mode configurability
Bug: 276358140
Test: verified flags are accessible
Change-Id: I4a54445a4238c81a409604be16c90ef341eed638
Merged-In: I4a54445a4238c81a409604be16c90ef341eed638
Yan Yan
commited 
Gerrit Code Review
commited 
Oriol Prieto Gasco
authored and