© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
Some points:
" This means that a user's device when initially provisioned ends up with all five APNs."
Will this at least make it work for the user? Besides having extra APNs that are not needed.
"What should have happened is that we should've discussed the details of giffgaff's MVNO arrangement with O2 and added 'mvno_type' and 'mvno_data' based upon this information. If this had been done, then users with giffgaff SIMs would only get the giffgaff APNs provisioned."
Don't know how easy is to do that, but we can try, for sure.
"Furthermore, these new APNs were added to the end of the file, instead of being inserted inline with the other APNs that specify the same mcc/mnc."
This was on purpose, as it's then easier to merge back changes from AOSP (helps reducing the amount of conflicts).
"The change to apns-conf.xml was reviewed, but not actually tested..."
What would the test show up here? Would it at least connect to one of the APNs available in there?
Also, I also took this change because a similar one is also available in CyanogenMod:
<apn carrier="giffgaff" mcc="234" mnc="10" apn="giffgaff.com" user="giffgaff" password="password" mmsc="http://
This is a common issue on Android as well, and it all goes back to the point of being able to define or not the mvno_type/data.
In case this entry wasn't there, would just using the APN editor help reducing the amount of APNs selected? If so, I'd vote removing this from the database.