Good Day. Would like to know whether it's possible to use the Unholey light and the AOD Helper in combination with music controls on the AOD. Would like to show these controls always when I play some music (keep the music control on all the times when set to only wake the screen when new notifications appear). Is that possible (with the help of AOD helper to save battery as long as there are no new messages)?
[APP][2021.03.02] Holey Light - Samsung/Pixel Notification LED Emulator [v1.00]
- Thread starter Chainfire
- Start date
Hay
Is it possible to make light notification on Galaxy S21+, to blink on the blank/black display (when notification arrives) together with AOD to be shown when tapping (once) on the screen. (clock + fingerprint sign, etc.. on black display)??
I can't achieve it...?? On any app..
Is it possible to make light notification on Galaxy S21+, to blink on the blank/black display (when notification arrives) together with AOD to be shown when tapping (once) on the screen. (clock + fingerprint sign, etc.. on black display)??
I can't achieve it...?? On any app..
Pretty sure that's not possible. It's designed to use the camera cutout and I don't believe that the Dev has any plans for anything else.
Well yes, to use the camera cutout, to blink on the black screen. But, when tapping on the screen once, would bring the AOD, or to make same appearance with fingerprint logo and clock, on the black screen, to se the notification preview.
You could always ask him in his Telegram Group - But I doubt he'd be interested in doing something different from what Holly Light does now.
The ONLY reason he developed this as it is - is because he uses it.
OK. But am I the only one, who loves one touch, to see the notification, clock and fingerprint on black screen, instead of turning the actuall screen on?
i use it with one touch on screen and it works, i have s21 ultra, the screen turns on for some seconds with aod and comes back all black, when i touch one time the screen the cutout turns on for the time the aod is on, from the original setting i just changed the type of notify and i removed all the 5 pins on the section "mark as read". removing that 5 pins the notify will be deleted only when you have read the notification.
(sorry for my english)
This program works great on my Galaxy S10e, but seems to use quite a bit of battery. I have it set to Blink at 0.5x Speed, only on when screen is off, and under battery it shows the app uses 15%.
My suggestion, and maybe it wouldn't help, but maybe add "Duty Cycle" under Tune? I noticed my Galaxy S8 LED would light up for something like 1-second, but off for 2. Seems like Holey Light Blink mode is fixed at 50% duty cycle so 0.5x speed is 1-second on, 1-second off. I wonder if I could change to something like 33.3% duty cycle if that might squeeze out a tiny bit more battery life.
My suggestion, and maybe it wouldn't help, but maybe add "Duty Cycle" under Tune? I noticed my Galaxy S8 LED would light up for something like 1-second, but off for 2. Seems like Holey Light Blink mode is fixed at 50% duty cycle so 0.5x speed is 1-second on, 1-second off. I wonder if I could change to something like 33.3% duty cycle if that might squeeze out a tiny bit more battery life.
Try the Unholey Light option, that use less battery. I like the icon on the off screen.
Hello, here to report the app work on Samsung M21, and the tuning for it is :
Scale base : +5.00dp
Scale horizontal : +3.25dp
Shift vertical : -5.00dp
Shift horizontal : +21.00dp
I added a 2.50dp thickness for good measures.
Ty for the app, it look nice in combination with "Muviz edge" definitely check it out if you never did guys.
Cheers
Scale base : +5.00dp
Scale horizontal : +3.25dp
Shift vertical : -5.00dp
Shift horizontal : +21.00dp
I added a 2.50dp thickness for good measures.
Ty for the app, it look nice in combination with "Muviz edge" definitely check it out if you never did guys.
Cheers
In contrary to early LOS17 users I can successfully finish the setup wizard under LineageOS 18 and change all required permissions and settings, except that it aways complains to me that Always On Display needs to be enabled in the settings. (the option in the lockscreen settings to always show time and information is ON though).
Can Holey Light be mapped to this Always on Display feature which seems to be similar to Samsungs AOD?
Can Holey Light be mapped to this Always on Display feature which seems to be similar to Samsungs AOD?
I am on LOS 18.1, but with AOD on, i dont get the Unholey light to work. The AOD is hidden, but i get no notiffications on the display. The other options work tho. Seems like a LOS + Pixel issue. According to the git repo, it is not yet supported.
Edit: does the battery drain level per hour means when there is active notiffication, with default speed/thickness? And do values differ per brand/model?
Last edited:
Go to the OP (post # 1) and join Chainfire's Telegram Group - You'll get faster answers & likely from the Dev himself.
I just bought a Samsung Galaxy S20+ and noticed an issue with Holey Light. I was using a Samsung Galaxy S10+ before and Holey Light worked perfectly. For some reason, on my S20+ Holey Light doesn't seem to detect the notifications from Google Voice. When someone messages me through Google Voice, Holey Light doesn't see it so it doesn't show me the holey light or unholey light notification. Strangely, Holey Light seems to work with everything else on my new S20+. I've tested it with WhatsApp, Signal, FB Messenger, and the default Samsung Messages app. All those are working. It's only Google Voice that's not working.
Did you set Google Voice's colour setting in Holey Light?
If it's set to black - you won't see any notifications for it.
I don't use Google Voice - So I can't say for sure if it works for it?
That was it! Thanks a lot! I wonder why Holey Light automatically selected colors for the other messaging apps but left Google Voice set to black? Anyway, thanks to you, it works now.
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
185100% Free - 100% GPLv3 Open Sauce - No ads - No tracking - No nags - Optional donation
Holey Light is a LED emulation app. It animates the edges of the camera cut-out (AKA punch-hole) as replacement for the sadly missing LED on many modern devices.
Additionally, it provides a notification display for when the screen is "off", replacing - or working in conjunction with - the Always-On Display feature. As this display is not around the camera hole, it is aptly named the Unholey Light.
Supports all Samsung devices with in-screen camera hole, and several Google Pixels.
Features
- Emulates notification LED
- Four different display modes: Swirl, Blink, Pie, Unholey Light
- Configurable animation size, position, and speed
- Customizable color for each notification channel
- Selects initial notification color by analyzing dominant color of app icon
- Displays during screen "off", sub-1% battery use per hour in Unholey Light mode
- Separate configuration modes for different power and screen states
- Ability to mark notifications as seen based on various triggers
- Respects Do-Not-Disturb and AOD schedules
- Can hide AOD completely, partially, and/or keep the clock visible
- Additional AOD Helper package for further battery usage reduction
It's all on GitHub!
Download
You can grab it from Google Play.
Feedback
You can feedback here. Or in the GitHub issue tracker. Or talk to me on Telegram. I guarantee no response or fix.
The workings of the app are quite intricate, so describe what is happening in minute detail.
TODO
You can find the TODO list in the issue tracker.
Enjoy!
Or not.33v0.40 is here
So, it was quite a journey to get to this point, and I am sad to report I am not fully satisfied with the results so far. But I have more than exhausted the time I have available for side projects, and I need to focus on work for a while now. There are further gains to be had, I'm sure, possibly someone else will figure it out while I'm doing other things
The past weekend I've dedicated entirely to investigating power and CPU use, how AOD functions, etc. A lot has been done on the main code-base to reduce its usage (such as replacing live animations with pre-rendered sprite sheets), but on that front we have reached the point of diminishing returns. There's not much more to be improved in that part of the code. It was a lengthy merry-go-round, as fixing things in one place would break things in another. Here's some technical mumbo jumbo for all y'all to enjoy.
First, there was the move to accessibility services. Should have been using those from the start, but I decided against it because (a) I botched up my first attempt, (b) it is frowned upon by Google (but apparently still grudgingly accepted for now), and (c) it's just unclean. On the other hand, Google has nerfed all the other ways to overlay (in favor of their upcoming "bubbles" contraption), so there's little choice left. This allowed for simplification of part of the codes and getting rid of the fake lockscreen, in favor of piggybacking on AOD. Unfortunately that itself has not brought all the improvements I had hoped. We still need to use the CPU quite a bit, and though we now have the advantage of the screen being in a lower power state and other apps being more restricted from running (both improving battery life), I've still clocked it at 3.5% (worst-case, down from 5.5%) per hour. Obviously this is only when you actually have notifications, otherwise it doesn't any battery at all.
It is my understanding right now (and this may in time prove to only be partially correct, or even completely incorrect), that AOD periodically offloads an image (the background, notifications, clockface without hands) to the display, and a separate process (sidekick? outside of Android? dedicated hardware?) updates the screen with the smaller changes (such as the clock hands). This allows the main CPU to be fully asleep while you still see a clock with a moving second hand on screen, using sub-1%/hour battery power. AOSP has supporting code for this, so it's possible. Additionally, I've experimented with hiding AOD by drawing black on top of it - and the clock's hands remain visible while everything else disappears. Interesting stuff, for sure (stay tuned for more tales of interest).
Overlays apparently are not part of this 'saved' image (I'm sure I saw a reference to how this is done somewhere in AOSP source, but I can't find it anymore, good job bookmarking that), so as the screen goes into its lowest power mode, they disappear. To counter this, we need to keep updating the screen (I had a work-around for this at some point, but it needs further investigation still). Some of you noticed the swirl didn't "time out" as the blinker did, that is because the swirl updates at a higher FPS. That high FPS keeps an internal lock deep in Android active, preventing the lowest power mode from being enabled. I've spent quite(!) some time trying to get to that lock, but to no avail. The only alternative is updating the view layout regularly, which also pokes that lock (after going through a long path of many other functions): this keeps the app's CPU usage down, but I later discovered this triggers high CPU usage in system_server, and so it was a net loss. There have been several instances of me saving 10-20% in one place just to have it pop up somewhere else, just because we don't have a direct path to the code inside Android we actually want to trigger. In the end, I've upped the FPS of the slower animations to 5-10, which seems to keep the screen happy (at least for me), as long as I don't have a better solution.
I've also done some experiments with a shell runner (code that needs to be started through adb with a PC, or through root if you have it), which had some interesting results. Though inconvenient, it does give us access to a number of permissions we can use to manipulate power states. Unfortunately, for most of it there still doesn't appear to be a way to actually do so - no path to the correct Android internals. If I have the time it any point in the future, I'll dig a bit deeper into that, but my opinion right now is that it'll probably require proper root and changing (overlaying) some system files and/or settings.
I've decompiled and analyzed a lot of Samdroid's packages, but so far haven't found the holey grail (See what I did there? Now I need to make a new app with that name...)
PS: This one will be going up on Play ASAP
PPS: For those reading on GitHub, the sauce is up, but I have not updated all the info yet, and that may not happen today
PPPS: I saw some translations come by, please update them to the texts from this version and re-post, thanks. GitHub pull request would be even better, but I understand if that's not your cup of tea
PPPPS: For the devs: there's some interesting stuff and comments in the code if you look closely
As always with these releases, it was probably working fine this afternoon and I botched something major up just before releasing this update, so come at me with your bugs and observations
Most significant changes (this includes things already in v0.26)
- Screen off + battery functionality enabled
- Migration from fake lockscreen to AOD-base
- Migration from application to accessibility overlay (Google frowns on this, though)
- Any notification can now be used for LED. The ones that don't ask for LED show up under Colors as black by default.
- Lottie renderer has been replaced by a sprite-sheet based rendered (up to 5x CPU reduction)
- Battery saving animations added (up to 3x CPU reduction), blinking and pie-chart (decided based on full or on-tap AOD)
- Several leaks and crashes have been fixed (and undoubtedly new ones created)30Good news everyone! I have it all running smoothly now. The code need some cleanup, dead code removal, fixing up some bad test code into "meh" production code, some installation helpers, etc, but I have the basics all working as I want them.
Going to run it overnight to see what the drain is... release hopefully tomorrow.25Now that I've figured how AOD works, I mostly finished up the AOD hiding (even without the addon package, but the latter is still better on battery if there are no notifications), now I just need to clean up the UI (oh no!) and provide ample in-app instructions and guidance, then I can release that to Play and continue on the other features (such as schedule/dnd, etc).
This cleaning up is my least favorite part of devving. It already works fine for my own uses now.
