Background

In Canada, the CRTC mandates that telecommunications companies and other organizations broadcast warning messages over various mediums, one of which is via cell phones.

Overall, this is a good idea that saves lives. However, the implementation is incredibly bad. All alerts, no matter the severity, are broadcast at the very highest level (called "Presidential" by Android phones), meaning that they can't be silenced or disabled by the user. In fact, the CRTC actually tested this and found that the only reliable way to silence the alerts was to put the phone on airplane mode.

After I received three alerts all about an hour apart starting at 2am telling me about a missing child over 1,300km away, I'd had enough.

This is a "boy who cried wolf" situation here. If these alerts ever:

1. Implement a basic distance filter so I'm not woken up by things happening nowhere near me
2. Start using an appropriate alert level instead of using the highest level for everything

I'll re-enable them. For now though, I don't want to be repeatedly woken up in the middle of the night because someone a full day's drive from me went missing. Maybe that's cold-hearted, but realistically what was I even going to do about it?

On Android at least, the lower-level emergency alerts can be configured to not make noise when the device is silenced, but not disabled entirely. This seems a lot better as it won't wake people up, but will show them the information the next time they look at the phone. Let's do that instead.

For now though, I'm turning everything off. Hopefully I don't get killed by a tornado or something.

How to disable ALL alerts

This is surprisingly simple - the application responsible for handling the broadcasts can be uninstalled.

To uninstall it, enable developer options and debugging on the phone, connect it to a computer with ADB installed and run:

1

adb -d shell "pm uninstall -k com.android.cellbroadcastreceiver"

Thanks to this reddit post for the method of disabling the alerts.

Why is it like this?

Which organization is responsible? Can this be changed?

Below is a rough dump of some details I found while trying to dig up which organization is responsible for this with the hopes of actually affecting some change.

On 2017-04-06 the CRTC issued Telecom Regulatory Policy CRTC 2017-91 which "directs wireless service providers to implement wireless public alerting capability on their long-term evolution networks by 6 April 2018". Relevant information pulled from that page:

34. SOREM has established a definitive list of emergency alert message types for immediate broadcast by alert distributors. These messages are defined as “Broadcast Immediately” (BI).

In a footnote on the page it defines SOREM as:

SOREM is a federal/provincial/territorial body that works to harmonize and improve emergency practices across the country. It includes representatives from provincial and territorial emergency management organizations as well as Public Safety Canada.

There was some disagreement on making the alerts mandatory:

35. Individual interveners’ views were divided among mandatory receipt, an opt-in mechanism, and the choice to opt out. Technology solutions providers indicated mixed support between mandatory reception and the choice to opt out. EMOs strongly supported mandatory receipt.

36. The OPC submitted that many people consider their mobile devices to be private and personal, and that some individuals could consider emergency alerts to be intrusive. It recommended that the Commission review how opt-out mechanisms have been implemented in the United States and other jurisdictions, and whether the ability to opt out has had a significant negative effect on alerting individuals in an emergency situation. It submitted that individuals should be allowed to opt out if the effect is found to be minimal.

39. Some WSPs provided insight on past experiences regarding the distribution of AMBER Alerts over their parent BDUs. For example, in March 2016, the Ontario Provincial Police issued an AMBER Alert, which was distributed by BDUs. Many television viewers were upset by the interruption of their television viewing and contacted their BDU customer service centres and, in some cases, 9-1-1 to complain.

And finally, in a section titled "Commission’s analysis and determinations", a decision was made:

41. Although some interveners suggested modifying the BI list, there was no consensus on which specific categories should be added or removed.

42. However, the question in this proceeding is not whether the BI list used in the broadcasting context should be changed, but whether the same or a different approach should be taken with respect to emergency alert messages sent to mobile devices compared to those sent via broadcasting emergency alerting. The current BI list is designed to protect against threats to life and property. It is therefore important to promote consistency between broadcasting and wireless emergency alerts so that Canadians can receive the same alerts regardless of transmission medium.

43. In light of the above, the Commission mandates the reception of emergency alert messages on mobile devices, based on the BI list developed by SOREM, as amended from time to time.

This seems to say that the list of what alerts exist and their priority is managed by SOREM.

To back this up, the CRTC's Emergency Alerts and the National Public Alerting System page has a section titled "Consistent appearance and sound of alerts" with the quote:

The visual appearance, sound, content, and other aspects of emergency alerts are guided by the Senior Officials Responsible for Emergency Management. This federal, provincial and territorial body works to harmonize and improve emergency practices across the country.

That section also includes a link to the National Public Alerting System's Common Look and Feel Guidance which has some more information in it:

From the 7.3 SOREM Public Alerting Layer section:

The SOREM Public Alerting Layer establishes parameters that are referred to by the CLF. The current version of the specification can be found in Appendix B.

From the APPENDIX B – SOREM Public Alerting Layer section:

The SOREM Public Alerting Layer establishes a number of CAP s which are used to support the public alerting community in Canada. In a separate document, SOREM maintains the “Broadcast Immediate Events List”, which works in conjunction with this layer. The current version of this list is available at https://alerts.pelmorex.com/highpriorityalerts/

That link goes to a page that doesn't exist, but by visiting https://alerts.pelmorex.com directly and looking around, it looks like it should point to: List of Event Codes for Broadcast Immediate Alerts (version 2.1) (last updated 2022-05-25).

This document contains a table titled "EVENT CODE DESCRIPTIONS FOR EMERGENCY PUBLIC ALERT BROADCAST IMMEDIATE EVENTS" that defines what codes map to what alert severity. For example, the reason why an AMBER alert is sent at the highest level is because of this entry:

Event Code: amber
CAP Code for Urgency: Immediate
CAP Code for Severity: Severe or Extreme
CAP Code for Certainty: Observed
Description: Amber Alert: Issued by police services when a child has been abducted and it is believed that his/her life is in grave danger. An Amber Alert provides the public with immediate and up-to-date information about a child abduction and solicits the public's help in the safe and swift return of the child.

Where the following definitions for the CAP codes are used:

• "Immediate" - Responsive action SHOULD be taken immediately
• "Extreme" - Extraordinary threat to life
• "Severe" - Significant threat to life
• "Observed" - Determined to have occurred or to be ongoing

This is where the "everything at the highest alert level" issue comes from. Aside from testMessage, literally every other event code on this list has the same Immediate + Severe/Extreme classification. This includes everything from silver ("a missing, wandering older adult who may be suffering from a documented cognitive disability or degenerative memory disorder") to meteor ("A natural object of extraterrestrial origin [...] hits the ground with the potential for catastrophic damage.")

Summary

The CRTC requires that Wireless Service Providers (WSPs) implement the alerts as defined by SOREM. SOREM's list of alerts defines an AMBER alert as requiring the same amount of urgency and disruption as a planet-killing meteor dropping from the sky.

This seems to be by design, but if not, SOREM is the organization that would need to fix it. As an aside, it seems like the CRTC wouldn't even have to get involved as the policy just defers to the "BI list developed by SOREM, as amended from time to time" which seems pretty loose. Maybe I'm missing something though.

I didn't find anything that specified any details about how wide the affected range for these alerts should or should not be. It seems like that's left up to the organization issuing the alert.

The situation

The Nexus 5 that I've had for almost 5 years started bootlooping repeatedly.

I've replaced/repaired multiple parts of it over the years but lately it had been more flaky than usual. For example:

• Sometimes when booting it would show a "Firmware update in progress, don't disconnect your computer" message, even though there was nothing connected to the USB port.
• It would randomly freeze and soft reboot when using it about once a week.
• When propping it up on a book or something to angle the screen towards me, the screen would sometimes turn off and on (as it turns out, this was a warning sign)

I've been ready to replace it for a while, but couldn't justify it while this one was perfectly (ok, mostly) functional. That changed today when I tried to turn it on and it started bootlooping.

So buy a new phone and move on, right? Right, except I committed the cardinal sin of living in the digital age - not having complete backups. Yeah, yeah, I know.

I got most of it. I'd been using Syncthing to automatically back up photos, videos, and other files to my home server every night so they were all good. The problem was that I had been using FreeOTP-export to back up my 2FA secrets manually and the latest backup was missing a bunch of logins.

So I needed to somehow get into my non-booting phone and pull the data off it. At least because I was replacing it, all destructive options were on the table.

Diagnosis

The first step was seeing if other people had this problem. Some searching revealed that it was most likely the power button gone bad and being stuck in the pressed position.

To confirm this, I rapidly hammered the power button on a hard surface while booting, hoping that the jarring would un-stick it and let it boot. This sort of worked in that it would boot, but stopping at any point would result it it powering off again. It was also extremely difficult to tap it consistently enough to keep the phone on for long enough to pull any data off it.

The issue I mentioned earlier where propping the phone up made the screen turn on and off now made sense. I'm guessing this was causing a slight flexing of the power button switch, causing it to close and trigger. Over time this must've permanently bent something so it stayed closed, causing the bootloop.

Now that I had pretty much confirmed that it was something physically wrong with the power button circuitry, I messaged my friend Mike. When it comes to electronics, he's definitely more experienced than me. Plus, he lets me borrow his tools :)

The "fix"

The next day Mike came over with his soldering iron and we started brainstorming.

The plan of attack was to just take the power button off the board entirely. It can't always be pressed down if it's not on the board right?

In preparation for this, I wanted the phone to automatically boot when it was plugged into a charger so I wouldn't have to manually short the pins on the board. Fortunately this can be done with a fastboot command: fastboot oem off-mode-charge 0 (basically: don't allow charging while off, therefore turn on when charging).

After desoldering the power button from the main board, it was still bootlooping. Not good. I went back and cleaned up the solder to make absolutely sure that the power button signal pins weren't connected in any way. Still bootlooping when powered on. It would get to the bootloader and stay there, meaning the power button wasn't being pressed anymore, but when launching to either recovery or the main OS, it would immediately restart.

Looked into dumping data from the bootloader - impossible.

Reflashed the boot and recovery partitions - same thing.

Tried booting into recovery using fastboot boot <recovery-image> - bootloop.

sounds like it's time to cry

-- Someone on Freenode's #lineageos-dev channel after I explained the situation

Thankfully, it was not. Right after that, someone else asked if I had reconnected the battery. I had not.

Turns out that a working battery is required to boot the phone, even when it's plugged in. I had taken the battery out to desolder the power button and never put it back in since the phone seemed to boot fine without it. Whoops.

After plugging the battery into the board and booting the phone, it launched the main OS without any issues. Huge relief.

Recovering the data

With the phone booted up normally I used adb (running as root) to pull the 2FA codes and other important things that I knew I needed over to my laptop.

I really don't trust myself to remember everything so I booted the phone into recovery mode and pulled a complete backup of /data/data, /data/app, and /storage/sdcard (not actually an sdcard) to my laptop as well.

To make absolutely sure I didn't miss anything, I also pulled a raw image of the entire flash memory (disk-based encryption was not enabled) using adb pull /dev/block/mmcblk0 mmcblk0.img. Everything I need should be in the normal backups, but if not, I can always go spelunking through that image.

Lessons learned

• If it's important, back it up automatically. If it's not automatic, at some point it will be missed.
• Make sure you have the ability to get root access on every device you own before you need it - in this case I wouldn't've been able to pull the 2FA codes or do full backups without it.

Future plans

For the Nexus 5, I'm planning on either buying a replacement power button or maybe just soldering some wires to the exposed pads and snaking them out of the phone to an external button if I can't find one. The phone can then continue to be used as an app development testbed, a Chromecast remote, or as a basic emulation console until it dies for real. In theory I could keep using it as a phone too, but at this point I just don't trust it enough.

For my next phone, I've decided on the Xperia XZ1 Compact. It's a smaller phone that's mostly waterproof (IP68), has a fast SoC (Snapdragon 835), a headphone jack, SD card support, and great battery life. I have high hopes for it. Also, as evidenced by this post, having root access to the OS is pretty critical at times so I'll be flashing LineageOS on it ASAP.

Introduction

I finally just bought a new phone (a Nexus 5), and after flashing CyanogenMod onto it, I've been messing around with its OTG support. My old phone (a Nexus 4) didn't have the capability so being able to plug in keyboards, mice, external hard drives, and various other peripherals was (embarrassingly enough) a thrill.

Keyboards worked, mice worked, but when an Xbox 360 controller was plugged in, nothing happened. Turns out that while the kernel didn't have support for it enabled out of the box, getting it enabled and pushing the change upstream into the CyanogenMod project was easier than I thought.

Beware that this post is going to be more of a record of what I did so that I can do it again and less of a coherent tutorial.

Building CyanogenMod

First step was to download and compile CyanogenMod for my phone. I'm not going to go into this in any detail on this because there's already a good overview on the CyanogenMod wiki that covers the entire process, as well as a customized guide for the Nexus 5. If those articles are followed correctly, you should be able to build a fresh CyanogenMod image with:

1

brunch hammerhead

Enabling the kernel module

Once the image was flashed to the phone and verified to be working, the next step was to enable the xpad kernel module.

Copy current kernel config to the kernel directory for editing:

1
2

cd <build dir>/kernel/lge/hammerhead/
cp arch/arm/configs/cyanogenmod_hammerhead_defconfig .config

Edit the config:

1

make menuconfig ARCH=arm

At this point, a menu will come up. Search for xpad (type /xpad), and take note of the paths. ESC out of the search, navigate the tree and enable the modules found with the search. Save and exit.

Copy the config back and clean up any stray *.o files:

1
2

cp .config arch/arm/configs/cyanogenmod_hammerhead_defconfig
make mrproper

After enabling the module, rebuild CyanogenMod using the normal brunch hammerhead and flash it to the phone.

Submitting the change upstream

Since Xbox controller support had already been requested in a JIRA ticket(dead link), I went through the process to submit the change on the CyanogenMod Gerrit instance for inclusion in the next release. There's a guide for this here. As well as the guide, I found the people in #cyanogenmod-dev on Freenode to be very helpful.

A short while after submitting the change to Gerrit, it was merged into the cm-11.0 branch as commit i7ef4f6a and pushed out in the next nightly build (changelog screenshot).

Wrap-up

It feels great to be able to contribute to an amazing open source project that had at least a million people using it at one point or another. I recognize that the change by itself was just changing a config file to enable functionality that already existed, but it's helped me get through some of the non-coding hurdles of contributing to an Android fork like CyanogenMod (adb, fastboot, unlocking and rooting phones, compiling AOSP, flashing images, the contribution process, etc). This time the actual contribution itself was minor, but it's gotten me more familier with the process, hopefully making it easier to contribute something more substantial in the future.

In the end, I learned a lot about Android development and how all the different pieces that I had read about at one point or another actually fit together. During the whole process I also lost a lot of the fear I had about messing with phones and other more expensive locked down devices. Going forward, I'm going to attempt to compile and flash open source operating systems like CyanogenMod onto more devices that I own. I like being able to tweak things and feel like I really own them, hardware and software.