Closed
Bug 1069862
Opened 10 years ago
Closed 10 years ago
MozMobileConnection.getCallBarringOption() with a specific serviceClass doesn't work on some operator
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
2.1 S6 (10oct)
People
(Reporter: aknow, Assigned: aknow)
References
Details
Attachments
(1 file, 1 obsolete file)
2.67 KB,
patch
|
aknow
:
review+
|
Details | Diff | Splinter Review |
Consider to have a workaround solution to cover the case. In gecko implementation, we could always use serviceClass=0 in ril request no matter what is given from api user. Then process the ril response to return the result for that serviceClass asked by user.
Assignee | ||
Updated•10 years ago
|
Summary: Get call barring options with specific serviceClass doesn't work on some operator → MozMobileConnection.getCallBarringOption() with a specific serviceClass doesn't work on some operator
Comment 1•10 years ago
|
||
(In reply to Szu-Yu Chen [:aknow] from comment #0) > Consider to have a workaround solution to cover the case. > > In gecko implementation, we could always use serviceClass=0 in ril request > no matter what is given from api user. Then process the ril response to > return the result for that serviceClass asked by user. I rethink about it... As title, this is operator-specific but I doubt how we could have a solution/workaround for all operators on reference phones. As we don't even have a clear definition of the meaning of serviceClass 0, I am concerned whether serviceClass 0 works for all operators. Could it possibly break the original behavior that is working on specifying a certain serviceClass? Unless we have more ideas about the semantic of serviceClass 0, I tend to close this bug as WONTFIX :(
Assignee | ||
Comment 2•10 years ago
|
||
(In reply to Hsin-Yi Tsai (OOO Sep. 22) [:hsinyi] from comment #1) > (In reply to Szu-Yu Chen [:aknow] from comment #0) > > Consider to have a workaround solution to cover the case. > > > > In gecko implementation, we could always use serviceClass=0 in ril request > > no matter what is given from api user. Then process the ril response to > > return the result for that serviceClass asked by user. > > I rethink about it... As title, this is operator-specific but I doubt how we > could have a solution/workaround for all operators on reference phones. As > we don't even have a clear definition of the meaning of serviceClass 0, I am > concerned whether serviceClass 0 works for all operators. Could it possibly > break the original behavior that is working on specifying a certain > serviceClass? Unless we have more ideas about the semantic of serviceClass > 0, I tend to close this bug as WONTFIX :( In current design, MMI code like "*#33#" will be implemented by using serviceClass 0. That means if serviceClass 0 doesn't work for all operators, we should also get the problem when sending this MMI code.
Comment 3•10 years ago
|
||
(In reply to Szu-Yu Chen [:aknow] from comment #2) > (In reply to Hsin-Yi Tsai (OOO Sep. 22) [:hsinyi] from comment #1) > > (In reply to Szu-Yu Chen [:aknow] from comment #0) > > > Consider to have a workaround solution to cover the case. > > > > > > In gecko implementation, we could always use serviceClass=0 in ril request > > > no matter what is given from api user. Then process the ril response to > > > return the result for that serviceClass asked by user. > > > > I rethink about it... As title, this is operator-specific but I doubt how we > > could have a solution/workaround for all operators on reference phones. As > > we don't even have a clear definition of the meaning of serviceClass 0, I am > > concerned whether serviceClass 0 works for all operators. Could it possibly > > break the original behavior that is working on specifying a certain > > serviceClass? Unless we have more ideas about the semantic of serviceClass > > 0, I tend to close this bug as WONTFIX :( > > In current design, MMI code like "*#33#" will be implemented by using > serviceClass 0. That means if serviceClass 0 doesn't work for all operators, > we should also get the problem when sending this MMI code. Oh, yup... thanks for the reminding. Then I am fine with this workaround, thank you Aknow.
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8495736 -
Flags: review?(htsai)
Comment 5•10 years ago
|
||
Comment on attachment 8495736 [details] [diff] [review] Use serviceClass 0 to query callbarring option Review of attachment 8495736 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, thank you.
Attachment #8495736 -
Flags: review?(htsai) → review+
Assignee | ||
Comment 6•10 years ago
|
||
https://tbpl.mozilla.org/?tree=Try&rev=07e75c1c1921
Attachment #8500346 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Attachment #8495736 -
Attachment is obsolete: true
Comment 7•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/0c22e43c9e77
Keywords: checkin-needed
Comment 8•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0c22e43c9e77
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S6 (10oct)
You need to log in
before you can comment on or make changes to this bug.
Description
•