The created handler thread will stay there for a while until
all the tests are finished. This is considered as a leakage
which will take the resource from the devices. In low end
devices, this may possibly impact the performance. The created
threads should be closed explicitly.
Test: atest ConnectivityCoverageTests ConntrackSocketTest
Change-Id: Ic1beb2a210e7c8c80c66fc9e0727c47599150672
Currently, metalava will discard concrete overrides of abstract methods
from the API signature files which causes problems when attempting to
generate stubs from those files and also discards information that may
be important in API reviews. This change is the first step in the
process of changing that behavior.
This change hard codes the current behavior for discarding the concrete
overrides (`add-additional-overrides=no`) into those signature files
that will (or are likely) to be affected by the change in behavior.
That allows the default behavior to be changed for all the other files
without affecting these.
Follow up changes will remove the hard coding from the signature files
and will update the contents which will include the concrete overrides
of the abstract methods.
More information and the background for this change is available at
go/add-overriding-one-pager.
Test: m checkapi
Bug: 299366704
Change-Id: I52c5bbe2e3bbd36019fe44fcb0b2d19876a5a869
After this change, all synchronous state machine functions are
implemented.
There are some intentional limiations:
1. Allow setup states before machine thread started or inside machine
thread but states can only be setup once before calling #start.
2. The behavior of transitionTo is defined so that the destination
state can never change during state transitions. Once a destination
has been specified, it cannot be changed until the previous state
transition is complete. In other words, SyncStateMachine does not
support calling transitionTo in State enter or exit.
3. Support sendSelfMessage in State#processMessage(), #enter() and
#exit(). This allow automaton to decide the follow up action by
itself. For example: if something wrong happens during state
transition, the implementation can enqueue an error message then
process the error message after finishing the current state
transition.
Test: atest SynStateMachineTest
Change-Id: I0790df4eeab2dccdb9f407d9131a62c3c12d123b
Currently, Ipv6UpstreamRule is added follows the adding of
Ipv6DownstreamRule when it is the first rule from a downstream
interface to the upstream interface.
This CL changed it to:
1. Upstream interface change updates both IPv6 upstream and downstream
forwarding rules.
2. Neighbor events updates only IPv6 downstream forwarding rules.
Data limit setting on the upstream interface is now depend on the
upstream rules instead of the downstream rules. This CL also updates
corresponding test cases in IpServerTest and BpfCoordinatorTest.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I5b4df64a3d276afb7a24bbef3a0432f53377e8b2
Implement performTransitions which does state transitions.
1. Determine the common ancestor state of current/destination states
2. Invoke state exit list from current state to common ancestor state.
3. Invoke state enter list from common ancestor state to destState by
going through mEnterStateStack.
The state transition is always defined so that the target can never be
changed mid-way of a state transition. In other words, calling
transitionTo in State enter and exit is not allowed.
Test: atest SyncStateMachineTest
Change-Id: I51e8c5440a8b9ac25715c3d030717421f68c15b3
This change adds SyncStateMachine class and provides the user
interface but doesn't have the details implementation.
Test: m
Change-Id: Ic2fa69b9e6424601fc2df2d07a052f48a6a46370
Found R8 accidentally remove TetheringUtils jni methods while doing
some refactor. If any of jni java methods is removed by R8, devices
would fail to boot because of jni registering failure. Explicitly
adding progurad rule to make sure R8 never remove it.
Test: boot, atest CtsTetheringTest
Change-Id: I091a2f094d01f683fb454ed4624be35555940393
This commit sets up the initial Thread network service for the
Android Thread feature which allows an Android device to create
a Thread network and being a Border Router.
See https://www.threadgroup.org/What-is-Thread for background of
Thread.
See b/235016403 for the Android Thread feature request.
Test: lunch aosp_cf_x86_64_tv-userdebug
m && launch_cvd
atest CtsThreadNetworkTestCases
Bug: 262683651
Change-Id: Ie1bb23084531f67165ec068ea3ca39592dbc01d1
Add end-to-end testing for testing NsdManager advertising and
discovering works fine with downstream tethering interfaces.
Bug: 281639507
Test: atest NsdManagerTest
Change-Id: I5a66423f216cfe0c82db5128502c885980ab264b
ot-daemon is a dependency of the new Thread feature. This commit
add the ot-daemon binary and init rc file to the Tethering module.
Note that the ot-daemon service is default disabled and versioned
init rc file is used to ensure that this service won't be started
before Android U.
This is expected to increase the size of "com.android.tethering.capex"
by around 400 KB.
Manual verification:
1. on Android T (33) CF device, the ot-daemon service is not started
after device boots; It reports service not found error when trying
to start the ot-daemon service with adb shell command "start
ot-daemon"
2. on Android U (34) CF device, the ot-daemon service is not started
after device boots; It can be started with shell comamnd "start
ot-daemon" but then failed because of missing sepolicy rules as
expected
Test: see above manual verification note
Bug: 296211911
Change-Id: I222e2bbcc2ad0be2beec9f5f3406e7144d314370
This CL also updates not to use isTetheringFeatureEnabled for
TETHER_FORCE_UPSTREAM_AUTOMATIC_VERSION which is wrongly configured in
Connectivity namespace.
Test: m
Bug: 279108992
Change-Id: If4f3a57c749bbaeb85454c31248c5bc5feaab936
udc-extended-api directory will be used only in udc mainline branch to
hide @FlaggedApi annotated api which is not supported in that branch
Copied api directories from udc mainline branch.
Bug: 299411828
Test: TH
Change-Id: I86023b1fb3e5f9b4b787a564303e6d2e60f74467
The testLocalOnlyTethering only verifies whether an IPv6 RA
with a ULA prefix is sent out. If the test interface is killed
after the RA is sent out while the DHCP server is starting,
the error callback with exception is raised. RunDhcp
verification is used to ensure that DHCP server is started.
Bug: 286701571
Test: TH
Change-Id: Iccebcedbba7b2f9cd28bb1cc06af928ff8dfaaca
In current code, IpServer will ensure bpf offload is supported before
calling BpfCoordinator's APIs. But those APIs already have the same
checks inside the function. This CL removed duplicated checks in
IpServer.
After this change, the BPF offload support status is only determined
inside BpfCoordinator and it won't change during the life cycle of
Tethering. Tethering initializes mBpfCoordinator just once in the
constructor. After that point, the value of isUsingBpf can never
change, because mIsBpfEnabled is final and
mBpfCoordinatorShim.isInitialized() is either always true (api30) or
can either never change (api31).
Also fixed a bug in IpServerTest upon this change.
Test: atest TetheringTests
Bug: 261923493
Change-Id: I50f231a83bf678b90eae4fd9bfa6035e86978bb3
