Add code that translates the new call states to old call states for
in-call UIs that don't yet support background call screening.
Test: CTS
Bug: 140317205
Change-Id: I104f5f7ab3e3dc075e1d9ed5c64fcd924f9a977b
I had added some lines during verification of the base CL [1], but had
accidentally committed, uploaded and merged them. This CL reverts the
accidental addition.
[1] r.android.com/1136528 commit 8e1c1f4d9d
Bug: 142267887
Test: Treehugger
Change-Id: If9ef2a956c8862b7022137111e6c512455780fc6
This CL topic speeds up DefaultMimeMapFactory.create() from 15.5msec
to 5.7msec (measured by bundling a copy of the logic and data into
a test app) and saves 5.2 KByte of space (16 KBytes uncompressed) in
framework.jar. This CL topic does not change the amount of heap memory
consumed by the loaded MimeMap.
This is achieved by moving the following parsing steps from
DefaultMimeMapFactory into a build-time optimization step:
* strip off comments (starting with '#')
* normalize whitespace (trim leading and trailing whitespace;
replace remaining whitespace with a single ' ').
* drop lines that do not contain a ' ' after this step (those
only contained comments or only a MIME type without any
extension).
* use String.indexOf(char) in favor of String.contains(String) or
Pattern matching.
Noteworthy extra step specific to this CL:
* specifically for vendor.mime.types (but not android.mime.types),
add a prefix '?' to MIME types and extensions at build time,
rather than at runtime.
Note that after this CL, DefaultMimeMapFactory can now *only* parse
minimized *mime.types files, not the original (non-minimized) file
format.
Test: Checked that the mapping didn't change by checking that
a device flashed after this CL passes CtsMimeMapTestCases
built before this CL.
Test: Ran "make mimemap-res.jar" and manually verified that files
in the resulting jar look as expected.
Test: Locally added some extra mappings to vendor.mime.types, some
of them with a leading '?', and verified that they all show
up with exactly one leading '?' for the MIME type and each
extension within mimemap-res.jar.
Bug: 142267887
Change-Id: Idf1ef945a4ac225476f2036fbc8bb35eb9c090af
CellBroadcastService is bound to by the platform to handle cell
broadcasts.
Bug: 135956699
Test: manual
Change-Id: Ib1b20da03d271fc0b2736774b2ca6c6514944093
Merged-In: Ib1b20da03d271fc0b2736774b2ca6c6514944093
Add a new method in LinkProperties, isWakeOnLanEnabled() which returns
true if network interface is defined in config_wakeonlan_enabled_interfaces
string-array (config.xml)
Bug: 132705025
Test: atest LinkPropertiesTest & atest ConnectivityServiceTest
Change-Id: I3f7803aafd2f8eaf8aa18419b21339e15d4b7a0b
TelephonyScanManager may sometimes encounter a race condition where
Telephony sends it the first scan result before it has saved the
returned scan ID. This causes a crash in the app that's requesting the
scan.
To fix this, synchronize on mScanInfo while requesting the network scan
so that the handler in TelephonyScanManager will wait for the scan ID to
be saved before processing the first message from Telephony.
Bug: 142068098
Test: manual
Change-Id: I0b2b4c6dc749e21641843818293941704ed870a6
Currently, the PackageManagerShellCommand returns success when a
staged session is successfully commited, regardless of the result
from pre-reboot verification. The flag will force the adb shell to
wait for the verification to complete and output result accordingly.
This will ensure a better experience for the testers.
Bug: 130039562
Test: manual testing by installing apex and observing new detailed
success message
$ adb install --apex --wait-for-staged-session-ready
--wait 2000 com.android.tzdata.apex
Change-Id: Ib7aa9b5dfb683956e48e55461b29278069573aec
Merged-In: Ib7aa9b5dfb683956e48e55461b29278069573aec
The wifi network factories/agents are going to run in the network stack
process for devices which accept wifi mainline module. Allow these
factories/agents to perform privileged operations.
Bug: 142115344
Test: ACTS test
Change-Id: I2dd412ac5c6b67f52c87113fcda345e1f531f9c4
WifiNetworkRequestTest:test_connect_failure_user_rejected passes now.
(cherry-picked from c7580b1d59ee126cd6867cb6fe4485a69e2b4622)
A side effect of CL topic r.android.com/q/topic:bug136256059_attempt2
was that the default MimeMap instance is now loaded eagerly (pre-fork)
regardless of whether any app process ends up using it, whereas
previously it was loaded lazily (post-fork) the first time an app
process used it.
This traded off CPU and memory use post-fork vs. pre-fork. Because it
isn't known / hasn't been proven whether and how many app processes
use that instance, the net CPU and memory impact is not known: if at
least one process makes use of a relevant API, the net impact will be
neutral or positive, or else negative.
Until this can be investigated and undergo system health review, this
CL topic changes the behavior back to post-fork lazy loading of the
default MimeMap instance.
Bug: 142019040
Test: Treehugger
Change-Id: I2a3f244240c51e7ada1f41a8abadb946ebcab40b
This property will need to be reset during userspace reboot, so it can't
be a read-only property anymore.
Test: builds
Test: atest apex_rollback_tests
Bug: 135984674
Change-Id: I9f5ec10ed31b63642192573139e44d43e726ea9c
Another CL in this topic moves libcore.net.MimeMap to package
libcore.content.type. This CL updates associated references.
Bug: 136256059
Bug: 124232146
Test: Treehugger
Test: CtsMimeMapTestCases
Exempt-From-Owner-Approval: move affecting imports only
Change-Id: I30aac8b28a1740180ea01834a2bb66b61cb255d4
The java.io.FileDescriptor object has a poor definition of ownership,
which can result in obscure use-after-close bugs. Instead, APIs should
return or accept ParcelFileDescriptor instances.
Bug: 130209137
Test: manual
Change-Id: Ifb3dd53dc138ec47f416f2d4b46c4668bc8ee1d8
The zygote handles requests by polling on its sockets, and then handling
one request for each active socket. However, it does so by reading from
a socket via a BufferedReader, which means that if multiple requests are
written into the socket before the zygote gets a chance to read them,
the zygote reads multiple requests into its BufferedReader, it handles
one request, and then never responds to the request that's buffered,
leaving its client stuck waiting for a response that will never happen.
For most requests, this can't happen, because the client will wait for a
response to be sent from the zygote before sending another request, but
this isn't true for --boot-completed until this patch.
Bug: http://b/141767463
Test: forrest runs of apct/text/text_native_test-cloud-tf
Change-Id: I8b7a80abfd9443d98f8cf5aedb7669b82c0cb84a
