Update MHC19Q.2016.04.06.11.37.02 broke the alarm clock

[christoph-buente]

I was not woken up by my alarm this morning and was wondering what went wrong. I investigated the issue and set the alarm clock 1 minute ahead. What happened is, that the alarm goes off for less than a second and then the alarm clock crashes. When i try to go to the alarm clock settings, the whole clock app crashes. This behaviour is repeatable every single time, i tried it several times. I know it's an upstream app, but i don't know if there have been any changes to it recently by you. Can you confirm the alarm clock works just fine?

Thx

[thestinger]

It works here. Can you do adb logcat -c to clear the logs, then make it crash, then provide those logs from adb logcat -d?

[thestinger]

It works here. Can you do adb logcat -c to clear the logs, then make it crash, then provide those logs from adb logcat -d?

[christoph-buente]

Sure, here you go.
clock_crash_log.txt

[christoph-buente]

Sure, here you go.
clock_crash_log.txt

[thestinger]

Which locale are you using? German? It seems that the translation is broken in the upstream DeskClock.

[thestinger]

Which locale are you using? German? It seems that the translation is broken in the upstream DeskClock.

[christoph-buente]

Yes, it's German. I actually also saw broken translations in the popup, when the alarm will go off.
I'll switch to english for now.

[christoph-buente]

Yes, it's German. I actually also saw broken translations in the popup, when the alarm will go off.
I'll switch to english for now.

[thestinger]

I don't know how to fix this. Reverting the translation updates will just break it in other ways.

[thestinger]

I don't know how to fix this. Reverting the translation updates will just break it in other ways.

[thestinger]

The only sane approach I can think of is removing all of the translations for DeskClock. I don't want to have a messy manual partial revert that I'll need to maintain, and the extent of the problems is unclear.

[thestinger]

The only sane approach I can think of is removing all of the translations for DeskClock. I don't want to have a messy manual partial revert that I'll need to maintain, and the extent of the problems is unclear.

[christoph-buente]

I switched to english language, rebooted the phone. Same behavior. Here is a log, when i try to confirm the alarm by swiping left or right.
clock_english_crash_log.txt

[christoph-buente]

I switched to english language, rebooted the phone. Same behavior. Here is a log, when i try to confirm the alarm by swiping left or right.
clock_english_crash_log.txt

[thestinger]

That's a separate issue and it's also not something caused by CopperheadOS. DeskClock in AOSP is clearly on life support. Google is pushing lots of changes from their extended internal version without any of it being tested in AOSP.

[thestinger]

That's a separate issue and it's also not something caused by CopperheadOS. DeskClock in AOSP is clearly on life support. Google is pushing lots of changes from their extended internal version without any of it being tested in AOSP.

[thestinger]

I don't consider fixing bugs in AOSP apps to be in-scope for CopperheadOS. I can't maintain these apps for Google if they're neglecting them. There are other clocks.

[thestinger]

I don't consider fixing bugs in AOSP apps to be in-scope for CopperheadOS. I can't maintain these apps for Google if they're neglecting them. There are other clocks.

[christoph-buente]

I set the system now to English(US), instead of English(UK). Now i can successfully access the clock settings page.

But when a alarm is due, it still keeps crashing. Here is a log of the moment when the alarm goes off.

Do you know how AOSP is managing their translations? I could possibly contribute to their I18n efforts.

alarm_goes_off_english_crash_log.txt

[christoph-buente]

I set the system now to English(US), instead of English(UK). Now i can successfully access the clock settings page.

But when a alarm is due, it still keeps crashing. Here is a log of the moment when the alarm goes off.

Do you know how AOSP is managing their translations? I could possibly contribute to their I18n efforts.

alarm_goes_off_english_crash_log.txt

[christoph-buente]

Thx for confirming the bug did not appear from changes you made. I'll try to file a bug report with AOSP then.

[christoph-buente]

Thx for confirming the bug did not appear from changes you made. I'll try to file a bug report with AOSP then.

[thestinger]

You've reported 2 distinct AOSP bugs here, not one. They are both specific to the marshmallow-dr1.5-release branch for the 5X/6P. One is caused by a translation issue but this one isn't. Unless there are specific commits I can cherry-pick from master to fix this, I don't want to do anything about it.

I noticed yet another issue, which is that the styling is messed up. The only realistic way of fixing these is removing DeskClock from CopperheadOS. I'm not inclined to do that since it's still being maintained by Google, unlike some applications that are completely dead.

[thestinger]

You've reported 2 distinct AOSP bugs here, not one. They are both specific to the marshmallow-dr1.5-release branch for the 5X/6P. One is caused by a translation issue but this one isn't. Unless there are specific commits I can cherry-pick from master to fix this, I don't want to do anything about it.

I noticed yet another issue, which is that the styling is messed up. The only realistic way of fixing these is removing DeskClock from CopperheadOS. I'm not inclined to do that since it's still being maintained by Google, unlike some applications that are completely dead.

[christoph-buente]

Yes, i know now it's two bugs. I've reported them both:

https://code.google.com/p/android/issues/detail?id=206185
https://code.google.com/p/android/issues/detail?id=206187

[christoph-buente]

Yes, i know now it's two bugs. I've reported them both:

https://code.google.com/p/android/issues/detail?id=206185
https://code.google.com/p/android/issues/detail?id=206187

[alxxlc]

I know this is most likely an AOSP issue but I would just like to add that I've been having the exact same issue as this original submission for this bug report but everything on my device is set to English (US). My alarm goes off for a second, cuts off, still shows the notification for the alarm, and crashes when I touch the small circle that is meant to be dragged to silence or dismiss the alarm.

The sound for the alarm only cuts off when my device is locked. The display will power on to show the dismissal activity (which it does show for a fraction of a second), the device will power off the display and silence the alarm sound, go back to the lock screen, power off the display, and repeat this entire mess about two more times. After that, the device is silent and acts normally but the alarm will still show it is going off as if it had been silenced.

If the display is on and the device is unlocked, the alarm will sound off properly.

When the alarm dismissal activity is opened, it works completely fine other than when the little circle that needs to be dragged to silence or dismiss the alarm is touched. The entire dismissal activity crashes when it is. Everything else like the little dismissal and silence pictures are clickable and work properly, it is just the dragable circle that causes the crash.

It seems like this could be two different bugs, one for the lockscreen alarm flashing and one for the dismissal activity crash, or it could be one big bug with the alarm dismissal activity. I'm not sure and I'm not really smart enough to figure it out.

I have had this issue on my 5X since the 2016.05.17.00.50.04 update (and possibly before but I installed that update the first day I installed COS).

I wanted to submit this because it doesn't seem 100% certain that this is an AOSP issue since the only reported case on their bug tracker is from a CopperheadOS user. If you need any information about what my device is doing or if you want some info from logcat, I will be happy to help anyway I can.

[alxxlc]

I know this is most likely an AOSP issue but I would just like to add that I've been having the exact same issue as this original submission for this bug report but everything on my device is set to English (US). My alarm goes off for a second, cuts off, still shows the notification for the alarm, and crashes when I touch the small circle that is meant to be dragged to silence or dismiss the alarm.

The sound for the alarm only cuts off when my device is locked. The display will power on to show the dismissal activity (which it does show for a fraction of a second), the device will power off the display and silence the alarm sound, go back to the lock screen, power off the display, and repeat this entire mess about two more times. After that, the device is silent and acts normally but the alarm will still show it is going off as if it had been silenced.

If the display is on and the device is unlocked, the alarm will sound off properly.

When the alarm dismissal activity is opened, it works completely fine other than when the little circle that needs to be dragged to silence or dismiss the alarm is touched. The entire dismissal activity crashes when it is. Everything else like the little dismissal and silence pictures are clickable and work properly, it is just the dragable circle that causes the crash.

It seems like this could be two different bugs, one for the lockscreen alarm flashing and one for the dismissal activity crash, or it could be one big bug with the alarm dismissal activity. I'm not sure and I'm not really smart enough to figure it out.

I have had this issue on my 5X since the 2016.05.17.00.50.04 update (and possibly before but I installed that update the first day I installed COS).

I wanted to submit this because it doesn't seem 100% certain that this is an AOSP issue since the only reported case on their bug tracker is from a CopperheadOS user. If you need any information about what my device is doing or if you want some info from logcat, I will be happy to help anyway I can.

[thestinger]

Stock Android doesn't ship the AOSP DeskClock app, so Google isn't impacted by the breakage. CyanogenMod has a bunch of fixes to work around the breakage in AOSP but it's messy to take changes from there and it's not clear that they are solving all of the issues properly.

[thestinger]

Stock Android doesn't ship the AOSP DeskClock app, so Google isn't impacted by the breakage. CyanogenMod has a bunch of fixes to work around the breakage in AOSP but it's messy to take changes from there and it's not clear that they are solving all of the issues properly.

[thestinger]

And it's not broken in the marshmallow-mr2-release branch, only marshmallow-dr1.6-release. I expect that it will be fixed by Android N since the separate 5X/6P branch should go away but it's impossible to know what will happen.

[thestinger]

And it's not broken in the marshmallow-mr2-release branch, only marshmallow-dr1.6-release. I expect that it will be fixed by Android N since the separate 5X/6P branch should go away but it's impossible to know what will happen.

[christoph-buente]

I actually switched to cyanogenmod 13 for now, mainly because of the clock. desk clock works like a charme.

[christoph-buente]

I actually switched to cyanogenmod 13 for now, mainly because of the clock. desk clock works like a charme.

[octohex]

Does this mean that at the moment (with MTC19T.2016.05.17.11.18.09) the alarm clock will definitely not work? This would actually be a reason for not installing it. Or does this just concern desk clock (which i presume is a different app than the normal alarm-clock app?)

[octohex]

Does this mean that at the moment (with MTC19T.2016.05.17.11.18.09) the alarm clock will definitely not work? This would actually be a reason for not installing it. Or does this just concern desk clock (which i presume is a different app than the normal alarm-clock app?)

[alxxlc]

From what I can tell, it only seems to affect the 5X branch of AOSP and possibly the 6P. I could be wrong but I believe deskclock is the actual name given to the AOSP clock app package.

[alxxlc]

From what I can tell, it only seems to affect the 5X branch of AOSP and possibly the 6P. I could be wrong but I believe deskclock is the actual name given to the AOSP clock app package.

[thestinger]

Other clock apps will work fine...

[thestinger]

Other clock apps will work fine...

[christoph-buente]

Yes, deskclock is the name of the app which is shipped with vanilla android and aosp, afaik. It's also the same that comes with cyanogen mod. But as i mentioned above, at some point it was broken. I filed bug reports as you can see. But i think nobody actually cares, because the flag "ReportedBy-User" seems to be filter for: we don't care. So maybe someone with more reputation can point the AOSP team to bug and get it fixed.

[christoph-buente]

Yes, deskclock is the name of the app which is shipped with vanilla android and aosp, afaik. It's also the same that comes with cyanogen mod. But as i mentioned above, at some point it was broken. I filed bug reports as you can see. But i think nobody actually cares, because the flag "ReportedBy-User" seems to be filter for: we don't care. So maybe someone with more reputation can point the AOSP team to bug and get it fixed.

[thestinger]

FWIW, it will likely end up fixed by Android N because this branch will be gone.

[thestinger]

FWIW, it will likely end up fixed by Android N because this branch will be gone.

[octohex]

I understand why fixing bugs in AOSP apps is usually out of scope. But this is in my eyes a special case. As dial/use the phone and the ability to send and receive sms, i consider being able to use the alarm-clock as one of the base-function of a smart-phone, so i think its crucial to have them working out of the box.

If tomorrow AOSP somehow manges to break the dialer, will i just have to install a replacement-app for this too and hope that it will get fixed in AOSP-upstream some day? I perfectly understand the focus of copperhead-os, but i want to be able to use the phone with out further modifications to some point (and with 'using the phone' i really just mean the points listed above plus simple working internet connection - not being able to use GPS/GCM etc).

If every AOSP- and in turn every COS-update could break some of this "vital functionality" i would have a hard time using COS.
Maybe it is worth discussing what such "vital functionality" really is and how far COS wants to support it out of the box.

Last but not least having to install replacement-apps for apps which are installed and should usually work unnecessarily widens the attack-surface.

[octohex]

I understand why fixing bugs in AOSP apps is usually out of scope. But this is in my eyes a special case. As dial/use the phone and the ability to send and receive sms, i consider being able to use the alarm-clock as one of the base-function of a smart-phone, so i think its crucial to have them working out of the box.

If tomorrow AOSP somehow manges to break the dialer, will i just have to install a replacement-app for this too and hope that it will get fixed in AOSP-upstream some day? I perfectly understand the focus of copperhead-os, but i want to be able to use the phone with out further modifications to some point (and with 'using the phone' i really just mean the points listed above plus simple working internet connection - not being able to use GPS/GCM etc).

If every AOSP- and in turn every COS-update could break some of this "vital functionality" i would have a hard time using COS.
Maybe it is worth discussing what such "vital functionality" really is and how far COS wants to support it out of the box.

Last but not least having to install replacement-apps for apps which are installed and should usually work unnecessarily widens the attack-surface.

[thestinger]

I understand why fixing bugs in AOSP apps is usually out of scope. But this is in my eyes a special case. As dial/use the phone and the ability to send and receive sms, i consider being able to use the alarm-clock as one of the base-function of a smart-phone, so i think its crucial to have them working out of the box.

What's wrong with installing another alarm clock until Google fixes DeskClock? I have much higher priority tasks than fixing something that's so easily worked around and not caused by CopperheadOS changes. Especially when it's a short-term issue that already has a fix coming down the pipeline without having to do anything. Since no one else contributes and since I don't earn any money from my work on CopperheadOS, the scope of stuff that will be worked on is extremely limited.

If tomorrow AOSP somehow manges to break the dialer, will i just have to install a replacement-app for this too and hope that it will get fixed in AOSP-upstream some day?

Yes, unless you're going to make a high quality patch to fix it or it's trivial to backport a fix. It's not within the scope of stuff that I plan on doing in my free time. The reason these things break is because Google either doesn't ship these apps on stock or they ship versions created by overlaying proprietary code and resources onto them. The scope of things that can break like this is limited to apps that are straightforward to replace. The core operating system is shipped on stock so it has proper QA.

Last but not least having to install replacement-apps for apps which are installed and should usually work unnecessarily widens the attack-surface.

Replacing an app with another doesn't add attack surface if you disable the other one. If it doesn't run as a service or register any handlers, then disabling it isn't necessary.

[thestinger]

I understand why fixing bugs in AOSP apps is usually out of scope. But this is in my eyes a special case. As dial/use the phone and the ability to send and receive sms, i consider being able to use the alarm-clock as one of the base-function of a smart-phone, so i think its crucial to have them working out of the box.

What's wrong with installing another alarm clock until Google fixes DeskClock? I have much higher priority tasks than fixing something that's so easily worked around and not caused by CopperheadOS changes. Especially when it's a short-term issue that already has a fix coming down the pipeline without having to do anything. Since no one else contributes and since I don't earn any money from my work on CopperheadOS, the scope of stuff that will be worked on is extremely limited.

If tomorrow AOSP somehow manges to break the dialer, will i just have to install a replacement-app for this too and hope that it will get fixed in AOSP-upstream some day?

Yes, unless you're going to make a high quality patch to fix it or it's trivial to backport a fix. It's not within the scope of stuff that I plan on doing in my free time. The reason these things break is because Google either doesn't ship these apps on stock or they ship versions created by overlaying proprietary code and resources onto them. The scope of things that can break like this is limited to apps that are straightforward to replace. The core operating system is shipped on stock so it has proper QA.

Last but not least having to install replacement-apps for apps which are installed and should usually work unnecessarily widens the attack-surface.

Replacing an app with another doesn't add attack surface if you disable the other one. If it doesn't run as a service or register any handlers, then disabling it isn't necessary.

[octohex]

I apologize if i sounded rude, that was not my intention. Thank you for clarifying.

[octohex]

I apologize if i sounded rude, that was not my intention. Thank you for clarifying.

[christoph-buente]

@thestinger: in general it's totally fine using an auxilary app. And of course i don't expect you to fix the AOSP deskclock. That's why i filed the bugs at the AOSP bug tracker. But unfortunately nobody could be bothered to look at them.

I tried several other clock apps from the f-droid store but never was satisfied. Either it drained the battery real quick. Or it lacked features, or was just plain ugly :)

And i want to mention, that i never intended to make such a fuzz about the damn clock app. Back then i just didn't know it was not related to Copperhead. So please don't be discouraged and keep the project running. Did the crowdfunding actually start. I'm willing to chip in :)

[christoph-buente]

@thestinger: in general it's totally fine using an auxilary app. And of course i don't expect you to fix the AOSP deskclock. That's why i filed the bugs at the AOSP bug tracker. But unfortunately nobody could be bothered to look at them.

I tried several other clock apps from the f-droid store but never was satisfied. Either it drained the battery real quick. Or it lacked features, or was just plain ugly :)

And i want to mention, that i never intended to make such a fuzz about the damn clock app. Back then i just didn't know it was not related to Copperhead. So please don't be discouraged and keep the project running. Did the crowdfunding actually start. I'm willing to chip in :)

[octohex]

To be clear, this was more about clarifying what one one can expect when installing COS and not about the clock in particular. This is not about demanding features but about knowing what one gets into.

The project-page states

There are likely rarely used components of the operating system that are broken due to latent bugs in Android uncovered by CopperheadOS exploit mitigations. The core functionality of the operating system is very stable.

I know that the clock technically does not belong the core functionality of the OS per se, but it does for a normal working phone in my eyes.

I was hoping that COS could be a easy to use (as far as one can talk about easy in a security-context), more secure alternative than other ROMs. I see now that it is more work than i have expected, and i definitely also see @thestinger's point.

Cheers

[octohex]

To be clear, this was more about clarifying what one one can expect when installing COS and not about the clock in particular. This is not about demanding features but about knowing what one gets into.

The project-page states

There are likely rarely used components of the operating system that are broken due to latent bugs in Android uncovered by CopperheadOS exploit mitigations. The core functionality of the operating system is very stable.

I know that the clock technically does not belong the core functionality of the OS per se, but it does for a normal working phone in my eyes.

I was hoping that COS could be a easy to use (as far as one can talk about easy in a security-context), more secure alternative than other ROMs. I see now that it is more work than i have expected, and i definitely also see @thestinger's point.

Cheers

[thestinger]

CopperheadOS will remain comparable to AOSP, but with much less tolerance for issues like memory corruption so services and apps will abort more frequently. The stability of the core AOSP system is great, but the stability of apps not included in stock Android isn't something that can be assumed. They clearly aren't testing it, so it can break in any monthly update for any reason and it isn't going to hold back updates. It can be worked downstream, but only if someone wants to step up to do that work.

I would happily include clean patches to fix AOSP bugs, but I don't consider fixing AOSP bugs to be in-scope so I don't want to leave bugs open here about them and I don't have time to work on them if it's non-trivial, like this turned out to be. The fixes for them need to either be backports from AOSP or clean code that's understood and can be maintained.

[thestinger]

CopperheadOS will remain comparable to AOSP, but with much less tolerance for issues like memory corruption so services and apps will abort more frequently. The stability of the core AOSP system is great, but the stability of apps not included in stock Android isn't something that can be assumed. They clearly aren't testing it, so it can break in any monthly update for any reason and it isn't going to hold back updates. It can be worked downstream, but only if someone wants to step up to do that work.

I would happily include clean patches to fix AOSP bugs, but I don't consider fixing AOSP bugs to be in-scope so I don't want to leave bugs open here about them and I don't have time to work on them if it's non-trivial, like this turned out to be. The fixes for them need to either be backports from AOSP or clean code that's understood and can be maintained.

[thestinger]

But I think it's worth noting that there are only a couple non-stock AOSP components that cannot be trivially replaced with a third party app, and they aren't critical components. If apps like Email, Calendar and DeskClock become too problematic, they can be removed. Other apps could potentially be bundled in their place.

[thestinger]

But I think it's worth noting that there are only a couple non-stock AOSP components that cannot be trivially replaced with a third party app, and they aren't critical components. If apps like Email, Calendar and DeskClock become too problematic, they can be removed. Other apps could potentially be bundled in their place.

[alxxlc]

Just to try to put a cap on this, I've actually found a really good alternative to the stock app. Simple Alarm Clock from the F-Droid repo has been great for me over the past few days. It doesn't look as good as the AOSP Clock app but it gives all the same functionality and it's very easy to use.

https://f-droid.org/repository/browse/?fdfilter=simple+alarm&fdid=com.better.alarm

I know it sucks to have to use a separate app for the time being but I agree with thestinger that this shouldn't be something that Copperhead should focus on since the app is just borked.

[alxxlc]

Just to try to put a cap on this, I've actually found a really good alternative to the stock app. Simple Alarm Clock from the F-Droid repo has been great for me over the past few days. It doesn't look as good as the AOSP Clock app but it gives all the same functionality and it's very easy to use.

https://f-droid.org/repository/browse/?fdfilter=simple+alarm&fdid=com.better.alarm

I know it sucks to have to use a separate app for the time being but I agree with thestinger that this shouldn't be something that Copperhead should focus on since the app is just borked.

[thestinger]

The next release will have all of the translation changes in the device release branch rolled back. Hopefully that resolves some of the issues for locales other than US English. I'm not sure about any other issues. I don't see fixes for other stuff in CyanogenMod and the other reason they didn't hit all of these is because they don't have all the changes merged anymore.

[thestinger]

The next release will have all of the translation changes in the device release branch rolled back. Hopefully that resolves some of the issues for locales other than US English. I'm not sure about any other issues. I don't see fixes for other stuff in CyanogenMod and the other reason they didn't hit all of these is because they don't have all the changes merged anymore.