* changes:
Clean up generatePackageInfoFromApex() API
Populate error message if apexd.markStagedSessionReady fails
Populate error message if apexd verification fails
Make ApexManager an abstract class
Don't use ApexInfo.packageName in StagingManager
This changes the API for generatePackageInfoFromApex in PackageParser
in response to review suggestions made in ag/6701090.
The method is renamed to generatePackageInfo with a PackageParser.Package
parameter (as well as an ApexInfo and flags). The implementation is combined
with the main generatePackageInfo method. Callers are changed to perform
the parsing themselves, including the collection of certificates if
necessary.
Note: the method signature and implementation had already changed since
ag/6701090, so the suggestions from that CL may not apply directly.
Bug: 129261524
Test: atest PackageParserTest
Test: atest CtsStagedInstallHostTestCases
Change-Id: Iee213e025583c2201ff9d65c447e4278b925a2f0
Merged-In: I495539679812110f89d5e3d93f2622ba2dab36c0
(cherry picked from commit c2c7a22333)
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
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
