If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[B2GDroid] Alarm menu is blank.

RESOLVED FIXED in Firefox 44

Status

Firefox OS
General
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Johnt, Assigned: reuben)

Tracking

unspecified
FxOS-S9 (16Oct)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(firefox44 fixed, b2g-master unaffected)

Details

(Whiteboard: [3.0-Daily-Testing], URL)

Attachments

(2 attachments, 5 obsolete attachments)

(Reporter)

Description

2 years ago
Created attachment 8617017 [details]
logcat_20150608_1703.txt

Description:
After opening the Clock app the menues for the Alarm tab will be blank. The Timer and Stopwatch tabs appear to working correctly.


Repro Steps:
1) Update to B2GDroid 20150608071805
2) Select Clock.
3) Select Alarm Tab.


Actual:
Alarm tab is blank.

Expected:
It is expected the user will be able to add and customize alarms with visible options.


Repro frequency: 100%.
Attachments: Logcat, Video
(Reporter)

Comment 1

2 years ago
This issue does NOT occur on the Flame 3.0.

Result: User is able to view and select Alarms options successfully.

Environmental Variables:
Device: Flame 3.0 Kitkat Full Flash (319mb) 
Build ID: 20150608010204
Gaia: 1d62b32408567f9f7cf1c71c1e5a0c6593be757b
Gecko: 7d4ab4a9febd
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Blocks: 1170323
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-master: --- → unaffected
Flags: needinfo?(ktucker)
Whiteboard: [3.0-Daily-Testing]
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(Assignee)

Updated

2 years ago
Assignee: nobody → reuben.bmo
(Assignee)

Comment 2

2 years ago
Created attachment 8640224 [details] [diff] [review]
Enable the Alarms API on B2GDroid

Not rocket science :)
Right, but we don't have the hal support on android for the alarm api afaik.
(Assignee)

Comment 4

2 years ago
Yeah, this will at least make it work for now with the fallback impl until we figure that out. (And would be needed anyway.)
What do you mean by "work"? will alarms fire?
(Assignee)

Comment 6

2 years ago
Yes. Though I didn't test with very long alarms.
(Assignee)

Comment 7

2 years ago
Created attachment 8640825 [details] [diff] [review]
HAL alarm for Android
Attachment #8640224 - Attachment is obsolete: true
(Assignee)

Comment 8

2 years ago
Created attachment 8658493 [details] [diff] [review]
Implement Android HAL backend for alarms
Attachment #8640825 - Attachment is obsolete: true
Attachment #8658493 - Flags: review?(snorp)
(Assignee)

Updated

2 years ago
Duplicate of this bug: 1202864
Comment on attachment 8658493 [details] [diff] [review]
Implement Android HAL backend for alarms

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

::: widget/android/AndroidJNI.cpp
@@ +164,5 @@
>      NS_DispatchToMainThread(runnable);
>  }
>  
> +NS_EXPORT void JNICALL
> +Java_org_mozilla_gecko_GeckoAppShell_notifyAlarmFired(JNIEnv* jenv, jclass)

We're trying to avoid new calls here, and are actively moving existing things out. I think you should be able to handle the native call in AndroidAlarm.cpp. See ANRReporter.cpp/h for an example.
Attachment #8658493 - Flags: review?(snorp) → review-
(Assignee)

Comment 11

2 years ago
Created attachment 8661358 [details] [diff] [review]
Implement Android HAL backend for alarms, v2

Now using the GeneratedJNINatives stuff.
Attachment #8658493 - Attachment is obsolete: true
(Assignee)

Updated

2 years ago
Attachment #8661358 - Flags: review?(snorp)
Comment on attachment 8661358 [details] [diff] [review]
Implement Android HAL backend for alarms, v2

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

Much nicer, but I think we can avoid the init call in nsAppShell. You should be able to do it in SetAlarm instead, since the Java side won't be calling the native side until that is completed.
Attachment #8661358 - Flags: review?(snorp) → review-
(Assignee)

Comment 13

2 years ago
Created attachment 8662518 [details] [diff] [review]
Implement Android HAL backend for alarms, v3

Seems like hal_impl::EnableAlarm is an even better place to do that. This ended up looking very clean.
Attachment #8661358 - Attachment is obsolete: true
Attachment #8662518 - Flags: review?(snorp)
Comment on attachment 8662518 [details] [diff] [review]
Implement Android HAL backend for alarms, v3

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

really nice, thanks
Attachment #8662518 - Flags: review?(snorp) → review+
(Assignee)

Comment 15

2 years ago
I'm not going to land this just yet - while testing with longer lived alarms, sometimes the BroadcastReceiver's wake lock is not long enough for Gaia to receive the alarm notification, so we'll need to hold a lock ourselves.
(Assignee)

Comment 16

2 years ago
Created attachment 8668258 [details] [diff] [review]
Implement Android HAL backend for alarms, v4

With this we wake up the device and turn the screen on for long lived alarms. The only differences to v3 are the changes to AlarmReceiver.java. I couldn't create an interdiff because this newer one was rebased.
Attachment #8662518 - Attachment is obsolete: true
Attachment #8668258 - Flags: review?(snorp)
Attachment #8668258 - Flags: review?(snorp) → review+

Comment 17

2 years ago
https://hg.mozilla.org/integration/b2g-inbound/rev/b0b053cb93e5
https://hg.mozilla.org/mozilla-central/rev/b0b053cb93e5
Status: NEW → RESOLVED
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S9 (16Oct)

Updated

2 years ago
Duplicate of this bug: 1202899
You need to log in before you can comment on or make changes to this bug.