877751 - [CBS] [User Story] Handle Broadcast Message Classes 0 and 1 [IOT blocker]

Status: RESOLVED FIXED

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

Description

[Andreas Gal :gal]

+++ This bug was initially created as a clone of Bug #874801 +++

As an operator and as a user I expect the different class of cell Broadcast messages to be handled according to specification.

Class 0: to be displayed immediately (even on a locked screen) , user must have option to dismiss, save or delete the message; user must be able to scroll through long messages and user must be notified with an audible alert when the message arrives on the device.

Class 1:  to be handled the same way as class 1 SMS message - and should be displayed to the user and user must have option to delete or save the message

Class 0 and 1 are mandatory for 1.1 IOT and we will handle them here. The original bug handles the other two classes (in case we need to handle them, looks like the modem already does).

Comment 1

[Dale Harvey (:daleharvey)]

I am currently working on class 0, there is a conflict between the UX spec and the requirements above, 

> user must have option to dismiss, save or delete the message;

If we can save messages then we surely need the ability to view old messages, the current UX spec has a single 'dismiss' button.

If we require the ability to view historical messages I suggest that both class 0 and 1 messages are treated as sms messages, with class 0 having the extra functionality of showing the immediate modal alert.

I am currently working on the modal alert, however how we handle messages to be treated as sms messages I am not sure about, cc'ing some people who work on sms, we most certainly dont have time to write a new api for CBS, transforming them into the sms api in gecko seems nasty, it may be possible to handle chromeevents in system and have system control sms, but that also doesnt sound trivial

Comment 2

[Andreas Gal :gal]

Notifications might be a sufficiently "model" UI here

Comment 3

[Andreas Gal :gal]

"model" = "modal"

Comment 4

[Dale Harvey (:daleharvey)]

Attachment: LockScreen notifications

Comment 5

[Dale Harvey (:daleharvey)]

Attachment: Main Screen notifications

Comment 6

[Andreas Gal :gal]

We need some carrier feedback here. Comment 4 links the notifications we get on the lock screen. Comment 5 links the notifications we get when the phone is in use. The notifications in comment 5 auto-hide after a few seconds (we could disable that for CB messages if absolutely needed). Would it pass IOT if we use this mechanism to notify the user? We use notifications and when you click on them it takes you to the SMS app where you can see the full message (in case it was truncated).

Comment 7

[Andreas Gal :gal]

Daniel, could Brazil use the same mechanism as comment 6?

Comment 8

[Andreas Gal :gal]

We are considering the following approach:

- Turn CB messages into class 0 SMS in gecko and the system app.
- Have the regular SMS pass handle CB on the lock screen and while the phone is in use (potentially disabling auto-hiding of notification if mandatory).
- Delete the special path for Brazil and use the notifications shown above for Brazil and PL.
- Delete the CB API in DOM since we will simply handle them as class 0 SMS.

Does this make sense?

Comment 9

[Dale Harvey (:daleharvey)]

Some notes about the current implementation just in case I need to be corrected:

If we receive a message via the navigator.mozCellBroadcast api, it will only be shown on the lockscreen and only if we are not on emergencycallsonly (and are connected), it will display there until the phone is restarted (or a new cbs message is received)

If we receive a class-0 sms message, it will not display a notification, it will attempt to bring the sms app to the foreground and display the message as a modal alert which can be disregarded (and the message is deleted)

Comment 10

[Michael Schwartz [:m4]]

Attachment: Android CBS screenshot

Comment 11

[Vicamo Yang [:vicamo][:vyang]]

By 3GPP TS 23.038 chapter 5 "CBS Data Coding Scheme", the only difference between Class 0 and Class 1 is "Class 0 messages shall not be automatically stored in the (U)SIM or ME".  That's the only Gecko shall do.

CBS is not SMS.  We can merge mozCellBroadcast into mozMobileMessage, but we should not turn a CB message into a SMS one.  There is a lot differences between two message types. ETWS info/language/messageId/popup/emergencyUserAlert are only available for CBS, and sender/receipients are only available to SMS.  Besides, don't forget Cost Control also involves.

Comment 12

[Andreas Gal :gal]

Thanks Vicamo. Good points. We will need the separate interface unfortunately.

Also, m4, thanks for the screen shot. Looks like we do need a modal dialog after all. We currently have some broken code for that for class 0 SMS. We can fix that code path and do a similar modal dialog for CB. Dale, can you get to work on this tomorrow? We can use the same code we have in the lock screen for the lock screen I guess. Its not pretty, but it probably does the trick.

Comment 13

[Dale Harvey (:daleharvey)]

clearing needinfo

Comment 14

[Dale Harvey (:daleharvey)]

Attachment: Pointer to GH

Comment 15

[Dale Harvey (:daleharvey)]

Copying the commit message here for comment

We do not distinguish between message classes as specified (and
previously implemented).

If a message is received while in the lockscreen then a notification
is sent which wakes the screen, sounds a notification and displays
it on the lock screen, clicking on the notification will then show
a dialog with a full message.

If we are currently using the device the dialog will be displayed
immediately.

Discussed with Andreas and this looked like the best solution that 
satisfied the requirements for certification and carried the least 
risk as any changes to the system app (especially introducing new 
UI mechanisms) carry a lot of risk, this currently reuses existing
and tested features of the system app.

Comment 16

[Dale Harvey (:daleharvey)]

needinfoing Alex due to string changes

Comment 17

[Andreas Gal :gal]

Daniel this changes the Brazil CB path (to the better I think, but I want to make sure you sign off on this).

Comment 18

[Daniel Coloma:dcoloma]

(In reply to Andreas Gal :gal from comment #17)
> Daniel this changes the Brazil CB path (to the better I think, but I want to
> make sure you sign off on this).

I don't think this satisfies ANATEL requirement. The message in the Idle Screen must be always shown as it indicates to the user the State in which he is currently registered which is essential to understand whether internal-roaming charges apply and the tax to be applied. I am going to look for the documentation and double check, but my initial feedback is that is is not valid for Brazil.

Comment 19

[Andreas Gal :gal]

This only changes CB messages. Does Brazil use CB to indicate roaming?

Comment 20

[Dale Harvey (:daleharvey)]

I dont think it would be too redundant to reinstate the original display on the lockscreen (its quite inconspicuous) in addition to the notification.

Comment 21

[Daniel Coloma:dcoloma]

(In reply to Andreas Gal :gal from comment #19)
> This only changes CB messages. Does Brazil use CB to indicate roaming?

Yes it does. Brazil operators broadcast that info (all carriers do), on the 2G network, using standard Cell Broadcast on channel 50 (that's configured on the SIM Card). The CB payload (like "VIVO RJ 21") is directly displayed in the homescreen (I will attach Android screenshot).

Comment 22

[Daniel Coloma:dcoloma]

Attachment: CB in Brazil (Android)

Comment 23

[Andreas Gal :gal]

Super strange and sorta clever actually. Makes sense. Thanks for the clarification. We can in that case simply keep both paths and enable them for Brazil and PL separately. Dale, can you fix this up? Thanks.

Comment 24

[Axel Hecht [:Pike]]

I don't know where the needinfo myth comes from. Post to .gaia coming up shortly.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 756854 [details]
Pointer to GH

Looks like something need to be fixed per request,
though I'm not sure what's needed here.

As I commented in github, the modal dialog layer is not the highest one.
You should inform other modules w/ higher z-index to hide their current overlay to guarantee the user will see the broadcast message.

Comment 26

[Andreas Gal :gal]

Dale, Android seems to always treat channel 50 differently, so just route channel 50 always to the lock screen and the rest goes into the new code path.

Comment 27

[Dale Harvey (:daleharvey)]

Sounds good, will get a new patch up asap, cheers alive as well

Comment 28

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 756854 [details]
Pointer to GH

it made lockscreen more clear, r+ for me

BTW, I tested it with |CellBroadcastSystem.show({message: {body: 'test'}})| on nightly browser, both looks good on locked & unlocked state.

please set review flag to alive again when you updated the pull request.

Comment 29

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

and Dale, I found your implementation removed Cellbroadcast information from connection status bar which implemented on bug 823650.

are you sure we need to remove that?

Comment 30

[Daniel Coloma:dcoloma]

(In reply to Yuren Ju [:yurenju] from comment #29)
> and Dale, I found your implementation removed Cellbroadcast information from
> connection status bar which implemented on bug 823650.
> 
> are you sure we need to remove that?

We must not remove that at least for Brazil, what was added in bug 823650 was for meeting ANATEL certification.

Comment 31

[Dale Harvey (:daleharvey)]

Yup, taking it out was intentional but it was clarified that it needed to be reinstanted

Comment 32

[Dale Harvey (:daleharvey)]

Comment on attachment 756854 [details]
Pointer to GH

I restored the previous functionality of displaying channel 50 CB messages on the lockscreen, all other messages go through alerts, I also added a sound notification to the alert (non overridable) and created a new event which hides in progress calls or the utility tray. 

Alive this is fairly urgent so if you could look at this asap it would great, I'll make sure to follow up promptly.

Comment 33

[Dale Harvey (:daleharvey)]

Daniel, just checking you are happy with this

Comment 34

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 756854 [details]
Pointer to GH

r=me, please see github comments.

Comment 35

[Dale Harvey (:daleharvey)]

Thanks a lot Alive, agreed on all the comments and have updated the PR, will merge when I hear back from Daniel

Comment 36

[Dale Harvey (:daleharvey)]

Attachment: Settings Screenshot

What it currently looks like in settings

Comment 37

[Dale Harvey (:daleharvey)]

I thought settings was a seperate bug but it isnt so amended it into this one

This adds a new option inside the 'Call Settings' header with the label 'Cell broadcast service', which can be toggled on or off, by default it is enabled, the settings location and label are very similiar to the android implementation.

The setting only applied to the CB alerts, the existing channel 50 lockscreen display will be unaffected by this setting, otherwise the setting simply disabled and enables the display of CB notifications.

Comment 38

[Anshul]

Dale, the bug for cell broadcast setting is bug 874796. Let's use the bug 874796 for the setting to avoid any confusion with this bug.

Comment 39

[Dale Harvey (:daleharvey)]

ah sorry missed that bug, will revert and commit this and put the settings only patch in a the other bug

Comment 40

[Daniel Coloma:dcoloma]

Dale, I've just being told that CB as required by ANATEL in Brazil is not working in 1.1 (however, it is working in 1.0.1). David has opened bug 879955 to track it.

Comment 41

[Dale Harvey (:daleharvey)]

Comment on attachment 756854 [details]
Pointer to GH

clearing, will be on new bug

Comment 42

[Dale Harvey (:daleharvey)]

Merged in https://github.com/mozilla-b2g/gaia/commit/7be0dfa9519d94a8f7b8b464f9805dd7a11faeb9

Comment 43

[John Ford [:jhford] CET/CEST Berlin Time]

Uplifted 7be0dfa9519d94a8f7b8b464f9805dd7a11faeb9 to:
v1-train: 9d0072b4a34e183b9ea20cd7cbe1457708aa0280