Closed Bug 757852 Opened 12 years ago Closed 12 years ago

B2G Emergency Calls: Make them work on ICS.

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla15
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: jaoo, Assigned: jaoo)

References

Details

Attachments

(1 file)

Emergency calls do not work on ICS. This is because we used a non-standard RIL request type on GB for SGS2. It seems that request type is not longer available on ICS. What RIL says when we make an emergency call with this request type is: 

'E/RILC    ( 1832): unsupported request code 10016 token 60'

At a first glance it seems we have to touch a bit our loved initRILQuirks() function.
Assignee: nobody → josea.olivera
The  REQUEST_DIAL_EMERGENCY_CALL request type is still supported on ICS stock. I made a test and also decompiled the RILConstants.java in order to assure if that request type is still supported. Here is:

.field public static final RIL_REQUEST_DIAL_EMERGENCY_CALL:I = 0x2720

Definitely something is fishy here because when running B2G ICS we get:

'E/RILC    ( 1832): unsupported request code 10016 token 60'

AFAIK we grab rild and RIL libraries from the device running stock ICS before building B2G and we should get the same behaviour but it seem that is not happening at all. I am quite lost, any comment is welcome ;).
Whiteboard: [b2g:blocking+]
It seems we are building rild instead using the one we grab from the device.
Let me explain what I mean a little bit more. I suspect that on ICS we are using the ril blobs we build in the B2G building process instead of using those propietary blobs that we extract from the device. This is because the RIL blobs we get after building and flashing do not accept the RIL request type REQUEST_DIAL_EMERGENCY_CALL. What surprise me is that if I overwrite the libril.ro and libsec-ril.ro with those ones we extracted from the device before building the RIL accepts the request type REQUEST_DIAL_EMERGENCY_CALL.

E/RIL     ( 1835): onRequest: RIL_REQUEST_DIAL_EMERGENCY_CALL
E/RIL     ( 1835): CreateRequest(): req(0x1bf48), id(10016), tok(0x1bf20) - FUNC(0x401bccb1)
E/RIL     ( 1835): [EVT]:Req(1), RX(0)
E/RIL     ( 1835): requestDialEmergencyCall()
E/RIL     ( 1835): requestDialEmergencyCall(): address[112], clir[0]
E/RIL     ( 1835): TxCall_ExecOriginate()
E/RIL     ( 1835): TxCall_ExecOriginate() number[112], number_len=3

So, the question is: Do we grab the propietary RIL blobs off the device and replace the built ones with those for the system image?

I'll file an issue on github in order to shed some light on the problem.
For SGS2, there are some proprietary implementations in binary blobs.  As we have no way to know the detail inside those binary blobs, IMO we should grab them if it works better.
Sorry!  Missed the CC here.

We have a way to force us not building the aosp rild, which we use for akami/maguro but IIRC not sgs2.  This was because the aosp rild didn't link against the akami/maguro libril.  Even so, we should be using the blob rild we pull off device; if there's a proprietary file available, it should win over the one built from the aosp sources when assembling the system image.  If we're not using the blob rild, it's definitely a bug.

For "libsec-ril.so", "sec" means Samsung Electronics Corporation, so if you had that in your build, it was pulled from a phone at some point.  Maybe you're using an ANDROIDFS_DIR that's a little out of date?  Maybe try re-configuring for sgs2?

CC'ing mwu for help with new build system.
See https://github.com/mozilla-b2g/android-device-galaxys2/blob/master/extract-files.sh for the files that we extract. If we need to, we can add libril.so and rild to the list of files extracted.
We already extract rild, libsec-ril.so and libsecril-client.so. First step done (see https://github.com/jaoo/android-device-galaxys2/tree/B2G-issues-18) I extract and use libril.so in my build which allow me to send to the RIL RIL_REQUEST_DIAL_EMERGENCY_CALL parcels. At this point there are other different problems while parsing the REQUEST_GET_CURRENT_CALLS response in ril_worker.js. Working on it.
It seems that the call state on SGS2 phones running ICS also has an extra uint32 in it. The solution is to use the libril.so we extract from the device and take care about the RIL quirk with that extra uint32 in the call state. Patch coming up. With that couple of changes emergency calls work on B2G ICS phones.
Attached patch WIP v1Splinter Review
This patch reverts what philikon did in bug 750592. That step back is because I have been using the proprietary libril.so library. Emergency calls do not work by using the library we build at all. Normal calls both the incoming and outgoing work and even data calls with the proprietary library. It's up to the decision about using the proprietary library instead of using the one we build.
Attachment #628689 - Flags: feedback?(philipp)
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Whiteboard: [b2g:blocking+]
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #9)
> Created attachment 628689 [details] [diff] [review]
> This patch reverts what philikon did in bug 750592. That step back is
> because I have been using the proprietary libril.so library. Emergency calls
> do not work by using the library we build at all. Normal calls both the
> incoming and outgoing work and even data calls with the proprietary library.
> It's up to the decision about using the proprietary library instead of using
> the one we build.

I see. Good sleuthing! I'm ok with this change if we're ok with the build system change for the SGS2.
Comment on attachment 628689 [details] [diff] [review]
WIP v1

r=me if we want to make the changes you described above. Flagging mwu for feedback on that. jaoo, have you submitted a pull request for the build system changes yet?
Attachment #628689 - Flags: review+
Attachment #628689 - Flags: feedback?(philipp)
Attachment #628689 - Flags: feedback?(mwu)
Comment on attachment 628689 [details] [diff] [review]
WIP v1

Sounds fine if it works.
Attachment #628689 - Flags: feedback?(mwu) → feedback+
(In reply to Philipp von Weitershausen [:philikon] from comment #11)
> Comment on attachment 628689 [details] [diff] [review]
> WIP v1
> 
> r=me if we want to make the changes you described above. Flagging mwu for
> feedback on that. jaoo, have you submitted a pull request for the build
> system changes yet?

Pull request submitted.
(In reply to Michael Wu [:mwu] from comment #12)
> Comment on attachment 628689 [details] [diff] [review]
> WIP v1
> 
> Sounds fine if it works.

It would be nice to have a double check on this. Shian-Yow, could you please tell us if you have tested that everything work fine with this change? or Is there someone willing to do this double check?
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #13)
> > r=me if we want to make the changes you described above. Flagging mwu for
> > feedback on that. jaoo, have you submitted a pull request for the build
> > system changes yet?
> 
> Pull request submitted.

Thanks! I will go ahead and land this patch, and then we'll just have to make sure we synchronize the upstreaming of m-c with the landing of https://github.com/mozilla-b2g/android-device-galaxys2/pull/11
https://hg.mozilla.org/mozilla-central/rev/b51ec793e01e
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #14)
> (In reply to Michael Wu [:mwu] from comment #12)
> > Comment on attachment 628689 [details] [diff] [review]
> > WIP v1
> > 
> > Sounds fine if it works.
> 
> It would be nice to have a double check on this. Shian-Yow, could you please
> tell us if you have tested that everything work fine with this change? or Is
> there someone willing to do this double check?

Using libril.so from proprietary binary SGS2-ICS has a side effect which resulted in no audio both ways, this is what I found in my test.

On SGS2-ICS, there was an existing one way audio issue during phone call: https://bugzilla.mozilla.org/show_bug.cgi?id=755405
We believe it's related to audio system, but root cause was not yet found.
Before root cause found, we don't know whether we need libril.so from AOSP or proprietary binary to fix the audio issue.  So either ways seems ok to me at this moment, but we may need to change it depending on investigating result of bug 755405.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: