Closed
Bug 968092
Opened 11 years ago
Closed 11 years ago
APN Settings: parse apn type 'dun' and 'ims' from apn.json database
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
1.4 S2 (28feb)
People
(Reporter: jessica, Assigned: jaoo)
References
Details
(Whiteboard: [FT:RIL])
Attachments
(3 files, 1 obsolete file)
46 bytes,
text/x-github-pull-request
|
Details | Review | |
1.76 KB,
patch
|
Details | Diff | Splinter Review | |
5.61 KB,
patch
|
kaze
:
review+
|
Details | Diff | Splinter Review |
APNs for dun and ims need to be parsed from the database and passed to gecko through 'ril.data.apnSettings', just like the other apn types. These apn types are needed for 1.4 features.
Updated•11 years ago
|
Blocks: b2g-LTE-1.4
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → josea.olivera
Assignee | ||
Comment 2•11 years ago
|
||
Assignee | ||
Comment 3•11 years ago
|
||
This simple patch allows the operator variant logic to set the APNs for 'tun' and 'ims' types on boot. These APNs will be passed to the RIL plumbing through the 'ril.data.apnSettings'. Jessica, I guess this patch will be useful for you while testing the logic you are adding to the RIL plumbing for handling these APNs. May I know what operator numeric value (MCC and MNC codes) has the ICC card you will test with? Note: this patch doesn't provide the bits the setting app needs to show the panels for selecting the APNs of these new types. Bug 969298 will take care of it.
Reporter | ||
Comment 4•11 years ago
|
||
Thank you, José. I have applied your patch and modified apn.json under shared/resources/ (added apns for type dun/ims) for testing, but after flashing gaia I still don't see the new apns coming in ril.data.apnSettings, am I missing anything? Does it read from apn.json everytime? The MCC-MNC that I use for testing is 466-92.
Assignee | ||
Comment 5•11 years ago
|
||
(In reply to Jessica Jong [:jjong] [:jessica] from comment #4) Jessica, I've used this patch for testing. It adds 'ims' and 'dun' APN types for the existing APN for internet. Moreover I've forced the operator variant logic to select the APNs for the ICC card you are using. I see the 'ril.data.apnSettings' holding the APNs for types 'ims' and 'dun'. I/Gecko ( 792): -*- RadioInterface[0]: 'ril.data.apnSettings' is now [[{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["ims"]}],[]] I/Gecko ( 792): -*- RadioInterface[0]: setupApnSettings: [{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["ims"]}] > I have applied your patch and modified apn.json under shared/resources/ > (added apns for type dun/ims) for testing, but after flashing gaia I still > don't see the new apns coming in ril.data.apnSettings, am I missing > anything? You just need to apply the patch and reinstall gaia as follow: |make reset-gaia| > Does it read from apn.json everytime? No, it does not. The 'ril.data.apnSettings' get populated every time a new ICC card is inserted.
Reporter | ||
Comment 6•11 years ago
|
||
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #5) > Created attachment 8373223 [details] [diff] [review] > Patch for testing > > (In reply to Jessica Jong [:jjong] [:jessica] from comment #4) > > Jessica, I've used this patch for testing. It adds 'ims' and 'dun' APN types > for the existing APN for internet. Moreover I've forced the operator variant > logic to select the APNs for the ICC card you are using. > > I see the 'ril.data.apnSettings' holding the APNs for types 'ims' and 'dun'. > > I/Gecko ( 792): -*- RadioInterface[0]: 'ril.data.apnSettings' is now > [[{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) > (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1. > 1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["ims"]}],[]] > I/Gecko ( 792): -*- RadioInterface[0]: setupApnSettings: > [{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) > (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1. > 1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) > (Internet)","apn":"internet","types":["ims"]}] > > > I have applied your patch and modified apn.json under shared/resources/ > > (added apns for type dun/ims) for testing, but after flashing gaia I still > > don't see the new apns coming in ril.data.apnSettings, am I missing > > anything? > > You just need to apply the patch and reinstall gaia as follow: > > |make reset-gaia| > > > Does it read from apn.json everytime? > > No, it does not. The 'ril.data.apnSettings' get populated every time a new > ICC card is inserted. Oh, that's why. I am having some problems using 'make reset-gaia', so I just used './flash gaia'. After switching SIM cards, I can get the 'ims' and 'dun' apns, thank you.
Assignee | ||
Comment 7•11 years ago
|
||
(In reply to Jessica Jong [:jjong] [:jessica] from comment #6) > Oh, that's why. I am having some problems using 'make reset-gaia', so I just > used './flash gaia'. > After switching SIM cards, I can get the 'ims' and 'dun' apns, thank you. Glad it worked. I'll keep an eye and land this bug once both 960865 and 961571 bugs land.
Updated•11 years ago
|
blocking-b2g: 1.4+ → backlog
Whiteboard: [FT:RIL]
Updated•11 years ago
|
Target Milestone: --- → 1.4 S3 (14mar)
Reporter | ||
Comment 8•11 years ago
|
||
José, do you think we can land this before bug 960865 and 961571? gecko can store the new apns and decide what to do with them later, cause just having the new apn might be enough in some cases. Thanks.
Comment 9•11 years ago
|
||
The target milestone is too late. I have changed it to 2/28. It is impossible date. Please let me know.
Target Milestone: 1.4 S3 (14mar) → 1.4 S2 (28feb)
Comment 10•11 years ago
|
||
(In reply to Ken Chang[:ken] from comment #9) > ..... It is impossible date. Please let me know. Sorry for this wrong sentence. What I mean is "If it is impossible to finish it before 2/28, please let me know.".
Assignee | ||
Comment 11•11 years ago
|
||
Fabien, the patch here allows the operation variant logic to store 'dun' and 'ims' APNs into the database. I've added some bits to cover the change/addition with the existing unit tests. Could you please take a look a it please? Thanks!
Attachment #8372226 -
Attachment is obsolete: true
Attachment #8377559 -
Flags: review?(kaze)
Assignee | ||
Comment 12•11 years ago
|
||
(In reply to Ken Chang[:ken] from comment #10) > (In reply to Ken Chang[:ken] from comment #9) > > ..... It is impossible date. Please let me know. > Sorry for this wrong sentence. What I mean is "If it is impossible to finish > it before 2/28, please let me know.". Nope, I guess it possible to finish it. Actually I was waiting bugs 960865 and 961571 to land before landing this bug.
Comment 13•11 years ago
|
||
Comment on attachment 8377559 [details] [diff] [review] v2 LGTM
Attachment #8377559 -
Flags: review?(kaze) → review+
Updated•11 years ago
|
Assignee | ||
Comment 14•11 years ago
|
||
The patch in this bug is ready to land, however it's not 1.4+ yet. As bug 952026 is part of the list in [1] I'm wondering if this bug could be 1.4+ and landed in master. [1] https://wiki.mozilla.org/B2G/Roadmap#Key_Focus_1.4_Features
Flags: needinfo?(whuang)
Flags: needinfo?(kchang)
Comment 15•11 years ago
|
||
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #14) > The patch in this bug is ready to land, however it's not 1.4+ yet. As bug > 952026 is part of the list in [1] I'm wondering if this bug could be 1.4+ > and landed in master. > > [1] https://wiki.mozilla.org/B2G/Roadmap#Key_Focus_1.4_Features It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features.
Flags: needinfo?(kchang)
Assignee | ||
Comment 16•11 years ago
|
||
(In reply to Ken Chang[:ken] from comment #15) > It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features. Thanks, should I wait to land it until it becomes 1.4+ or could I land it directly?
Flags: needinfo?(kchang)
Comment 17•11 years ago
|
||
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #16) > (In reply to Ken Chang[:ken] from comment #15) > > > It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features. > > Thanks, should I wait to land it until it becomes 1.4+ or could I land it > directly? Partner asks to have some bugs landed before 2/28. Bug 952026 is one of these bugs. So yes, it would be great if you can land it directly. Moreover, as I know "now"(I am not sure if it would change afterwords.), we don't use 1.4+ for features, even it is a key feature.
blocking-b2g: backlog → 1.4+
Flags: needinfo?(kchang)
Updated•11 years ago
|
blocking-b2g: 1.4+ → ---
Flags: needinfo?(whuang)
Assignee | ||
Comment 18•11 years ago
|
||
Test passes, everything seems to work correctly and travis went green. Landing then on Gaia master branch at https://github.com/mozilla-b2g/gaia/commit/16767eb7ed284bc89604aa00be145ef67343f0bc
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•