back to article Sleuths unearth 'Panic Mode' in Android, set off by mashing back button

The phone sleuths at XDA-Developers have unearthed a handy undocumented feature in the latest version of Android. Phones running Nougat 7.1.1 are able to invoke a "panic button" by pressing the back key four times. It's in the AOSP source code for the Android Window Manager. Panic mode returns the user to the home screen, …

Silver badge

DON'T PANIC

16
0
Gold badge

Surely that would mean pressing the button 42 times?

25
0

Yeah, you press it 43 times and the battery catches fire!

10
0
Silver badge

I'll make a note of that.

17
0
Silver badge
Joke

Re: 43 times

It will naturally only catch fire if it is running on Samsung hardware.

All other makes will give you a 500v electric shock to make sure you don't do it again.

{see icon}

12
1
TRT
Silver badge

Re: 43 times

You only have to press it once - the screen lights up with the message "Do not press this button again".

23
0
Silver badge
Coat

According to the documentation, the button is "mostly harmless".

12
0
Silver badge
FAIL

Re: 43 times

"You only have to press it once - the screen darkens up (down?) with the message "Do not press this button again"."

FIFY

2
0

It only catches fire if you remembered to pick up all the junk mail off the doormat in the morning.

8
0

No such thing on a MS Windows phone

If something bad is run, as far as I know it can't be stopped, unless you remove the battery

6
7
TRT
Silver badge

Re: If something bad is run...

like, say, Windows 10 mobile you mean?

14
5

Re: If something bad is run...

Do you think it's a problem when I actually switch it on in the mornings then?

3
0
Silver badge
Trollface

Re: No such thing on a MS Windows phone

Just out of interest... at what point does the article mention Microsoft, Windows Phone or Windows 10 Mobile? Does it mention iOS or Apple as well? Does it, in fact, focus on anything apart from what is quite an interesting quirk of the Android?

No?

So why bring up Windows Phone at all?

Back under your bridge...

24
7
Pint

Re: No such thing on a MS Windows phone

That is of course, provided you can actually, physically remove the battery without an impressive array of miniature sized screwdrivers, 3 pints of virgin blood and a bible (I'm looking at you Samsung / Apple et al.).

10
0
Silver badge

Re: No such thing on a MS Windows phone

Firstly, none of the people I know with a WinPhone has had a malicious app requiring termination.

Secondly, I am sure the Win key cannot be used by an app or intercepted - can't be sure but no apps I have ever used use it, it makes no sense to do so.

And finally, holding the power key takes one to the shutdown request screen, which, if not proceeded with, almost certainly allows the WIn key to have focus.

My WinPhone also allow the battery to be removed easily - but I have never needed to do it, ever.

4
0
Silver badge
Flame

Re: No such thing on a MS Windows phone

"That is of course, provided you can actually, physically remove the battery without an impressive array of miniature sized screwdrivers, 3 pints of virgin blood and a bible (I'm looking at you Samsung / Apple et al.)."

No, be fair to Sammy for once. They've just provided another way to "access" the battery.

5
0
Silver badge

Re: No such thing on a MS Windows phone

> none of the people I know with a WinPhone has had a malicious app requiring termination

... or indeed, any apps at all?

6
1
Silver badge
Joke

I thought this was going to be about a bug that causes a kernel panic if you press the back button too many times in short succession. I'm kinda disappointed.

13
0
Silver badge

PANIC mode

I thought this was where Android finally admitted that it's whole inspiration came from '80's kitchen-sink-indie trailblazers The Smiths

"On the Leeds side streets that you slip down, provincial towns that you jog round, hang the DJ, hang the DJ, hang the DJ....."

2
0
Silver badge

REISUB

Yes, might be useful if Android did support the magic sequences:

https://en.wikipedia.org/wiki/Magic_SysRq_key

4
0
Silver badge

I was once reading a discussion, many years ago, about Linux UI's and process priority. It might even have been Torvalds himself. Something was mentioned and I couldn't refute it, yet it really surprised me and has stuck with me.

When a user moves or clicks the mouse... that should be the top priority action. It provides instant feedback. You don't get slow-cursor-syndrome just because something is churning to disk. The mouse-click is the action you want to do something (which may be "stop doing all those other things!"), so nothing else matters. Delaying a background task by hundreds of a second at that point is what the user WANTS. If they wanted the long, background process to continue as top priority, they wouldn't be wiggling the mouse around clicking on things. And nothing should be that critical that it can't wait for a mouse move.

I thought it was surprising, and I thought it was correct, and I thought it was genius. And still, to this day, it's not how it's implemented in any OS - we still do junk like busy-loops listening for input and handling mouse movements in screen-refresh loops, etc.. The computer in front of me likes to run off on a pause-venture every few days (I think it's Outlook doing something but I'm not sure because you can't do anything like get task manager up, I'd have to leave it running all day and hope it did it and it's too rare to bother). It'll only take 20 or so seconds but in that time, I can't do anything and the mouse jerks and stutters. I've even seen - on brand new PC's - the "I'm going to pause until the speakers start to thrrrpp / beep because you're doing things I can't keep up with or the keyboard buffer is full"

Why? Why is the user's input not top priority, even if it means an extra half-second of churning to allow that? Why does clicking-the-cross not terminate that app and push it to the back of the priority queue while it clears itself up? Why does drawing the mouse cursor not get top priority over drawing the Chrome window that's under the mouse which is struggling to draw that web page?

Even in a multi-user system, the user LOGGED INTO THE GUI should be the one with priority, surely? It changed the way I think about process priority and human interfaces. One simple change would make the PC more responsive, more useful, even if it's all an act and it can't actually move any faster.

I don't think there's an OS in the world that actually works like that. My Android phone regularly shows high CPU and takes several seconds to switch to the home screen if some crappy app is trying to load.

Why? Why is that base human interaction not the thing taking priority over some app that's churning up memory in the background? Pressing the "kill all apps" button restores it to working order in seconds, which makes me wonder why it can't just throttle them itself so the user can still interact. Don't even get me started on smartphones - including iOS - where you're in an app and everything comes to a grinding halt because of a phone call, which you can't properly answer of deal with anyway because of all the other stuff trying to get out of the way.

User input should be a unmaskable interrupt, running in top-priority processes, which then determines what in the rest of the system gets priority (e.g. old Unix windowing concept of "GUI process which is underneath the mouse cursor has focus" - it shouldn't have FOCUS, but it should have higher priority, surely, as that's what the user is about to interact with?), to get to a result for the user ASAP.

If I click 20 apps from the task bar, why do they not all start and take 1/20th CPU but the 20th responds and starts loading just as quickly as the first when I click its icon? Surely that's the way to MAKE a system seem fast and doing what the user wants.

It blew my mind and still, to this day, I've never seen it implemented properly.

38
0
DJO

User input should be a unmaskable interrupt,

And before USB with dedicated mouse and keyboard ports it was but it's tricky for the USB controller to issue a maximum priority interrupt securely in a way that cannot be abused.

8
0
Bronze badge

That's great, up until the point when the 'unimportant' background task loses data and the user whinges, because the machine isn't fast enough or a task is poorly programmed.

In reality non server OS do exactly what you specify : foreground tasks get a performance boost over background tasks.

You do realise that a phone call on a smartphone is by nature a background task, so by your logic if you're busy in a game consuming plenty of CPU, the smartphone should drop the call and let you get on with squashing monsters

In short, it's not easy, and users get very annoyed when a dialog box pops up saying 'your computer is no longer fast enough to run more than one modern app at a time, please spend four hundred quid and try again'

5
8
Silver badge

@Binky

There are a number of assumptions in your post that are unsupported by the original hypothesis.

"...when the 'unimportant' background task loses data"

No reason why this should happen unless the app is badly coded. Which is kind of the OP's point.

"...a phone call on a smartphone is by nature a background task"

Why? Phone functionality is an app these days like any other, but is by definition realtime, and should be a foreground task unless otherwise specified (e.g. when you click away from the phonecall)

"...if you're busy in a game consuming plenty of CPU, the smartphone should drop the call and let you get on with squashing monsters"

It's also possible in a multitasking OS to give a process a minimum priority - so it won't drop the call, but will divert as much CPU as possible to your game if desired.

"In short, it's not easy"

No it's not. It requires real coding expertise, and that's difficult when companies are driven by marketing. It is possible though, and in my view should be an aspirational goal.

13
0
DJV

@Lee D

Exactly, very well put.

And, it should be added that, absolutely NO program should pop itself to the front and take focus away from whatever the user is currently doing! Over the years I've lost count of the number of times something running in another window has popped itself to the front at the most inconvenient point, whereupon I've accidentally clicked on a button or pressed a key that has caused that program to do something I hadn't intended.

13
0
Silver badge

Re: @Lee D

Windows explicitly tries to make it impossible for any program to bring itself to the top, because the OS developers know it's pretty much the worst possible thing to do.

Several software developers then use undocumented calls to force their application to the top.

Microsoft are one of the worst offenders.

11
0
Bronze badge

'No reason why this should happen unless the app is badly coded. Which is kind of the OP's point.'

Sure, in a perfect world with perfectly coded apps and an (absolutely necessary) enforced upgrade cycle everything would be peachy. Now look at managed app ecosystems (where the apps are only approved if they meet strict responsiveness requirements) and see that they're moribund.

This leads to the reality of trying to e.g. run Firefox and being told 'sorry, this program may at some point be unresponsive, so we're not letting you run it'. *That's* going to go down well.

'Why? Phone functionality is an app these days like any other, but is by definition realtime, and should be a foreground task unless otherwise specified (e.g. when you click away from the phonecall)'

The phone call is only a foreground task when the user initiates the phone call, otherwise it's a background task, because it is interrupting the foreground task the user is operating. Obviously a phone call should have a high responsiveness, now extend that to all the other background tasks and argue the point on those.

'It's also possible in a multitasking OS to give a process a minimum priority - so it won't drop the call, but will divert as much CPU as possible to your game if desired.'

"Sorry - I can't run this game. If a phone call (or other background tasks that's not as user response critical) happened in the middle of it, it might not respond fast enough and cause you to lose a life.". Even though 98% of the time, it won't be a problem, the app has to refuse to run.

This is always going to be a balancing act. Phones and Apple products limit what OS can be installed on them, some times because the manufacturer can't be arsed, other times because the hardware is not fast enough to effectively run a typical set of apps. Even then there are limits depending on the app mix.

The end result in a perfect ecosystem is that the device remains responsive, but there are mandatory upgrades and/or loss of functionality (unless the whole ecosystem is held back by supporting someone that refuses to upgrade their 15 year old device). Apps take longer to come out, longer to be upgraded, and cost more. Possibly a good idea, not necessarily appreciated by users.

In a non perfect ecosystem (i.e. reality) the device slowly degrades, as the apps upgrade, and the OS scheduler does its best to keep everything running. Apps stop being supported on their device, but at a slower rate than in the 'perfect ecosystem'. The user eventually gets fed up and upgrades, particularly if they've ignored recommendations and installed later OS versions not designed for their device.

The advantage in the latter case is that the user can hang to their device for an extra year or two before having to spend hundreds of pounds on a New Shiny. It works most of the time, and that's what they actually care about.

It's not just marketing, it's business. To maximise sales, apps have to target the largest reasonably supportable number of devices. Let's say YourApp will run absolutely fine on 70% of devices, not at all on 5%, fine almost always on 20% of devices, and badly on 5% of devices. In a 'perfect ecosystem' that's 25% of sales instantly lost. The 5% of badly running devices you probably don't want to sell to. The 20% - you definitely do, as the only time it has problems is when all apps simultaneously need to run with their highest level of speed and functionality on the device.

1
1
Silver badge

"The phone call is only a foreground task when the user initiates the phone call, otherwise it's a background task, because it is interrupting the foreground task the user is operating"

That makes no sense. Phone calls are always foreground when you pick them up. You can send them to the background on a multitasking-capable device, but they always start foreground. Or are you talking about standby mode?

""Sorry - I can't run this game. If a phone call (or other background tasks that's not as user response critical) happened in the middle of it, it might not respond fast enough and cause you to lose a life.""

Said no operating system ever.

I've reread your post six times now and I really truly have no idea what point you're trying to make.

2
0
Bronze badge

Some manuals or articles on operating system architecture and scheduling will help. A phone call is a background task listening for a call, it only becomes a foreground task when it starts a (foreground) interface to accept the call that overlays whatever application was previously in the foreground.

The whole point about this thread is having a deterministic operating system and interface so that it remains equally responsive under all conditions, no exception. The only way to achieve that is via a well written OS, well written and vetted apps, and the refusal to run anything that would affect that.

As it is, the current status quo is for some reasonably complex process schedulers to be used that fit a specific pattern of expected behaviour. By and large, it works quite well, whether it's Windows, Unix, or one of the Phone OS. To achieve the best responsiveness use apps produced by companies that favour response (this may mean missing out on functionality), run a minimum of heavy or background tasks, and upgrade your device on a regular basis, particularly if it's a phone.

Plenty of people don't like spending money to upgrade their device on a regular basis, or restricting what it runs, but processing power is not unlimited.

0
1
Silver badge

It's got nothing to do with reading manuals or articles; it's to do with you explaining correctly what you mean. You originally said "...a phone call on a smartphone is by nature a background task" - and followed it up with "A phone call is a background task listening for a call, it only becomes a foreground task when it starts a (foreground) interface to accept the call..." - neither of which make sense.

A phone call is always a foreground task - at least initially. I suspect you mean a phone app on standby being a background process.

Re the rest of your post, you appear to be saying that a well written OS is able to strike the right balance between app performance and responsiveness in most situations. Except you used a lot more words.

1
0
Silver badge

Re: @Lee D

And, it should be added that, absolutely NO program should pop itself to the front and take focus away from whatever the user is currently doing!

True ... but, conversely, when the user explicitly clicks on something in one application that causes another application (or, "Activity", in Android parlance) to open, that second application is part of the user's current workflow, and it is extremely annoying if that second application does not take the focus.

It's not always straightforward.

1
0
Bronze badge

Panic Mode not what I thought.

I thought a panic mode would automatically dial 911/999, not back-out of a stuck application.

How is something like this even left up to the OEM? Couldn't they trap this in the kernel? Imagine if PC OS provider said "Ctrl+Alt+Del" to panic? Nah, we'll switch that to launch your web browser. People might not be so friendly to that vendor. But I guess, right now, no one expects the back button to be able to panic, so it's just a case of not knowing what we're missing out on.

Still, remember when phones had a home button that would take you home? Like a physical button that could drive an interrupt to the CPU? Those were crazy days.

3
0
Silver badge

Re: Panic Mode not what I thought.

I thought it's 0118 999 881 99 9119 7253 now?

3
0

This was not the Panic Mode I was looking for.

I was hoping like hellwig that this was some sort of special dialling code for anyone being attacked/mugged/robbed who could mash the button while handing over their phone to cause it to lock up and autodial the emergency services.

But i guess having a useful feature like that would cause less phones to be stolen and therefore reduce profits so would never be implemented.

5
0
Silver badge

Re: This was not the Panic Mode I was looking for.

...or for Samsung models, self-destruct in 5...4....3.....

3
0

I must be missing something...

Isn't that what the "Home" button is for?

4
0
Silver badge

Re: I must be missing something...

Not any more. These days, the home button is a combination of Alt+Tab and Show Desktop - having it force-quit running apps (with the associated data loss) would drive your average consumer nuts.

1
0

I don't know about stock Android

But LineageOS has an option in the developer menu to kill an app by a long press on the back button.

6
0
Silver badge

Re: I don't know about stock Android

Seems to be yet another thing inspired by Cyanogen.

Not surprised Cyanogen had problems differentiating themselves from stock Android.

2
0
Silver badge
Thumb Up

Re: I don't know about stock Android

Yep, it was part of Cyanogenmod for many years, I assumed it was part of stock Android already.

For those wondering, you need to enable the Developer settings, and then enable "Stop app via long-press" (exact wording may vary).

2
0
Anonymous Coward

I wonder why

1. Developers did not consider from the beginning a way to kill the foreground app

2. Developers still refuse to do it

6
0
Bronze badge

Re: I wonder why

Having an Exit button/choice in the main menu for the app would remove the need for this. Why anyone would build an app without any way to exit it is beyond me.

The fact that you have to download an extension to Firefox to get an exit choice on the menu suggests that there is an industry-wide inability to design UIs.

6
2
Silver badge

Re: I wonder why

"Having an Exit button/choice in the main menu for the app would remove the need for this"

The problem is that an Exit button in the app would require the app to (a) have focus, and (b) not be misbehaving. When an app misbehaves, for example by infinite-looping itself to 100% CPU, the Exit button won't work, and you need an OS-level Exit button to kill the process/app and return gracefully.

Which coincidentally is exactly what we're talking about here with the OS-level Panic button.

1
0
Bronze badge

Re: I wonder why

There is also the fact that a well behaved app should just be paged out when inactive - then when you open it again, it comes back as it was, while also being faster and less power hungry.

By all means, kill off active background tasks that are sucking resources, but apps like Firefox on the mobile don't need a close button in the menu.

Worst comes to the worst, you kill it in the app switcher.

0
0
Silver badge

Wait, there's no way to kill the foreground app in Android?

Surely this isn't the case???

Not even just for malicious apps, any buggy app that stops responding can be a problem and need to be killed.

A few revs back the Facebook app on iOS seemed to get 'stuck' and stop responding to any input, and I'd need to kill and restart it. If there was no way to do this, and I could only power down or force reset the phone, I would have been mightily annoyed!

1
0
Silver badge

Re: Wait, there's no way to kill the foreground app in Android?

Of course there are ways to do this. The Panic mode is there for if those ways aren't working because theres a buggy app in the way. Not quite sure why they couldn't just code this into the home button single press. When I press the home button I expect it to take me home regardless of what the current foreground app is doing.

1
0
Silver badge

Re: Wait, there's no way to kill the foreground app in Android?

"When I press the home button I expect it to take me home regardless of what the current foreground app is doing"

If the home button force-quit the app every time you pressed it (which it would need to do if the app didn't gracefully relinquish control within an acceptable time period), it would be incredibly annoying.

Handsets should provide 3 user-accessible return functions;

(1) App-level call (return focus to homescreen);

(2) OS-level call (terminate and return focus to homescreen), and

(3) Firmware-level call (terminate with prejudice, return focus to homescreen).

On iOS, these calls works like this;

(1) Single-press Home button

(2) Long-press Power button THEN Long-press Home button

(3) Long-press Power button AND Home button.

1
0
Silver badge

Re: Wait, there's no way to kill the foreground app in Android?

I meant to say "there's no way to kill a misbehaving foreground app in Android?" Obviously you can kill the foreground app, but if it locks up, it sounds like there can be problems being able to kill it. Is that the case or not? Not trying to start an Android vs iPhone war, just curious as a non-Android user if this "panic mode" the article refers to is something actually needed or superfluous?

0
0
Bronze badge

Had a TV remote app on my Note 4

said app could be activated from the lock screen without entering PIN - I can see their reasoning, BUT a shit update had the app putting an impenetrable overlay on top of the pin screen, and the power off menu too once i activated that.

Took a couple of occurrences to identify the cause - and remove the app, but the immediate fix was ripping out the battery.

This is just an example why users need an absolute hardware kill option - and how they work.

The panic button is a second rate solution which sounds like it wont even be implemented by most suppliers.

1
0

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017