(This is consistent with Google's APNs config.)
These changes have been thoroughly tested on the Telus mobile network.
More Info...
Telus (from Western Canada) doesn't yet fully support IPV6. As a
result, Telus customers trying to run LineageOS won't have mobile data.
Telus users (including myself) have been running into this
problem for years. For example...
https://www.reddit.com/r/LineageOS/comments/hyg5hw/change_apn_settings/
Change-Id: I5085c9463e26da7101106525550f1efef2474c5b
* Since it's unclear what the numbers are, make it easier to add a new
apn by specifying the possible values in a comment at the top
* Also add missing copyright (verified, first LineageOS commit was
indeed 2016)
Change-Id: Icaf292fd79a903bcf9ef5a3813f6288cffc468ad
(cherry picked from commit 7aded097379bd76b9167cc7f5784bcb3a9858066)
* The correct string is "IP", not "IPV4"
* Other possible values are "IPV6" or "IPV4V6"
* Source: prebuilts/sdk/30/public/api/android.txt
Lines: 46832-46834
Change-Id: I3d4729b829f87a4d7ab83584d1aed01d87e10fd2
(cherry picked from commit 7dc952be2a46b2987a293f02dc394d1e5c9809ab)
* The parsing of apns-conf.xml happens in
packages/providers/TelephonyProvider/src/com/android/providers/telephony/
TelephonyProvider.java
* Looking at the code, the only possible occurance of "spn" is as a
value for "mvno_type"
-> Remove all spn="" attributes
Change-Id: Ic7fef88c98ad54ea98d702e028a0455de22e55cd
* We have duplicate entries with one of them having a proxy
* According to the issue, no proxy is required
* Since the one with proxy is selected by default, the user has to change
it manually
-> Remove the wrong one
* Also correct order: Internet, then MMS
* Fixes: https://gitlab.com/LineageOS/issues/android/-/issues/3850
Change-Id: Id3857d74b703b1dd7d16714a3edc6853d4752e64
(cherry picked from commit 7efa2053b6a08da41ddea78bfd30b543693b5c05)
* Devices should use ro.radio.noril and considering vendor
services now should have a vendor. prefix, this script is
useless. No device is using this script now.
Change-Id: I7cbb4f966124ca1307aaf1787301b8247d881b26
- FreedomPop UK uses three.co.uk for its APN
- Add missing `type` param that prevents use of data on any Three UK or Three MVNO SIM
Change-Id: I5f0656d95070c312d5d563536909f23722857372
from MIUI v12.0.8.0.QJKCNXM for lmi
The default APN selection for some Chinese carrier SIM cards is
incorrect, resulting in no internet or very slow internet access.
Therefore, replace APN configs from MIUI for all mcc=460 entries.
[TH779] Still keep IPv6 enabled for these APNs.
Signed-off-by: TH779 <i@779.moe>
Change-Id: Id95cbeda2a63764348d07ddcc8caa7b7e49c6f7c
* It's EE now
* Should not be required since 2015:
"In 2010, it merged with Orange UK to form a joint venture,
Everything Everywhere, in 2010, which continued to operate the
T-Mobile and Orange brands until March 2015 and allowed T-Mobile
customers to utilise Orange's 2G signal and vice versa.
In 2012, Everything Everywhere launched a new network, branded EE."
-- https://en.wikipedia.org/wiki/T-Mobile_UK
Fixes: https://gitlab.com/LineageOS/issues/android/-/issues/3069
Change-Id: Id94a6e156f20b484ea3d23cd3a30f5f9e796b117
* PosteMobile is now a full MVNO and it has its own mnc
* Entries extracted from platina-user 10 QKQ1.190910.002 V12.0.3.0.QDTMIXM release-keys
Change-Id: I70d314c558074f2564e88c761c22bc842b973d99
* CoopVoce is now a full MVNO, thus deprecating older ESP entries (still kept here because not all users changed SIM card yet)
* Entries extracted from platina-user 10 QKQ1.190910.002 V12.0.3.0.QDTMIXM release-keys
Change-Id: I9a59ba54926e27ce64d5adbca42fb7b058436e6f
* Ignore the block devices in case their mount points are symlinks.
This is common on devices where maintainers have chosen not to use
real partitions because of their size being too small to be useful
Also `continue` instead of `break`. Oops.
Change-Id: I3e27abe510219066ecacd81d099220ac8e119f9f
There are addon.d scripts that rely on the value of ADDOND_VERSION
to determine if they're being called from a-only vs a/b backuptool.
If they declare ADDOND_VERSION=3, they shall stop doing that;
otherwise offer them the same environment, that is unset ADDOND_VERSION
for a-only backuptool.
Change-Id: I1be21eda2e6ec9837b3080bb5e7fbe5241318eaa
* Also: add a lot of additional info for many of the numbers based on
the comments from the commit prior to this
Change-Id: I937637c8f002d193ed6b23ac60c1f350d7d2eec7
* The plan was to support odm & oem too, but it turned out
unnecessarily complicated due to their symlink setup,
while being most likely unused.
The partitions were removed from the list of supported ones
in a-only backuptool, but were forgotten in ab backuptool.
Change-Id: I58a01cdc3f5c4239048b204f3313f4bf697dd60a
For scripts declaring ADDOND_VERSION=3 automatically mount
vendor, product, system_ext and others (when they're dedicated partitions).
Also expose the get_output_path() function to get the path to where
a file is mounted in case it lives in a dedicated partition.
ab exapmles:
get_output_path "system/product/priv-app/MyApp.apk" = "/postinstall/product/priv-app/MyApk.apk"
get_output_path "system/app/MySystemApp.apk" = "/postinstall/system/app/MySystemApp.apk"
a-only examples:
get_output_path "/mnt/system/system/product/priv-app/MyApp.apk" = "/mnt/system/system/product/priv-app/MyApp.apk"
******************************************************************
Instead of cycling all scripts for each stage, run
pre-backup -> backup -> post-backup in quick succession
(and likewise for restore), to ensure backwards compatibility
with scripts that wrongly assumed their environment not to
change between steps.
This is needed because we want to undo any mounting done for V3
scripts when executing V2 scripts. If a V2 script did mounting in
pre-restore and expected things to still be mounted in restore,
we would break their (yes incorrect) assumption.
Change-Id: I73fbad6f45824fed99e4482128769435348588f5
