[Samsung Galaxy S9  Questions & Answers] cr2:
Wow, thanks! It seems the chinese really kicked Samsung's ass ;)

The problem is with the buggy post-processing tools like

https://github.com/rokubun/android_rinex

which can't cope with dual- (or triple-) frequency data.

I have modified this script a bit, so ignore the line for column formatting

4 C1 S1 L1 D1 # / TYPES OF OBSERV

because the L1/E1 is intermixed with L5/E5a:

18 06 23 04 16 54.000199 0 30G01G03G07G08G11G17G18G22G28G30G01G03
G08G30R22R12R11R23R21J193J193C01C03C07
C08C10E02E30E02E30
20342817.136 26.714 4348.261 -144.612
160033405783223.906 11.595 -11354.202 1533.683
20056981.801 33.608 30251.712 -815.290
23297916.965 35.073 112405.810 -2997.898
20469583.161 36.869 55459.585 -1485.024
23354615.793 30.690 -40356.377 1070.240
20906958.175 26.254 68637.919 -1838.817
24177555.707 22.328 -34541.965 1015.860
22992130.762 32.338 -42931.967 1142.406
20865945.068 39.449 -40354.058 1067.293
20342815.042 30.382 7091.377 -144.330
24587688.559 8.282 418033.959 1695.919
23297921.153 37.685 392089.972 -2997.655
20865939.693 26.216 -142667.985 1067.440
152180067348069.656 28.864 59178.607 -1566.715
160032831928217.750 26.719 -82162.777 2157.172
160032831182525.688 33.146 34403.499 -914.303
152180069486786.031 24.950 -73118.007 2181.582
152180070242587.719 24.801 149508.310 -4174.866
160033411104960.625 19.209 11275.600 -429.216

160033406907861.719 12.954 -8495.260 -412.546
4234542532.363 32.557 6771.931 -502.740
160033411118526.250 26.994 5153.246 -503.103
4233253213.742 27.442 5470.045 -155.371
4232905313.602 25.028 16231.081 -431.796
4233395911.048 38.024 -5429.621 140.716
25466351.764 30.442 31481.828 -1918.917
21853647.600 35.377 -6910.191 189.473
25466351.485 28.684 -288601.840 -1919.438
21853655.382 34.853 -20815.672 189.631

If i clean up the junk and time-misaligned GLONASS, QZSS and BEIDOU entries you get

this table (BTW, QZSS J1 is also sending L5 signal according to your logs!)

C1/C5 S1/S5 L1/L5 D1/D5
20342817.136 26.714 4348.261 -144.612 g1 L1
20056981.801 33.608 30251.712 -815.290 g7 L1
23297916.965 35.073 112405.810 -2997.898 g8 L1
20469583.161 36.869 55459.585 -1485.024 g11 L1
23354615.793 30.690 -40356.377 1070.240 g17 L1
20906958.175 26.254 68637.919 -1838.817 g18 L1
24177555.707 22.328 -34541.965 1015.860 g22 L1
22992130.762 32.338 -42931.967 1142.406 g28 L1
20865945.068 39.449 -40354.058 1067.293 g30 L1
20342815.042 30.382 7091.377 -144.330 g1 L5
24587688.559 8.282 418033.959 1695.919 g3 L1
23297921.153 37.685 392089.972 -2997.655 g8 L5
20865939.693 26.216 -142667.985 1067.440 g30 L5
25466351.764 30.442 31481.828 -1918.917 e2 E1
21853647.600 35.377 -6910.191 189.473 e30 E5
25466351.485 28.684 -288601.840 -1919.438 e2 E1
21853655.382 34.853 -20815.672 189.631 e30 E5

Another important thing is the availability of Galileo INAV subframes

in your logs

(neither Samsung nor Huawei provide this output).

Mask=101 is GPS NAV, and Mask=601 is GAL INAV:

SV Mask
1 101
2 601
7 101
8 101
11 101
17 101
18 101
28 101
30 101
30 601

I don't know how bad is the chinese smartphone antenna and how stable is the carrier phase tracking, but the rest of the system seems to provide the necessary raw data for centimeter-level accuracy :)

This is really the first true L1/L5 smartphone setup.