Jessica Jong [:jessica] (inactive) Reporter
	Description • 11 years ago

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.

	Ken Chang[:kenkai]
	Comment 1 • 11 years ago

It is a 1.4+ bug.

	José Antonio Olivera Ortega [:jaoo] 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.

	Jessica Jong [:jessica] (inactive) 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.

	José Antonio Olivera Ortega [:jaoo] 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.

	Jessica Jong [:jessica] (inactive) 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.

	José Antonio Olivera Ortega [:jaoo] 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.

	Jessica Jong [:jessica] (inactive) 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.

	Ken Chang[:kenkai]
	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.

	Ken Chang[:kenkai]
	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.".

	José Antonio Olivera Ortega [:jaoo] 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!

	José Antonio Olivera Ortega [:jaoo] 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.

	Fabien Cazenave [:kaze]
	Comment 13 • 11 years ago

Comment on attachment 8377559 [details] [diff] [review]
v2

LGTM

	José Antonio Olivera Ortega [:jaoo] 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

	Ken Chang[:kenkai]
	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.

	José Antonio Olivera Ortega [:jaoo] 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?

	Ken Chang[:kenkai]
	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.

	José Antonio Olivera Ortega [:jaoo] 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