The legacy VPN has, among many parameters, a host to connect to.
This host can be specified as a numeric address, or as a hostname.
When it's a name, resolution is required. Currently, name
resolution is performed by the native VPN daemons racoon and
mtpd. When a hostname is used, the framework does not know the
IP address of the VPN server and does not add a throw route for
the VPN server IP address. On older kernels this does not matter
because the legacy PPP kernel code binds the PPP socket to the
right network, but on newer devices that use the upstream PPP
code, this does not work. See b/133797637.
This patch instruments the legacy VPN code so that it can be
run in tests, and uses this instrumentation to simulate passing
a configuration that contains a host, and verifies that the
arguments passed to the mptd and racoon daemons receive the
expected server address, and that the expected throw route is
correctly installed.
It then adds two tests : one specifying the server as a numeric
address, and one as a hostname. As the resolution is currently
broken, the latter of these tests is added disabled, and the
followup fix to the issue enables it.
This test is basic and very targeted, but it's what we need right
now. Also there are plans to remove this entire code path in S, so
the test being ad-hoc is not much of a problem.
Test: this
Bug: 158974172
Change-Id: I96f4bbb9b109e3e5813d083bed1989d88fb156b8
Merged-In: I3c4a94181bd71df68121fa0f71669fa4fa588bdd
(cherry picked from commit dece7f3f74)
This patch is still needed and should go in now that the
error is fixed.
The patch was submitted into rvc-dev and is already in
rvc-dev-plus-aosp (patch in in ag/11923559, revert
skipped in ag/12072199). A follow-up will remove the
unused services.net-module-wifi target.
Test: originally tested in aosp/1324109
Test: m; manual: flashed, wifi and telephony working
Test: atest NetworkStackCoverageTests
Change-Id: I1074eedb0b0f156a1135e11210ec102de15ea674
Merged-In: Icd141a992c46290c74929785e261a1cd57bc001b
The semantics of FileDescriptor in AIDL are that the callee must close
the file descriptor it receives manually.
Bug: http://b/157789860
Test: treehugger
Change-Id: Ice9fc9abe2959a84ad138a95c900dff676653665
Prevents the robolectric shadows jar from including ExoPlayer
symbols, which collide with app-bundled class files.
Bug: 161753405
Test: Manually checked robolectric jar contents.
Test: Built sargo-userdebug, flashed and tested on physical device.
Change-Id: I3bdc9e0b22cd0dea40f5bad15b0e6c619d32faf6
This method is intentionally overridden by subclasses. The
infrastructure doesn't detect that this is happening, but we should
still annotate this as part of the API.
As requested by API review council.
Bug: 162811168
Test: build only
Change-Id: I27714a93b71108cc0cc62fc858c260e2a6920ba9
Abstracted logic that applies to all pointer types into general
PointerController class and moved implementation of logic specific
to the mouse cursor and touch spots to MouseCursorController and
TouchSpotController, respectively.
Test: Pixel 3XL device, atest PointerController_test, compile
Change-Id: Ia5825c37ca75951cc8bcd7d5102c986bd957e69f
Its getAllUsers() method was not returning pre-created users, so
packages installed for a "regular" user were not marked as
"installed=false" for the pre-created users. Hence, when the
pre-created was "promoted" to a full user, it contained such
packages.
Here's how to reproduce the issue:
$ m -j ApiDemos
$ adb shell pm create-user --pre-create-only
Success: created user id 10
$ adb install --user cur $OUT/testcases/ApiDemos/arm64/ApiDemos.apk
Performing Streamed Install
Success
$ adb shell pm list packages --user cur | grep com.example.android.apis || echo
package:com.example.android.apis
$ adb shell pm list packages --user 10 | grep com.example.android.apis || echo "NOT FOUND"
package:com.example.android.apis # Should return "NOT FOUND"
$ adb shell pm create-user FullUserIAm
Success: created user id 10
$ adb shell pm list packages --user 10 | grep com.example.android.apis || echo "NOT FOUND"
package:com.example.android.apis # Should return "NOT FOUND"
With this fix, it returns "NOT FOUND" in the expected steps.
Fixes: 160252062
Fixes: 162847145
Test: see above
Merged-In: I6cd17ac588a4d95bf0ea704dd18387e19eeab374
Change-Id: I6cd17ac588a4d95bf0ea704dd18387e19eeab374
(cherry picked from commit 00175974ba24d982ecfe760ee78a1a17bb326d04)
If the carrier supports call forwarding number prefixes to be allowed
while on IMS roaming, then the number should be dialed and forwarded successfully
Bug: 153413483
Test: Verify the call using *72 <number to be forwarded to> is dialed and forwarded successully
Change-Id: Ia93dec2ebb11aa3ab8f48975a9b6f02089d1482b
Merged-In: I6cd1e60e0dbb634581c97552dad244383ff4e3f9
This adds code to resolve the endpoint in the legacy VPN
runner if it was specified as a hostname, and enables the
previously added test that was disabled because this was
broken until this patch. See the linked bug for details.
This patch uses the async DNS API to do the resolution.
This lets the resolution be fully cancellable, though the
code is more complex than with the non-interruptible
getByName.
Test: VpnTest and in particular VpnTest#testStartRacoon
Fixes the test meant to test this
Also manual testing that resolution of a real
hostname works as expected, that failure to resolve
returns correctly, and that cancellation/interruption
will unblock the thread and terminate immediately.
Bug: 158974172
Change-Id: I714985f3c7919dad9c1854830c50f29c1f94a21e
The legacy VPN has, among many parameters, a host to connect to.
This host can be specified as a numeric address, or as a hostname.
When it's a name, resolution is required. Currently, name
resolution is performed by the native VPN daemons racoon and
mtpd. When a hostname is used, the framework does not know the
IP address of the VPN server and does not add a throw route for
the VPN server IP address. On older kernels this does not matter
because the legacy PPP kernel code binds the PPP socket to the
right network, but on newer devices that use the upstream PPP
code, this does not work. See b/133797637.
This patch instruments the legacy VPN code so that it can be
run in tests, and uses this instrumentation to simulate passing
a configuration that contains a host, and verifies that the
arguments passed to the mptd and racoon daemons receive the
expected server address, and that the expected throw route is
correctly installed.
It then adds two tests : one specifying the server as a numeric
address, and one as a hostname. As the resolution is currently
broken, the latter of these tests is added disabled, and the
followup fix to the issue enables it.
This test is basic and very targeted, but it's what we need right
now. Also there are plans to remove this entire code path in S, so
the test being ad-hoc is not much of a problem.
Test: this
Bug: 158974172
Change-Id: I420b63db03a58e8c67a98a85c9f4c2d6ed7ad078
(cherry picked from commit 45846a03051a13d667732288e457eab4336a691e)