Closed Bug 1019783 Opened 10 years ago Closed 10 years ago

Output from *#06# on FLAME DIALER used to return 2 IMEI

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, b2g-v1.3 wontfix, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

RESOLVED FIXED
2.0 S6 (18july)
blocking-b2g 1.4+
Tracking Status
b2g-v1.3 --- wontfix
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: retornam, Assigned: gsvelto)

References

Details

(Keywords: regression, Whiteboard: [sprd319109][planned-sprint][in-sprint=v2.0-S5])

Attachments

(4 files, 2 obsolete files)

STR:

Gaia      ec462dc62979dae593b4ad96ac3851ccbafe1813
Gecko     b637b0677e15318dcce703f0358b397e09b018af
BuildID   20140505215459
Version   28.0
ro.build.version.incremental=87
ro.build.date=Mon May  5 20:19:07 CST 2014


Flash the build above on to your FLAME phone, it returns two IMEI



Now flash 

Gaia      ba8d7ef46cadf5d66d189b0b036d0f2e936bece0
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/384d3410a854
BuildID   20140602000203
Version   30.0
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014


enter *#06# on the dialer. It returns one IMEI


My question is are the FLAMES supposed to return 2 IMEI or one?
IIRC currently we should get only one IMEI, the one associated with the SIM card used for outgoing calls. If you're getting the same IMEI on both cards then something's wrong, similarly receiving two IMEIs doesn't seem right to me.
(In reply to Gabriele Svelto [:gsvelto] from comment #1)
> IIRC currently we should get only one IMEI, the one associated with the SIM
> card used for outgoing calls. If you're getting the same IMEI on both cards
> then something's wrong, similarly receiving two IMEIs doesn't seem right to
> me.

I ran tests again using the following steps:

1) No SIM card installed

    The first build showed two IMEI since the FLAME phone has two SIM-card slots.
    The second build showed only one.

2) One SIM card installed.
    The first build showed two IMEI
    The second build showed one.

3) Two SIM cards installed.
    The first build showed two IMEI
    The second build showed one.



AFAIK, the standard behavior of devices with two SIM card slots is to show both IMEI when *#06# is entered.


Naoki, what do you think?
Flags: needinfo?(nhirata.bugzilla)
I believe that Raymond is correct.  Bug 1008737 indicates that we should have 2 IMEIs.
We also have a tool from a Vendor for a different dual SIM device to reset IMEI for both slots.

I asked Raymond to double check if having SIMs in the device makes a difference.  Based on his testing, it sounds like both IMEI should show regardless of 2, 1 or 0 SIMs.

Raymond, are both SIMs detected?  or is only one SIM detected?

We also need to determine if somehow one of the IMEI got wiped.  We have had that after flashing for various other devices.  I am unsure if this would show in the logcat or dmesg even with RIL debugging turned on... maybe Alexandre or someone else could help in regards to figuring out how to see if the second IMEI got wiped or not?
Flags: needinfo?(nhirata.bugzilla) → needinfo?(lissyx+mozillians)
Gabriele worked on this. I don't know the APIs there.
Flags: needinfo?(lissyx+mozillians) → needinfo?(gsvelto)
I'm even wondering if it may not be a QCRIL thing, to return the two IMEIs.
Blocks: 1020166
According to gsvelto, this is a dupe of bug 1019370.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Flags: needinfo?(gsvelto)
After some further discussion it turns out that this is a bug of its own: the previous behavior of returning two IMEI numbers when dialing '*#06#' irrespective of the SIMs is what we should get here. I'm reopening this to track a fix for this particular issue.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
blocking-b2g: --- → 1.4+
Is it the same as bug 1002327?
Depends on: 1002327
Whiteboard: [sprd319109]
Assignee: nobody → gsvelto
Target Milestone: --- → 2.0 S5 (4july)
Whiteboard: [sprd319109] → [sprd319109][planned-sprint]
(In reply to Gabriele Svelto [:gsvelto] from comment #7)
> After some further discussion it turns out that this is a bug of its own:
> the previous behavior of returning two IMEI numbers when dialing '*#06#'
> irrespective of the SIMs is what we should get here. I'm reopening this to
> track a fix for this particular issue.

Hi, Gabrielle, can we have your latest update? I saw the target milestone was configured as sprint 5. 
Are we still expecting to fix this by July 4th? Thank you!
Flags: needinfo?(gsvelto)
(In reply to Kevin Hu [:khu] from comment #10)
> (In reply to Gabriele Svelto [:gsvelto] from comment #7)
> Hi, Gabrielle, can we have your latest update? I saw the target milestone
> was configured as sprint 5. 
> Are we still expecting to fix this by July 4th? Thank you!

I still hope so, I'm about to finish bug 1016885 and I'll work on this next.
Flags: needinfo?(gsvelto)
I was unable to repro the expected behavior on the given build ID, a build from a few days before that, or the earliest build available on Flame (2014-04-22-16-02-03), when flashing both Gecko and Gaia from those dates. Every build I tried only gave me one IMEI. Also, it's showing me one IMEI no matter how many SIMs I have in the device.

Raymond, do you know if there are any additional STR? Maybe a specific version of firmware or something?
Flags: needinfo?(mozbugs.retornam)
(In reply to Doug Sherk (:drs) from comment #12)
> I was unable to repro the expected behavior on the given build ID, a build
> from a few days before that, or the earliest build available on Flame
> (2014-04-22-16-02-03), when flashing both Gecko and Gaia from those dates.
> Every build I tried only gave me one IMEI. Also, it's showing me one IMEI no
> matter how many SIMs I have in the device.
> 
> Raymond, do you know if there are any additional STR? Maybe a specific
> version of firmware or something?


No. I'm not the only one who could reproduce this with the STR I used.
Flags: needinfo?(mozbugs.retornam)
(In reply to raymond [:retornam] (needinfo? me) from comment #13)
> No. I'm not the only one who could reproduce this with the STR I used.

So just to be clear, they were able to repro it behaving with the expected behavior in build ID 20140505215459 and before that?
Flags: needinfo?(mozbugs.retornam)
(In reply to Doug Sherk (:drs) from comment #14)
> (In reply to raymond [:retornam] (needinfo? me) from comment #13)
> > No. I'm not the only one who could reproduce this with the STR I used.
> 
> So just to be clear, they were able to repro it behaving with the expected
> behavior in build ID 20140505215459 and before that?


I dont have the exact build ID but I've seen the expected behavior described in  comment #7 on previous builds.
Flags: needinfo?(mozbugs.retornam)
QA Wanted to retest on the latest 1.4 to confirm this still reproduces.
Keywords: qawanted
Quick update: the current RIL code returns only the IMEI code of the associated connection when calling MobileConnection.sendMMI('*#06#'). I think this is a sensible choice so I'll prepare a gaia patch to fix this bug instead. The idea is to iterate over all connections, retrieve the IMEI codes and then display them all.
Whiteboard: [sprd319109][planned-sprint] → [sprd319109][planned-sprint][dialer-in-sprint=v2.0-S5]
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
Whiteboard: [sprd319109][planned-sprint][dialer-in-sprint=v2.0-S5] → [sprd319109][planned-sprint][in-sprint=v2.0-S5]
Hi Gabriele,

Is this the same patch you prepared in bug 1002327? 

(In reply to Gabriele Svelto [:gsvelto] from comment #17)
> Quick update: the current RIL code returns only the IMEI code of the
> associated connection when calling MobileConnection.sendMMI('*#06#'). I
> think this is a sensible choice so I'll prepare a gaia patch to fix this bug
> instead. The idea is to iterate over all connections, retrieve the IMEI
> codes and then display them all.
Flags: needinfo?(gsvelto)
(In reply to Wayne Chang [:wchang] from comment #18)
> Is this the same patch you prepared in bug 1002327? 

No, that patch only made the MMI code multi-SIM aware (previously it would deal with MMI/USSD only on the first SIM). I'm preparing a dedicated patch for this.
Flags: needinfo?(gsvelto)
This patch special-cases requesting the *#06# MMI code in the dialer so that typing it always returns IMEI codes for all SIM slots and not only for the one set as default for outgoing calls.

The code used to request only one code at a time was removed as it's not used anymore.

The new functionality is covered with unit-tests (which are a bit ugly but functional) and this has been tested on a Flame.
Attachment #8452999 - Flags: review?(anthony)
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
I made a silly mistake in my previous patch so it wouldn't work if you didn't have SIM cards inserted in all slots; with a small fix this now works irrespective of the number of SIMs you have in your phone or if you have none at all.
Attachment #8452999 - Attachment is obsolete: true
Attachment #8452999 - Flags: review?(anthony)
Attachment #8453122 - Flags: review?(anthony)
Comment on attachment 8453122 [details] [diff] [review]
[PATCH v2] Always display IMEI codes for all SIM slots

Review of attachment 8453122 [details] [diff] [review]:
-----------------------------------------------------------------

The logic is sound and the use of promises makes it lovely to use.

I mostly have stylistic comments. r- for the missing test though.

::: apps/communications/dialer/js/dialer.js
@@ +367,5 @@
>    /* === Calls === */
>    function call(number, cardIndex) {
>      if (MmiManager.isMMI(number, cardIndex)) {
> +      if (number === '*#06#') {
> +        MmiManager.showImei();

We need a test for this change.

::: apps/communications/dialer/js/mmi.js
@@ +422,5 @@
> +   * @returns {Promise} A promise that is resolved when the operation has been
> +   *          completed.
> +   */
> +  showImei: function mm_showImei() {
> +    function mm_getImeiPromise(cardIndex) {

Put this in a function called '_getImeiForCard' outside the scope of this one.

@@ +451,5 @@
> +    return new Promise(function(resolve, reject) {
> +      self.init(function() {
> +        var promises = [];
> +
> +        if (navigator.mozMobileConnections) {

I don't think we need to guard against this.

::: apps/communications/dialer/test/unit/mmi_test.js
@@ +554,5 @@
>      });
>    });
>  
> +  suite('Retrieving IMEI codes', function() {
> +    test('Getting the IMEI code of a single SIM device', function(done) {

'for a single SIM device' will read better in the output of tests. It is repetitive otherwise.

@@ +575,5 @@
> +        target: { result: { serviceCode: 'scImei', statusMessage: 123 } }
> +      });
> +    });
> +
> +    test('Getting the IMEI code of a multi-SIM device', function(done) {

for a multi-SIM device
Attachment #8453122 - Flags: review?(anthony) → review-
Updated patch with comments addressed and further unit-tests added.
Attachment #8453122 - Attachment is obsolete: true
Attachment #8453610 - Flags: review?(anthony)
Comment on attachment 8453610 [details] [diff] [review]
[PATCH v3] Always display IMEI codes for all SIM slots

Review of attachment 8453610 [details] [diff] [review]:
-----------------------------------------------------------------

The multi-sim tests need to be addressed either here or in a follow up. The stylistic changes are up to you :)

::: apps/communications/dialer/test/unit/dialer_test.js
@@ +402,5 @@
> +      });
> +
> +      test('> Dialing a generic code', function() {
> +        var number = '*123#';
> +        CallHandler.call(number, 0);

We need to test with each SIM. See https://github.com/mozilla-b2g/gaia/blob/990bb2c47c6484c8b2d7e78ac77e9e2f61214e60/apps/communications/dialer/test/unit/call_log_test.js#L813 for an easy way to do so. You can do that in a followup if preferred.

@@ +404,5 @@
> +      test('> Dialing a generic code', function() {
> +        var number = '*123#';
> +        CallHandler.call(number, 0);
> +
> +        // We send the MMI message and clear the phone number / suggestion bar.

This comment is a sign that you've finished setting up your test and you are now testing.

suite('> Dialing a generic code', function() {
  setup();
  test('> sends a MMI message');
  test('> clears the phone number');
});
will read better.

@@ +410,5 @@
> +        sinon.assert.calledWithMatch(MockKeypadManager.updatePhoneNumber, '');
> +        sinon.assert.calledOnce(MockSuggestionBar.clear);
> +      });
> +
> +      test('> Requesting the IMEI codes', function() {

Same comments for each SIM and readability.

::: apps/communications/dialer/test/unit/mock_suggestion_bar.js
@@ +1,1 @@
> +/* exported MockSuggestionBar */

I'm surprised we didn't have a mock for this yet. Good addition!
Attachment #8453610 - Flags: review?(anthony) → review+
(In reply to Anthony Ricaud (:rik) from comment #25)
> We need to test with each SIM. See
> https://github.com/mozilla-b2g/gaia/blob/
> 990bb2c47c6484c8b2d7e78ac77e9e2f61214e60/apps/communications/dialer/test/
> unit/call_log_test.js#L813 for an easy way to do so. You can do that in a
> followup if preferred.

OK, I'll add code to check on both SIMs.

> This comment is a sign that you've finished setting up your test and you are
> now testing.
> 
> suite('> Dialing a generic code', function() {
>   setup();
>   test('> sends a MMI message');
>   test('> clears the phone number');
> });
> will read better.

Yes but I'd rather not explode the checks in a lot of small tests. It tends to slow down the unit-tests a lot.
I've pushed an updated patch to the branch. I'll wait for the Try/Travis run to turn green before merging:

https://tbpl.mozilla.org/?rev=9d1426568e770293b736747f0246a3768582b3ce&tree=Gaia-Try
https://travis-ci.org/mozilla-b2g/gaia/builds/29586524
Landed on gaia/master c329a67bafe60032820ab64b52c07c22eeff114e

https://github.com/mozilla-b2g/gaia/commit/c329a67bafe60032820ab64b52c07c22eeff114e
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
I'll be waiting before uplifting to v2.0 until the last part of bug 1002327 gets approval.
Keywords: qawanted
Uplifted to gaia/v2.0 1bd6e8957ccf310b2f75ba5695b058a2e284df3a

https://github.com/mozilla-b2g/gaia/commit/1bd6e8957ccf310b2f75ba5695b058a2e284df3a
I still get only 1 IMEI back with this build..

flame v2.0 aurora
Gaia      2c6c413ed729d465c52d6c2d5d458e2eee79e956
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/d32649a24965
BuildID   20140714160201
Version   32.0a2
ro.build.version.incremental=112
ro.build.date=Mon Jul 14 14:57:32 CST 2014
(In reply to Eric Chang [:ericcc] [:echang] from comment #32)
> I still get only 1 IMEI back with this build..

Ugh, that's because I've mixed up the uplifts and actually haven't uplifted this one yet.
Here's a modified patch that works on v1.3t, this basically gets rid of promises and uses callbacks instead to retrieve the IMEI codes. Etienne can you give this a spin on your Tarako? On mine it returns both IMEI codes but they're both all zeroes so I want to be sure that's OK and not a side-effect of my patch. Also shall we nom this for 1.3T? in order to land? The fix here should really have been part of bug 1002327 which was 1.3T+ but due to a misunderstanding on my part it end up split between that bug and this one.
Flags: needinfo?(etienne)
Sorry for the delay, it works perfectly and shows 2 different IMEIs that aren't 000000.

Cheers!
Flags: needinfo?(etienne)
OK, I've landed attachment 8460888 [details] [diff] [review] in gaia/v1.3t 740923380878dfcc48295698761b1136b33d1ae2

Note that I didn't ask for approval because this should have really been part of bug 1002327 which is 1.3T+ but due to a misunderstanding on my part I split the work between that bug and this one.
Attached video Verify_Video_Flame.MP4
This issue has been verified successfully on Flame 2.0 & 2.1.
The three conditions as follows:
1) No SIM card installed
2) One SIM card installed.
3) Two SIM cards installed.

Enter *#06# on the Dialer, it will return 2 IMEI.

See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        ead3b72a84512750bc5faff4e9e8faa1715c0d05
Gecko-Rev       c715df57d1d1593ede48140ebc88e101f8c3f7da
Build-ID        20141208050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2

Flame v2.1 version:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        ead3b72a84512750bc5faff4e9e8faa1715c0d05
Gecko-Rev       c715df57d1d1593ede48140ebc88e101f8c3f7da
Build-ID        20141208050313
Version         32.0
Device-Name     jrdhz72_w_ff
FW-Release      4.4.2

Flame v2.1 version:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: