This is a preparatory work for mainline. since Intdef is hidden, so we
have to move some annotations (applied in SDK/system API) to a separate
annotation class and having other module statically link to it.
TODO: include telephony annotation in framework-non-updatable-sources
Bug: 140908357
Test: Build
Change-Id: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit c9d4ee112e)
Merged-in: I37f8a0624bbf27f264870ee9dbf03d3aaa5cadc1
(cherry picked from commit 4712711d3d91621083bf92f5a1647b92c20a8b81)
This is primarily a wrapper over ICarrierMessagingService
that to create a stable API to communicate with CarrierMessagingService.
Test: basic messaging sanity
Bug: 143609473
Merged-in: I67fda8bab3902b358c483f992633dbdfe3a8cda2
Change-Id: I67fda8bab3902b358c483f992633dbdfe3a8cda2
(cherry picked from commit 92642659e8)
today telephonyRegistry lives in system process
this is intended to persists all telephony listeners when
phone process crash. Telephony today notify system server by
using AIDL APIs directly. Instead, we are exposing a proper API
surface: telephonyRegistryManager where only phone app and
carrier privileged apps are allowed to use APIs in
TelephonyRegistryManger to notify telephony related status update.
Bug: 140908357
Test: Build & Manaul
Change-Id: I1b750751148925b4a7bd94553318907654012fc1
(cherry picked from commit 288b71c8c1)
Merged-in: I1b750751148925b4a7bd94553318907654012fc1
These apis are required for adding UI in the Developer options for
modifying compatibility change overrides.
Bug: 138280620
Test: atest CompatConfigTest
Change-Id: If55aa68f9bdd6bed0765324e972de3683bacb553
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
