Alarms don't wake up the phone when it is powered off

In order to have enough battery left to ring an alaarm, this bug would need to be fixed too: https://bugs.launchpad.net/indicator-power/+bug/1317860

Status changed to 'Confirmed' because the bug affects multiple users.

I don't understand what this bug report is requesting that indicator-datetime isn't already doing -- it calls the powerd dbus API to request an RTC alarm wakeup when the alarm should ring. powerd uses platform-api's u_hardware_alarm_*() API to implement; it performs the hardware wakeup and emits a wakeup signal to listeners, which datetime catches and rings the alarm.

Is the request here to power on the phone even if the user has manually powered it off?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03.03.2015 03:01, Charles Kerr wrote:
> Is the request here to power on the phone even if the user has
> manually powered it off?

Yes bug more importantly, if the phone has switched itself off because
of low battery.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlT1emkACgkQXJwWsxE5x7h9PwCfYL4w9/7wpwdIYMduFvHBN6cc
TloAn0SbaITh7XFDbTehEHCjCyQwIXe1
=13ls
-----END PGP SIGNATURE-----

From the data sheet (http://www.datasheetspdf.com/PDF/MT6582/785907/11):

"After that PWRKEYcan be released, pulling BBWAKEUP high will also turn on the handset. This is the case when the alarm in the RTC expires."

So it seems the hardware should support to turn the device on when an RTC alarm happens.

Status changed to 'Confirmed' because the bug affects multiple users.

I can confirm this bug also occurs on a MX4.
Is this a hardware or a software issue?

Status changed to 'Confirmed' because the bug affects multiple users.

Jolla phone can do it as well, fwiw.

I love that feature, and I think it is a real showstopper for people who are used to having a reliable alarm-phone.

I already missed the alarm twice because my Krillin switched off because of a bug (or because it had run out of battery) during the night. I've been using the Jolla as secondary alarm since then, and I know that even if it runs out of battery, it will still keep enough juice to fire the alarm when the time comes.

The use of the API by powerd is correct

u_hardware_alarm_set_relative_to_with_behavior(
         hardware_alarm,
         U_HARDWARE_ALARM_TIME_REFERENCE_RTC,
         U_HARDWARE_ALARM_SLEEP_BEHAVIOR_WAKEUP_DEVICE,
         &sleep_interval);w

Which platform_api maps to

     else if (time_reference == U_HARDWARE_ALARM_TIME_REFERENCE_RTC)
            switch(behavior)
            {
                case U_HARDWARE_ALARM_SLEEP_BEHAVIOR_WAKEUP_DEVICE:
                    type = ANDROID_ALARM_RTC_WAKEUP;
                    break;
                case U_HARDWARE_ALARM_SLEEP_BEHAVIOR_KEEP_DEVICE_ASLEEP:
                    type = ANDROID_ALARM_RTC;
                    break;
            }

        int result = ::ioctl(fd, ANDROID_ALARM_SET(type), ts);

Can we look into whether we need to enable something in the kernel configs?

The Android API RTC_WAKEUP indeed refers to waking from deep sleep, I see no reference to an API for powering on the device.

Wasn't https://code.launchpad.net/~charlesk/powerd/add-hardware-alarms/+merge/231302 supposed to provide the needed beef for this usecase?

That is what we use for alarms but it doesn't work when the device is powered off.