Flashlight toggle upon long-press power button; req for advice

Doboprobodyne

TL;DR: I'm begging for help to get code written that will create an option for allowing, in the screen-off state, a long-press of the power button to toggle the flashlight on or off. I realise just because the code gets written doesn't mean it gets merged. I can't program my way out of a paper bag: I intend to pay someone to write it for me, and my post here is to ask if any kind souls might help me write the tasking that would get put out to tender, so to speak.

History of task:

Flashlight toggle upon long-press power button has come up on the forum numerous times. The best response I thought was from @Carlos-Anso who wrote:

For years there have been repeated requests to add this button press flashlight shortcut to GrapheneOS. So many that the team now almost considers it a meme.

The response is always the same. As GrapheneOS is focused on security and privacy any use of physical button press shortcuts would be for a privacy or security features.

There is a long list of work the team plans to implement which has higher priority than adding button press shortcuts.

Devs have very patiently explained that they will not develop this feature (at least here, here, and here).
- To my mean understanding, the most useful reply was that the feature is not available in the stock pixel OS.
Under Settings > System > Gestures > Press and hold the power button, there is a nascent setting that appears to have no user-settable features.
- In the AOSP code base, "press and hold power button" either opens the power menu, or opens the Assistant feature. My (mean bordering on knuckle-dragging) understanding is that this is where the feature would need to appear.
- I'm conscious that the thing that probably causes so many to pester devs with repeated requests for the described feature is that LineageOS has made it available to users. The LineageOS' code for the feature is here, and the way they've had it working for the last _8yrs has worked (for me, at least) superbly.

My thoughts:

I am here as a grateful user of GrapheneOS having migrated following the end of DivestOS. The work of the devs in creating GrapheneOS is truly awe-inspiring, and gives me hope for a brighter future.
I've started getting tendonitis in odd places, and manipulating my telephone while carrying things in my other hand is painful; being able to put my free hand in my pocket and - without reference to the screen - pull out a flashlight, was a really fantastic asset to me whilst using my previous telephone.
- I currently use the corner function pinning on the lock screen to switch on the flashlight, however manipulating the telephone with one hand to see the screen is sometimes problematic. I share my personal motivation for this post because it is important to me that the depth of my gratitude for GrapheneOS' existence remains clear throughout.
I share @matchboxbananasynergy and others' dim view of giving accessibility permissions to a third party app in order to achieve the goal.
This post was posted in 'off-topic' because I don't want to trouble the devs with this until I have a useful solution I can present for their consideration. Frankly I think specialists should be protected from the brainless gabbling of the general public (and in this case, I am the general public). I'm fully aware that the devs may not have capacity to review the code perhaps even for many years. It is not, realistically, within my gift to change that, however I can at least explore ways I might get some of the work begun.
My impression is that it would be easier for the devs to accept this feature if it were available in the AOSP. I presume one has to have many grey beards to get code accepted into the AOSP, but if anyone knows the best course of action to achieve this, I'd be all ears.

My ask:

Would it be more productive if I were to strive to get this written so that it could be submitted for consideration for the AOSP, rather than for GrapheneOS?
Would it be more productive if I asked someone to write a script that would fork GrapheneOS and inject the required code? (I'm not wholly sure how updates would work for such a fork; my impression is that this course of action is less productive, but I would gladly be corrected).
If my proposed course of action is likely to be the most productive means to my end, then: are there any technically inclined forum users who might be willing to work with me to formulate the question that ought to be asked of a programmer to achieve the goal of getting the feature developed to the stage it could be submitted for consideration?
Perhaps the most important 'ask', as whenever the general population speak to specialists, they often not only have the wrong end of the stick, but are barking up completely the wrong tree: Should I be asking a different question altogether? And if so, what?

In closing:

I must reiterate my love for this project, my gratitude to the developers, and my wish to pursue this in a way that doesn't get up anyone's nose. I realise that there is a world of difference between programming a feature, and having the programming accepted into the product, and that the latter might very well never happen in this case (hence my posting in off-topic). Being a thicko, I may have got the words wrong making this meme, but I hope it will go some way to conveying my understanding that even the richest features may have to wait for many decades to get into production:

Doboprobodyne

I think I ought to add that I am sensible of the fact that:

GrapheneOS is intentionally kept lean so that it's easy to port (credit to @matchboxbananasynergy for the observation).
GrapheneOS goal is to take AOSP and harden its security (credit to @spiral for the observation).
any features - beyond those in the AOSP - need to have intrinsic security appeal to the development team so they want to shoulder the burden of maintaining them going forward. Obviously having a one-press flashlight I can pull out of my pocket feels like a huge security boon to me, but unless the developers feel the same way it is unreasonable to ask them to maintain that feature for all time. It may be that figuring out how to make this feature appeal to Google for integration into the AOSP is the most productive course of action.

matchboxbananasynergy

I really appreciate you taking the time to make this post, and I - really - appreciate you doing so in a respectful and thoughtful way.

So when I say I don't want you to take the following as dismissive, please know that I mean that.

This is such a common request that I've had a lot of time to think about what someone who really wants this feature and also really wants to use GrapheneOS should do.

Yes, the lockscreen shortcuts have made this require less clicks than before, but I also understand some people want to be a button press away from doing this and may have serious and legitimate reasons for wanting that.

Have you considered carrying a separate flashlight?

Again, I don't want to sound dismissive - so hear me out!

This is such an important feature to you that you would go such lengths to get this code landed in GrapheneOS. Wouldn't it instead be more productive to simply carry a pocket flashlight? Not only would it be easier and probably cheaper, especially if you're looking to hire a developer to do this (MUCH cheaper), but the standalone flashlight would kick the phone's flashlight's ass. Different modes, different kinds of beams, can even get a flashlight that has a light on the side that you can use to light up an entire room if needed, or use as an emergency light if you're walking somewhere dark and want to make sure you're noticed by cars etc.

All this to say, seeing as this is so important for you, maybe it's worth considering something that is an objective upgrade, is much cheaper, and probably not that much of a pain to carry in addition to your phone, you'd be surprised how powerful a modern LED flashlight that you can get for 50 bucks is.

Doboprobodyne

matchboxbananasynergy

You're very kind to reply, and especially so politely given all you've been through with this! Thought about it, but it's less net effort to muddle through with the flashlight on the telephone as it is, than it is to carry an extra thing. I do very often carry keys and will probably buy a little keyring torch for the reasons you describe. There are lots of USB rechargeable keyring lights.

Wouldn't it instead be more productive to simply carry a pocket flashlight?

I suspect you're right, but if there's a way to get this code into the AOSP, I'll probably get a couple or few decades benefit out of it, so I don't mind devoting a little time to trying to understand how to solve the problem the 'correct' way.

I should add that in the mean time I'm trying to find a Third Way, using dimple NFC membrane buttons, combined with an automation app (easer or automation, but neither of them allow flashlight operation sadly... open to suggestions) in order to achieve the desired end.

I was disinclined to use a "shake for flashlight" app as the inadvertent flashlight activation will probably get annoying (my work uniform's trousers don't have serviceable pockets, and the tops have a pocket on their bottom edge, so the phone is sort of suspended in front of the hip and gets shaken whilst walking).

If I manage to achieve the end I will report back!

de0u

My son got me a RovyVon flashlight to hang on the dog's leash. Double-tapping the power button locks it on. It is so much better than the light on my Pixel 6a that there is no comparison. I join matchboxbananasynergy in suggesting you try this approach -- for example, try it for a month.

I suspect there is no realistic way to get the LineageOS power-button flashlight feature into AOSP or GrapheneOS in any time frame even faintly approximating a month, so experimenting for a month is, comparatively, cheap.

Doboprobodyne

de0u thank you! I've ordered a type-c rechargeable "Chip On Board" LED keyring light for ~ 5 USD. I think both of you make a sound argument.

matchboxbananasynergy

Doboprobodyne I'd pair this with a "detachable keyring" (multiple versions of this kind of thing exist) so that you can easily decouple the keyring flashlight from your keys, if that's where you plan to keep it, when you're actively using it, so the keys don't get in the way. Even holding it with your keys attached is probably more practical than holding up your entire phone, though. :P

Doboprobodyne

matchboxbananasynergy r134a

You're both very kind. My key-ring torch is already ordered.

I will try to learn how to "develop an app", so a dimple.io NFC membrane-button can be used to toggle the flashlight. If anyone has any tips at all in this regard they will be gratefully received.

I am also not averse to trying to get changes made to the AOSP, if anyone feels able to give me a steer in that regard.

r134a

Not sure if this could be beneficial in any way for u, but i could recommend the Klarus e5 flashlight as an EDC flahlight. It's relatively small, cheap, and pretty multifunctional given its size.

Doboprobodyne

For completeness I should add that I tried the keysh app (pasted the example flashlight script in, instead of the default script, https://github.com/hufrea/keysh/blob/master/examples/flashlight.sh , enabled run-at-startup) but it doesn't seem to have worked.

https://github.com/hufrea/keysh

I will try to stay the course using NFC tags.

leromarinvit

Doboprobodyne

I just tried keysh (thanks for the pointer!) on my Pixel 6 running a slightly modified GrapheneOS (PixeneOS), and it worked immediately after performing the same steps you tried. The flashlight turns on by long-pressing vol-, and off again with vol- or vol+.

This probably won't help you - I just wanted to let everyone know that it's not fundamentally incompatible with GrapheneOS.

Berlino

Doboprobodyne
Doboprobodyne

Thank you so much for pointing this out - just installed it on my devices and it seems to work reliably. This is a good alternative to the power button.

Doboprobodyne

Obviously if anyone has had the keysh app working, I'd be grateful of a steer in the right direction!

Re.: NFC push-buttons: dimple.io is a discontinued product. There are numerous others out there; by way of example: https://air-button.com/product/air-button-customizable-nfc-button-for-android-phones/

Will report back if & when I have this solved.

Doboprobodyne

At the moment I'm just posting an ad on upwork. If anyone has strong feelings re. things I should add/change, let me know.

We are looking for a skilled developer to create an Android application using Python that integrates NFC functionality. The app should be able to listen for a user-programmable NFC tag and toggle the flashlight on detection. Candidates should have experience with NFC technology, Android app development, and Python programming. Code should be as simple as possible, and well documented to aid developers who are asked to maintain it in the future. If you have any relevant projects to showcase your skills, please do include them in your application.

Doboprobodyne

Unfortunately I've been advised there is a system-level limitation in android that prevents use of NFC when the screen is off. Stackoverflow answer tallies here The only way around it seems to be to to spoof the reply, when the system polls to see if the screen is on. I regret I don't want to weaken any of AOSP's built in security.

I'll discontinue this effort. happy to liaise if anyone sees a solution.

Doboprobodyne

leromarinvit
Victory... ish!
Following your report I retried it on my phone, and it worked. Now it isn't working again... no idea what I was/am doing wrong haha.
Anyway thank you for prompting me to persist with this!!

Doboprobodyne

Okay, I think I have it working reliably.

In the system's App Settings, under Battery Usage, I switched it from "Optimised" to "Unrestricted".

It seems fine now.

Thanks :D haha I think we can tell the devs this meme has been put to bed!

matchboxbananasynergy

How does this work, exactly? Do you need to grant the app the accessibility permission? If so, I would caution people against doing so. Many apps that do this exist, but that permission is highly sensitive and gives apps entirely too much access to your device.

Doboprobodyne

Negative. No accessibility permission required. If one checks the tick-box within the app settings to run at start-up, then it executes whatever script the user has told it to.

The example script for the flashlight functionality that we are using is as follows:


set -eu

TO=0.300
DUR_S=30
TORCH_OFF_TO=300
WL_MAX=310000

# Down 300ms = torch on
#           -> Up/Down   = torch Off


on_flashlight() {
    cmd vibrate $DUR_S
    cmd torch on
    while read -t $TORCH_OFF_TO key; do
        [ "$key" = "$RELEASE_DOWN" ] || break;
    done
    cmd torch off
}


on_down() {
    read -t $TO key && {
        cmd volume music down
        return
    }
    on_flashlight
}


loop() {
    while read key; do
        cmd wakelock acquire $WL_MAX
        
        case "$key" in
            "$PRESS_UP" )
                cmd volume music up
            ;;
            "$PRESS_DOWN" )
                on_down
            ;;
        esac
        cmd wakelock release
    done
}


encode_list() {
    ENCODED=""; for arg in "$@"; do
        ENCODED="${ENCODED}${#arg}:${arg}"
    done
    ENCODED="${#ENCODED}:$ENCODED"
}
cmd() {
    encode_list "$@"; 
    echo "$ENCODED"
}

loop

matchboxbananasynergy

Thanks. This app seems to work by acting as a foreground media playback service.

I have confirmed that it does work. Volume down while screen is off will turn on the flashlight.

The trade-off is that you cannot adjust volume while screen is off by long-pressing volume down. You can do multiple short presses, though. That is because while the app is active and "armed", long-pressing volume down will trigger the flashlight.

Doboprobodyne

matchboxbananasynergy
Aaaah clever! Thank you for explaining it. I did wonder how they got around that!

Now that you've explained it, this bit of code makes sense to me:

cmd volume music down
        return
    }
    on_flashlight

Doboprobodyne

matchboxbananasynergy
Begging your pardon; I just uninstalled keysh, and whilst playing media, tried (screen-off) a long press of the volume keys. Only the first press seemed to register as altering the volume by an increment. Holding the button did not continue to "push" the volume up or down, as it would do if the screen were on.

My conclusion is that, at least on my device, there is no trade-off in volume-key functionality when using this workaround.

Yeeehaw! :D