In current design, the interface will be removed from the list if
the network disconnected which will cause getUidStatsForTransport()
returns unexpected snapshot to caller since the list is empty.
This change also remove interface name from all entries before
the method returns the result.
Ignore-AOSP-First: non-AOSP CL is included in the same topic
Bug: 231514741
Test: FrameworksNetTests
manual test
Change-Id: Ie60829a65d0d9b5b63ad353695a820c0586e3665
NsdManager callbacks were run on a provided executor by capturing the
handler message in a lambda, but the message will be recycled
immediately after handleMessage returns. This means that any non-inline
executor would see bogus callbacks, as they have an empty Message. Fix
it by not capturing the Message in the lambda, but capturing its
contents instead.
This was broken when updating the class to support executors in change
ID: I4c31e2d7ae601ea808b1fd64df32d116c6fff97f; before that, callbacks
were all run on the NsdManager handler.
Also, DelegatingDiscoveryListener is being run on the NsdManager handler
thread for notifyAllServicesLost, causing onServiceLost to be run there,
but other methods are run on the provided Executor, even though they
access maps maintained on the handler thread, like mPerNetworkListeners.
Revert DelegatingDiscoveryListener to run on the handler thread as
before, and only use the provided executor to execute any app-facing
callback instead.
Bug: 234419509
Test: atest NsdManagerTest
Change-Id: Icca64511b02dad2f725a2849d2a1e871135b3286
In order to increase the line coverage for the Connectivity
module, remove the DisabledState from NsdService which is
uselss for a while.
Bug: 234315786
Test: atest FrameworksNetTests CtsNetTestCases \
ConnectivityCoverageTest
Change-Id: I29c7ef608d97037084b25daa70ad5829f474e20a
Tethering downstreams do not have NetworkAgents, and although they have
a netid of 99, Networks with netId 99 are not usable by apps for most
connectivity APIs.
Recent refactoring in NsdService adds the Network of a found service
into its NsdServiceInfo, and uses that network to resolve the service.
In that case the Network has netId 99 and resolving the service fails.
Avoid that problem by:
- Keeping the Network field null when a service is found on a tethering
downstream; this avoids giving apps a confusing and unusable Network
with netId 99
- Using the interface index found during discovery to resolve the
service, if the app uses the NsdServiceInfo that was obtained from
discovery to resolve. If not, all interfaces will be used to resolve,
as per legacy APIs.
Bug: 233979892
Test: atest NsdServiceTest
Also manual test with 2 devices connected via hotspot
Change-Id: Idd176153b67ccbd1d4f1b1fd66dafaa2f3a9e27a
(cherry picked from commit 1a8ee102d3)
Merged-In: Idd176153b67ccbd1d4f1b1fd66dafaa2f3a9e27a
* changes:
Skip PersistentIntTest on S- device
Don't clobber existing history entries.
Ensure NetworkStats migrated snapshot is identical
[MS82.1] Support network stats data migration process
Add a PersistentInt class.
Tethering downstreams do not have NetworkAgents, and although they have
a netid of 99, Networks with netId 99 are not usable by apps for most
connectivity APIs.
Recent refactoring in NsdService adds the Network of a found service
into its NsdServiceInfo, and uses that network to resolve the service.
In that case the Network has netId 99 and resolving the service fails.
Avoid that problem by:
- Keeping the Network field null when a service is found on a tethering
downstream; this avoids giving apps a confusing and unusable Network
with netId 99
- Using the interface index found during discovery to resolve the
service, if the app uses the NsdServiceInfo that was obtained from
discovery to resolve. If not, all interfaces will be used to resolve,
as per legacy APIs.
Bug: 233979892
Test: atest NsdServiceTest
Also manual test with 2 devices connected via hotspot
Change-Id: Idd176153b67ccbd1d4f1b1fd66dafaa2f3a9e27a
NetworkStatsHistory internally assumes that bucketStart is
sorted at all times. However, in the fields, we've found there
are some buckets of NetworkStatsHistory do not preserve the
order of timestamp, which is caught by the IAE when addEntry
is called.
In order to provide backward compatibility, return sorted items
instead of throwing IAE when adding entry into
NetworkStatsHistory instance.
Ignore-AOSP-First: Base change not in AOSP, will cherry-pick
immediately after
Test: atest android.net.netstats.NetworkStatsHistoryTest#testBuilder
Bug: 233825704
Change-Id: If3187384bd1e90770ca5873b8ec73e852fff543d
Allow calling enable/disableInterface on non-automotive devices. Also,
fixing the naming of these functions to be consistent with the API.
Test: atest EthernetManagerTest
Bug: 171872016
Bug: 225317990
Change-Id: Ic20185a855d0e639582132bf1103e0183f6f78c3
Currently, adding a history to a NetworkStatsCollection.Builder
will overwrite any history that was previously passed in with the
same key. This breaks the importer (which is the primary/only
caller of this code), because the importer re-uses the same
NetworkStatsCollection object to import multiple files.
Instead, simply add any passed-in entries after the ones that
were already there. Require the caller to pass in entries in
order, because NetworkStatsHistory internally assumes that
entris are always sorted.
Bug: 230289468
Test: manually verified this unbreaks the importer
Change-Id: Ic8647ff28fca78d579d5f759f96a864877f8158b
Merged-In: Ic8647ff28fca78d579d5f759f96a864877f8158b
(pure cherry-picked from ag/18453213)
Read migration snapshot both from the platform API and the legacy
method, and Log.wtf if they are different. Use the legacy method data if
they are.
This ensures that using the migration API is a no-op, and that errors
are reported (through Log.wtf) if it would not have been if used as-is.
Test: NetworkStatsServiceTest
Bug: 230289468
Change-Id: I857ad18183d63d1aa16e89f89eb24009648720a2
Merged-In: I857ad18183d63d1aa16e89f89eb24009648720a2
(pure cherry-picked from ag/18452103)
Improve the setUnderlyingNetwork method by throwing IAE
when Network's LinkProperties is null. Also update the
API doc to give caller more guidance in using this API
Bug: 232309601
Test: UT: IpSecServiceParameterizedTest, IpSecServiceTest,
IpSecServiceRefcountedResourceTest, IpSecManagerTest, VpnTest
Test: CTS: IpSecManagerTest, IpSecManagerTunnelTest, Ikev2VpnTest
Test: make doc-comment-check-docs
Change-Id: Idab4706b0db42ed2222fb48b168589ed005d2f2f
This reverts commit 53eb35cd82.
Reason for revert: b/233081774, caused long build times in FrameworkNetTests
Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Currently, adding a history to a NetworkStatsCollection.Builder
will overwrite any history that was previously passed in with the
same key. This breaks the importer (which is the primary/only
caller of this code), because the importer re-uses the same
NetworkStatsCollection object to import multiple files.
Instead, simply add any passed-in entries after the ones that
were already there. Require the caller to pass in entries in
order, because NetworkStatsHistory internally assumes that
entris are always sorted.
Ignore-AOSP-First: in a topic with internal-only changes
Bug: 230289468
Test: manually verified this unbreaks the importer
Change-Id: Ic8647ff28fca78d579d5f759f96a864877f8158b
Read migration snapshot both from the platform API and the legacy
method, and Log.wtf if they are different. Use the legacy method data if
they are.
This ensures that using the migration API is a no-op, and that errors
are reported (through Log.wtf) if it would not have been if used as-is.
Ignore-AOSP-First: in a topic with internal-only changes
Test: NetworkStatsServiceTest
Bug: 230289468
Change-Id: I857ad18183d63d1aa16e89f89eb24009648720a2
This is needed to ensure corrupted data can be clean up if
the data migration process dones't go well.
Test: NetworkStatsCollectionTest
Bug: 197717846
Change-Id: Ic76ad6f3e96f03791b48988fb2622c9c647ffc7c
(cherry picked from commit 306a00316c)
Merged-In: Ic76ad6f3e96f03791b48988fb2622c9c647ffc7c
Jarjar rules are hard to keep in sync with code, and hard to maintain
manually as the distinction between what should and should not be
jarjared is not always clear. This results in unsafe binaries that are
manually maintained, and developer frustration when something fails due
to incorrect jarjar rules.
Autogenerate jarjar rules at build time instead. This is achieved by
introducing a jarjar-rules-generator python-based library, which scans
pre-jarjar intermediate artifacts, and outputs jarjar rules for every
class to put it in a package specific to the module. The only exceptions
are:
- Classes that are API (module-lib API is the largest API surface of
the module)
- Classes that have unsupportedappusage symbols
- Classes that are excluded manually (for example, because they have
hardcoded external references, like for
ConnectivityServiceInitializer in SystemServer).
This change causes all classes in framework-connectivity(-t) and
service-connectivity to be jarjared into android.net.connectivity, but
still avoids jarjaring classes in com.android.server as before, to keep
it small.
For many classes this differs from the original jarjar rule.
Notes on implementation:
- connectivity-jarjar-rules now has a subset
framework-connectivity-jarjar-rules containing only the rules
necessary for framework-connectivity. This is necessary because
framework-connectivity cannot depend on rules generated based on
service-connectivity, as there would be a dependency cycle
(service-connectivity depends on framework-connectivity); Soong even
crashes with a stack overflow.
- framework-wifi.stubs.module_lib is added to
framework-connectivity-pre-jarjar as it is necessary to build it (it
is already in impl_only_libs in the defaults).
It is unclear why framework-connectivity-pre-jarjar could build
before that (possibly because it was only used as "lib" ?)
- Fix package-private visibility; for example NattSocketKeepalive,
TcpSocketKeepalive are not API so should be jarjared, but are used
by ConnectivityManager which is not jarjared, so they are not in the
same package after the change. Package-private members in the
former 2 need to be public to be accessible. Changes in this commit
are all that is needed, as demonstrated by followup commits that move
the classes to a different package without further changes, and that
enforce that no class in an API package gets jarjared.
- framework-connectivity-internal-test-defaults is separated from
framework-connectivity-test-defaults, for unit tests that need to
access internal jarjared classes. Such tests need to use the jarjar
rules themselves too, so this is only appropriate for connectivity
internal unit tests.
Test: atest ConnectivityCoverageTests CtsNetTestCases
Bug: 217129444
Change-Id: Ied17c3955ea2fda130089265d02908937ad8af1e
This is needed to ensure corrupted data can be clean up if
the data migration process dones't go well.
Test: NetworkStatsCollectionTest
Bug: 197717846
Change-Id: Ic76ad6f3e96f03791b48988fb2622c9c647ffc7c
When adding a listener via the addInterfaceStateListener API, the
expectation is that ethernet service calls that listener immediately
with a list of all interfaces and their respective state. However,
this doesn't work as expectation due to the EthernetManager stores
all registered listeners within one global service listener class,
the new registered listener will be invoked until the state of any
interface has changed.
Instead of storing all registered listeners within one global service
listener class, associate each new registered listener to an instance
of IEthernetServiceListener, and pass it to the EthernetService, that
will be invoked when iterating the state of all existing interfaces.
In order to avoid the scanning of all registered listeners, that would
be slow if there are lots of registered callbacks, moving the service
listener to the ListenerInfo class, where the service listener can
access the executor and listener passed from the caller naturely,
unnecessary to iterate the whole list.
Bug: 229125889
Test: atest android.net.cts.EthernetManagerTest --iterations
Change-Id: I111eba78d1066794c414ab5fb4a31258ea311413
(cherry picked from commit bb9a49cf72)
Merged-In: I111eba78d1066794c414ab5fb4a31258ea311413
When adding a listener via the addInterfaceStateListener API, the
expectation is that ethernet service calls that listener immediately
with a list of all interfaces and their respective state. However,
this doesn't work as expectation due to the EthernetManager stores
all registered listeners within one global service listener class,
the new registered listener will be invoked until the state of any
interface has changed.
Instead of storing all registered listeners within one global service
listener class, associate each new registered listener to an instance
of IEthernetServiceListener, and pass it to the EthernetService, that
will be invoked when iterating the state of all existing interfaces.
In order to avoid the scanning of all registered listeners, that would
be slow if there are lots of registered callbacks, moving the service
listener to the ListenerInfo class, where the service listener can
access the executor and listener passed from the caller naturely,
unnecessary to iterate the whole list.
Bug: 229125889
Test: atest android.net.cts.EthernetManagerTest --iterations
Change-Id: I111eba78d1066794c414ab5fb4a31258ea311413
Currently dumpCheckin passes a null object to create
the contructor of NetworkStatsCollection.Key but the
constructor requires non-null object. Thus, it caused
the NPE in dumpCheckin. To fix this exception, create
an NetworkIdentitySet() object instead of using an
null object.
Bug: 225131008
Bug: 226539404
Test: dumpsys netstats --checkin is fine
FrameworksNetTests
Change-Id: I7f2dadf0647b3f42e0f667d96291d2ae37e23faf
From current design, NetworkPolicyManagerService should only
creates metered carrier/mobile templates. However, if someone
calls the hidden API interface or the template was created
before NetworkTemplate#Builder is published. The caller may
create a non-metered carrier template and persist into the
storage.
This CL elimates this possibility and mark non-metered carrier
template non-persistable, so devices could auto-recover from
this symptom after reboot.
Fix: 222382637
Test: TH
Change-Id: I5265e371b0126ce65c32fb09a6e04223afb3d286
Move iterator and NetworkStats.Entry getters to system-current
according to API council feedback. This reverts parts of
ag/17117903.
Test: TH
Fix: 225168182
(cherry-picked from ag/17397294)
Change-Id: Ia7fdf8d31a96a26b0bf1682f462292b051560477
Merged-In: Ia7fdf8d31a96a26b0bf1682f462292b051560477
Some of the internal classes are not available for priv-apps.
Thus, make them module-lib instead.
This change also adds some nullability annotations for existing
APIs according to go/android-api-guidelines.
Test: m
Test: m frameworks-base-api-system-current-compat
Fix: 217479745
(cherry-picked from ag/17117903)
Change-Id: I18de46b11df7232ab82b9465856fdde621283156
Merged-In: I18de46b11df7232ab82b9465856fdde621283156
Merged-In: Ief3f2304f11b7940a18b98b8533fbca85ffa4dc1
