Problem & Root cause:
the mInterfaceBroadcastAddr.sll_protocol is not assigned when the
interface initializes, sll_protocol is 0x0000 by default.
This causes packets to be filtered incorrectly in packet capture,
typically with tcpdump. The previous API is used by DhcpClient, causing
DHCP tx messages to not be recognized properly.
Background: inside the kernel packets carry both an ethertype metadata
(skb->protocol) and may also carry a real ethertype in the mac header.
Previously skb->protocol would be inherited from the socket either from
the protocol from socket() creation or from bind(). This was zero,
so skb->protocol would end up 0, even though the DHCP packets we actually
wrote would have the right on-the-wire ethertype populated in the bytes
passed to send().
As such DHCP packets would look correctly on the wire, but were lacking
the skb->protocol metadata to correctly tag them as IPv4.
This results in 'tc' and packet hooks potentially not triggering
correctly, and can thus result in tcpdump 'ipv4' filters discarding
these packets leading to confusing/erroneous tcpdump output.
In newer kernels (somewhere around 5.3), if socket protocol is 0, we
actually parse out the right ethertype from the mac header during send().
However, for old kernels we can't rely on this kernel magic, and the
right fix is simply to make sure that socket bound protocol is correctly
set to ipv4 [htons(ETH_P_IP)] in the bind() system call.
Solution:
Add a new constructor in SocketUtils to set the protocol parameter.
Bug: 133196453
Test: manual test
Change-Id: I07887b82e0e32aadb0cbb9f930f2b2fa3e277ca9
This class is hanging around for UnsupportedAppUsage. Adding additional
method to fix compilation, but it should never be called.
Bug: 135686713
Test: compilation fixed
Change-Id: I58022af86a53239990e057936826d0f1214acc6f
Moved RESOLUTION_ACTIONS from EuiccService to EuiccResolutionUiDispatcherActivity,
so that it does not need to be made public.
Bug: 137202333
Test: compilation
Change-Id: If8011bbe6af32c038f55d851acc2406eba208de6
Merged-In: If8011bbe6af32c038f55d851acc2406eba208de6
Instead of storing each Locale within a Configuration object's locale
list by its language, country, variant, and script to proto, store the
entire locale list by its language tags representation which accurately
describes each locale.
Bug: 140197723
Test: atest ConfigurationTest
Test: atest UsageStatsDatabaseTest
Test: manually with bad data
Merged-In: I53946ed4e31de0ffe9c84875c391a7dec6f5375a
Change-Id: Idaae690f79a5c680ad0059a52be62160d9dfb5e7
(cherry picked from commit 5e67462971)
Introduce a platform_compat_native service that just calls the
platform_compat service.
The new service is needed as it needs a slightly different (more
limited, no ApplicationInfo in cpp) aidl API, and a class can only
extend one stub.
Test: Call the service from dumpsys.cpp (http://aosp/1142055)
Bug: 138275545
Change-Id: Ic46cc34b4c1dd4ebc6bcc996fb3f8503607214ac
Merged-In: Ic46cc34b4c1dd4ebc6bcc996fb3f8503607214ac
Provide a specifc notification to let users know that device
has no internet is because it really doesn't have internet access
or it's caused by private DNS resolution failed.
Bug: 113242081
Test: atest FrameworksNetTests
Change-Id: I710c88a4742f5fd56c39fc797d7fa3ad36dba553
Make TimeDetectorService more aware of a time signal's origin by making
the time signal from telephony less generic.
When TimeDetectorService was written it was assumed that the TimeSignal
could be generic and there would just be a String source identifier to
indicate origin.
With multiple SIMs / phones on a device it makes sense to keep track of
the originating phone of the signal so that the time detector service
could implement stickiness if it wanted. This would avoid a device
alternating back and forth between two signals and help with debugging.
As new signals are added, new "suggestXxxxTime()" methods will be added
to TimeDetectorService. That is the point at which the strategy for
ranking different sources can be decided. e.g. should NTP always rank
higher than NITZ?
The main change here is that TimeSignal is renamed to
PhoneTimeSuggestion to indicate it's only for use by signals from
telephony, sourceId has been removed and it has been given a phoneId
instead. Extra free-form metadata (mDebugInfo) has been added to assist
with logging / debugging.
Bug:140712361
Test: atest android.app.timedetector
Test: atest com.android.server.timedetector
Change-Id: I5305c34516e5f4e254309193183f00e054801a46
The mention of P in the doc was unclear. Also, listing the specific
values allowed is a maintenance issue.
Test: None
Change-Id: I9c46eec353090ecd822f10a0a9e8433fa46246a0
To support mainline modules, adding the methods which
are used by wifi.
Bug: 139268426
Bug: 135998869
Bug: 138306002
Test: atest android.net.cts
atest android.net.wifi.cts
atest FrameworksNetTests
atest NetworkStackTests
./frameworks/opt/net/wifi/tests/wifitests/runtests.sh
Change-Id: I49856863c15b6b3b59aa867a77b0f137003149ef
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
Bug:141028068
Change-Id: I89f4add79a55c3c8d6fbe8d57decaa78fe12f0f9
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
We had accidental usages of the PermissionChecker for cases where no
private data was provided to the app but the checkPermission API on
the latter also did blame data access on the app. The PermissionChecker
was designed to handle IPC calls and not for generic API checks.
To avoid future accidental incorrect PermissionChecker usages this
change renames the existing APIs of the latter to clearly indicate
that they should be used for data delivery and also adds sibling
methods for doing the same permission checks for preflight purposes.
Also the documentation is improved to furhter assist developers.
In addition, this change fixes accidental permission checker usages
that blame when they should not by using the new preflight flavor
of the permission check APIs.
Test:
atest com.android.settingslib.location.RecentLocationAppsTest
atest CtsPermissionTestCases
added: LocationAccessCheckTest#notificationOnlyForAccessesSinceFeatureWasEnabled
added: LocationAccessCheckTest#noNotificationIfFeatureDisabled
added: LocationAccessCheckTest#noNotificationIfBlamerNotSystemOrLocationProvider
added: LocationAccessCheckTest#testOpeningLocationSettingsDoesNotTriggerAccess
Bug:141028068
Change-Id: I4a74d4906f92e323fbd30b9b25011129895afc9a
Merged-In: I89f4add79a55c3c8d6fbe8d57decaa78fe12f0f9
Merged-In: I65c71569d0dd8a40bc6fecabb22c5373dd6e806e
waitForService is used to lazily start AIDL services
Bug: 138756857
Test: Manual (tested starting gsiservice with this function)
Change-Id: I7ff16b014052d3845bd4b1baa8fc9843e7975a16
