sysinit depends on having the filesystems mounted, and userdata
in particular depends on having /data present. Move its startup
to post-fs-data
Change-Id: Iafcc926a3aa310c1afe501d272df5811da500d86
This commit updates the Personal Argentina APN to the new
datos.personal.com address and adds another set of entries for when
mnc is 341
Change-Id: Ibe17ba00c5ffe3730fce107f0a471ac9c408b636
The error that this patch was guarding against is no longer reproducible
on d2spr.
This reverts commit 285d4c2a4d.
Change-Id: I373ad22a021de74df4f8907dc79717719708431d
MTNL uses 68 and 69 MNC respectively in Delhi and mumbai
forward port of this change
http://review.cyanogenmod.org/#/c/27022/
Signed-off-by: Arnav Gupta <championswimmer@gmail.com>
This is taken from the OTA update for the Note II.
All APNs are currently resolving to the same 2 addresses from my T-Mobile phone.
The T-Mobile support website lists fast.tmobile.com (no hyphen).
I am attempting to mirror the stock OTA from T-Mobile.
Change-Id: I863b517be7dec19620b79fc876a88ba65e4dacba
Using proxy.mvno.tracfone.com should also future proof it if they change the
IP again. proxy.mvno.tracfone.com resolves to (66.209.11.32)
Change-Id: I8cb5b3ce473bef1369ec4ee313759258fc1172d3
* These "phone" provisioned SIM's don't work with the "pta" APN
* LTE and MMS do work properly with "phone" APN
Change-Id: I782f9ee5c642c5354ab35489a9c899a52c0d5107
- remove SpareParts: it's disabled and broken, the options it provides
are either useless/broken or available in development settings
- remove modelid_cfg.sh: no devices are using this any more
- remove opticharger: it's not used any more
Change-Id: I68c86b2407486c4b40998288cf1f70b7cb8170f4
Reportedly Free Mobile users must edit their APN and remove whitespaces to make it work. I searched and fixed the other ", " occurrences too while I was at it.
Change-Id: Ib948dff8329653c42c967c4dae5a6e97086df127
Keep a blacklist of md5 sums for scripts known to cause issues, and
ignore them when installing new builds
Change-Id: I19a88b58194a32da5eb5fe278f2c5b9a145b57be
This is to address hang-ups in eHRPD-LTE hand-offs as witnessed on d2spr.
Log of problem:
[GsmDC-6] Connecting to carrier: 'APN2 EHRPD internet' APN: 'n.ispsn' proxy: 'null' port: 'null'
[0319]> SETUP_DATA_CALL 15 0 n.ispsn null null 0 IPV4V6
....
qmi_ril(0/281): [event] qcril_data_event_hdlr: Dual-IP Partial Retry: Failure
qcril_data_event_hdlr: Dual-IP Partial Retry: Sending setup data call failure code
On stock rom:
[GsmDC-50] Connecting to carrier: 'APN2 EHRPD internet' APN: 'n.ispsn' proxy: '' port: '
[GsmDC-50] Allow IPv6 type request: false
[9240]> SETUP_DATA_CALL 15 0 n.ispsn 0 IP
Note, PDP type on stock rom/APN is not Dual-IP. Without information on how
"Allow IPv6 type request" is tested, for now force the PDP change via apns-conf.xml
Change-Id: I938bf9d1a0b50ec72283fbdba3785832519f3f48
"getprop" depends on the presence of the property workspace
env var, which is created by the first starting service. Why
not make that sysinit itself? (\/) (°,,,°) (\/)
The old Sprint CDMA MMS apn uses the same MCC/MNC pair (310120) and apn
type ("default") as Sprint's LTE/eHRPD service. Thus, Sprint LTE devices
attempt to connect to LTE/eHRPD services using the old CDMA MMS apn first,
which usually fails, and thus delays service establishment.
However, occasionally service "successfully" connects with the CDMA MMS
apn, for unknown reasons, at which point that apn is set as the preferred
apn for LTE connections. Thus, any subsequent LTE/eHRPD connection attempt
fails due to use of the wrong apn.
By removing the old CDMA MMS apn, LTE/eHRPD connections will use the
appropriate apns. Furthermore
com.android.mms.transaction.TransactionSettings::TransactionSettings does
not query the bearer field when looking for valid MMS apns, so the
LTE/eHRPD will continue to work on non-LTE Sprint devices.
Note that with this change, the MMS apn now specifies an mmsproxy.
Change-Id: Iba48bd6d120b02bc6265f958d0e04181d17f5c66
The "import" keyword is only parsed once, for a one shot execution, during
the initial section setup, and before running "on fs". Having an import of
a file that's located in a filesystem other than root will result in an error
like
<3> init: could not import file '/system/etc/init.local.rc' from '/init.rc'
So... any files imported into init need to be moved to the root fs.
While we're at it, move init.rc changes that are specific to CM (and don't
involve modification of preexisting configs) into this file, to ease future
upstream merges (and minimize breakage on devices that override init.rc with
their own variants)
Needs to be paired with the corresponding system/core patch
Change-Id: Iab6340db2e28ef19dbcd84ae5c71737ce0cd491f
