{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This application is made for enhancing or changing some feature for galaxy S
Requirement
1. machine
galaxy S (all variant)
2. version
Froyo (kernel 2.6.32.9)
3. rooted phone*
(*After checking "use with unrooted" option, you can remove rooting)
Feature
1. IO scheduler change
It can change CFQ(default) to deadline for some block device.
This change affect response time of disk IO.
(If you are using the application which handle many small files. You can feel better responsive reaction)
2. LCD color adjustment
(Test version)
This can be helpful to adjust so blue or yellow LCD.
3. Sound (3D, Hardware Equalizer)
It affect all system sound. so, If you change some parameter, all system sound(music, movie, radio..) will be affected.
How to test.
When you are hearing the music, As soon as changing the parameter, you hear different sound.
4. Memory Manager
Because It is controlled by kernel and android framework, It is more powerfull and efficient then memory killer.
for more info visit this link (thank to androcheck)
http://forum.xda-developers.com/showthread.php?t=622666
5. Over Clock (1.2Ghz)
OC feature is harmful to your phone. so, I put some restriction for preventing abuse.
(OC kernel user do not use this feature. I didn't consider OC kernel. and, I don't know about OC kernel)
6. Firmware(kernel) writing
you can write kernel(zImage) directly. and. can enter into recovery,download mode via this app.
7. use this app with unrooted
(Fort this. you must check "use with unrooted" option. before unrooting)
8. Bad block check (for ext filesystem)
If There are bad blocks on your ext filesystem. You can experience lag,abnormal app exit,slowness
9. key(Button) remaping Feature added
Volume Up,down key can be remapped to other key. (This is tested on M110S)
10. Touch gesture
It can map total 6 key button with Touch gesture.
11. Orientation Fix (especially Landscape mode)
It is helpful to view Landscape lying
How to download
search with this keyword on the market (galaxy tuner or d.w.kim)
Technical note
* LCD color and Sound function is accessing chipset resister directly.
* because, I don't have mDnie(LCD), wm8994(Sound) datasheet. I could not implement many feature.
* all system changing is volatile. so, If you reboot your phone. all system state is identical to original state
* OC function in this app change governor(performance, conservative..) policy. so, consider changing governor policy from like set cpu app
* running without rooting is a little tweak. It still require root privilege.
* more detail technical note
http://blog.naver.com/dowkim10/120122503306
* more about sound Howto
http://forum.xda-developers.com/showthread.php?t=921736
(Thanks to supercurio and studiominal)
Version note
1.3
The first version for all galaxy variant.
1.4
memory manager feature added
1.5
- color, sound (on boot adoption)
- memory manager (add some reinforced feature)
- bug fix for voodoo 5.2 patched kernel user (previous user must reboot once or reinstall for working)
1.6
OC (Over Clock 1.2Ghz) feature added
1.7
working on unrooted state.
1.8
Firamware(kernel) writing Feature added.
1.9
Bad block check(ext) Feature added
2.0
key(Button) remaping Feature added
fix bug (running Galaxy Tuner service at any time)
2.1
Orientation Fix (Feature added)
Sound (add option)
(it will clear user sound profile)
Memory Manager (Enhancement)
bug fix (on boot adoption is not worked sometimes)
2.2
Memory Manager (add VM control)
Key mapping( more button mapping added)
2.3
key mapping(Power key as Power+ headsetHook)
touch gesture feature added
Bug note
beta test version note
It is pre version for testing bug fix and add-on feature before releasing market
try attached file
Thanks dw kim. The app is amazing. I tried it with a couple of Mr Big songs. Is it like a parametric equaliser? Anyway, it's amazing how bassy it can achieve. The color temperature is great, I've always thought colours of my pictures were way too greenish, now I can adjust it to look more natural. Any way we can save it as boot settings?
Thank you very much.
I'm very happy It's working on your phone.
(You are first user except korean)
According to wm8993 manual(I don't have wm8994 manual). It is parametric equalizer.
It does not support on boot setting.
(but, I consider this function. I suggest you saving and loading user profile)
Haha, I am glad I am the first customer. Yes, the user profiles helps a lot.
Well, I think Supercurio, maker of Voodoo kernel, (maybe you already know him) has the Wolfson WM8994 manual? You could try ask him, he has a thread about sound here.
http://forum.xda-developers.com/showthread.php?t=806195
Btw, my phone is the international I9000.
Thanks a lot.
but, I don't have update plan right now, and I know him as very famous people.
so, I don't want to bother him.
No worries, dw kim, he's super helpful guy! Okay, relax, that app will make many ears happy already.
Btw, my favourite settings is +9, +6, +5, +7, +11. I think it's perfect. Using stock SGS earpiece.
It is too high gain.
How about extracting constant value on every band. and, volume up. (maybe same effect)
Too high value can make sound noisy
3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.
stfudude said:
3d sound doesn't seem to work. o_0
one more thing: I'm using bluetooth A2DP.
Click to expand...
Click to collapse
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?
Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...
pandomu said:
Great app!!!
Is there any posilibity to make it "autostart"...?
every time i reboot my phone I have to turn the settings on...
Click to expand...
Click to collapse
I am considering. It is not difficult to implement.
(IO scheduler menu has this option)
but, I am afraid to add this option (LCD, Sound)
because, It handle hardware.
If There is no special case (after changing Sound, Phone is died)
I will add on boot option.
This application is not background application or service.
After setting a sound parameter, you can kill or remove from memory.
Just reporting that it works perfectly well with international GT-I9000 version.
For me, CFQ scheduler works best.
Thanks very much, i haven been waiting months for this
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom
pwhooftman said:
Hi Dowkim,
Thank you very very much. I have been waiting months for an application to adjust LCD color, but i had to either flash a kernel or accept that the camera stopped working. Your app works perfectly, thank you!
A suggestion: in the screen when adjusting color, you could add a colour testpattern so one can see the effect of the changed colors immediately.
Galaxy 9000 International Speedmod Rom
Click to expand...
Click to collapse
Thanks. That is good idea.
I'll try. (but, I am poor at android programming)
dowkim10 said:
(but, I am poor at android programming)
Click to expand...
Click to collapse
I didn't notice for sure
Awsome work on this app. The music controls all work perfectly and make a huge difference in volume which i always thought was to low.
Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.
dowkim10 said:
This application access Sound chipset register directly. It is not software Equalizer.
If sound stream is transfered via bluetooth devcie. (without path of sound chipset)
you can not experience sound effect.
How about earphone or headphone ?
What is your phone model?
Click to expand...
Click to collapse
International I9000
supercurio said:
Hi dowkim10, this is interesting work.
I thought a lot about how to design the Voodoo sound driver and the consequences of the design chosen.
I took a different approach than yours: coding also a new driver, not as an independent .ko but using hooks in the actual source of the sound drivers to stay portable.
I believe a few limitations of the design you use are :
- It will be hard to add improvement like the microphone input auto-gain I prepare for the next version.
- Same thing for the FM radio bass solution
- Next to impossible for the upcoming audio jitter issue resolution
- Pretty hard and encumbered for adjusting other various input/ouptut gains/levels here and there
As kernel modules, like the scolor.ko and ssound.ko have a lot of power, in theory everything is possible but Galaxy S devices have so much different versions that implementing a module overriding some functions from the actual driver without breaking anything on a device or another will probably lead to very dirty code and headaches to maintain.
I thought of implementing everything using the wm8994_write dynamic register rewrite technique described here, also by inserting .ko modules like you do.
But here is what's in Voodoo sound source code:
https://github.com/project-voodoo/l...-voodoo/Kernel/sound/soc/codecs/wm8994.c#L215
https://github.com/project-voodoo/l.../Kernel/sound/soc/codecs/wm8994_voodoo.c#L270
By sniffing sequences of register address / value pairs, you should be able to recognize some patterns and add custom changes into it to extend your implementation.
But again, quite a dirty design
Good think of course it's the awesomeness of not requiring a custom kernel.
Of course my approach requires to publish every single piece of Kernel work as GPL and convince a lot of kernel developer to apply these patches, including eventually Samsung and Google.
But it's how I like it
As you distribute and insmod .ko modules, you're not forced to release source for them, but I advocate for Open Source.
Also, you will find a lot more code and ideas you will be able to re-use in the next Voodoo sound versions, about how to handle the parametric EQ and avoid saturation, and a lot of things like that.
Again, GPL will be a lot preferable.
bug report: mDNIe settings you use are lost after running Video player, Camera application (every app sending new mDNIe settings affecting the color response)
PS: don't be afraid to contact me, I am 70% of the time connected to IRC to discuss with and provide support to users and developers in real time.
Click to expand...
Click to collapse
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.
dowkim10 said:
Hello supercurio
First, I am honored to meet you.
I know someone in korea said existence of this application. and, talked with you.
I also know you did very great job on galaxy kernel.
When I saw your sound code and mDnie code. I think you developed all passion and soul with many trial and error.
Absence of document maybe a excuse.
I have worked for ten years on embed linux. and treating many architecture(arm, ppc,mips,x86.) and treating kernel from 2.2 (now 2.6)
and, a few years ago, I ported android kernel to many board(arm v5,6,7 and xscale) and implemented HAL layer(GPS, alsa, bluetooth..) (android 1.0 around)
but, now I don't have relation Android in my job. so, I am doing this for my hobby. (I don't have enough time)
I know the risk of kernel module. wrong code or accessing bad address can cause system dieing.
but, basically, built-in and kernel module is same.
And, I didn't use your code. this module is treating only a few register.
Anyway, I am very nice to meet you. and many thanks for your advice.
( I hesitated to contact you. I'm a little shy)
If I keep my composure. I'll contact you via IRC.
Thank you.
Click to expand...
Click to collapse
Hi! be sure the honor is shared.
Thanks for your answer,
I see you not only speak Korean and English languages with ease but also I2C at least
Yes the absence of any sign of documentation about mDNIe forced to use the reverse-engineering approach ^^ as I had no experience in Kernel development a few months ago it was a lot of trial and error.
Now Samsung have given a little details in their new source code release about mDNIe controls, which is definitely a move in the right direction.
I'll try to get the doc for this chip.
I agree the first Voodoo sound implementation was crude, that's why I never activated and rewrote it from scratch for the release.
You're a much more experienced kernel and embedded developer than me!
Come on, don't be so shy, I'm just a rookie compared to you
See ya!
Related
Attached is a kernel source patch that fixes the EB13 camera video lag and "Sports" scene mode force-close. It's actually the same kernel bug that's responsible for both.
Also attached is an Odin/redbend-flashable, otherwise stock EB13 kernel with this patch applied. It's intended for anyone who wishes to further test the fix and who is familiar with Odin and/or redbend_ua. For others, I'd recommend waiting until one of the custom kernels integrates the patch or until Sprint releases an official update.
I'll update this post in the morning with a workup of the bug (done, see below), since it's a bit interesting/illustrative. And yes, it's very simple and very silly. One of those things that really never should've happened. Thanks to everyone in the solutions thread for providing clues that were instrumental in locating it.
Bug details:
Shortly after the release of EB13 folks reported lag when recording videos, particularly in low light. Although not obviously related at the time, folks also reported that switching to "Sports" scene mode results in a force-closed (and in my experience, renders the screen inoperable as well, sigh). Folks in the solutions thread also reported that (i) these problems are new to EB13, they weren't present in DK28; and (ii) replacing the user-space camera components (app, libraries, etc.) with DK28 versions did not resolve the problems, implying they were likely due to one or more kernel bugs.
Unfortunately we do not have the DK28 source code to compare EB13 against, but at least knowing that these problems weren't present in DK28 helps narrow down the possible bug locations quite dramatically. Furthermore, it's quite likely that this bug was introduced rather recently, as I imagine it would've been caught by internal testing had it been present in say, December.
So with that in mind, I sorted the kernel source files by modification time and started looking for the most recently-changed files that might be relevant to the camera driver. "include/linux/videodev2_samsung.h" was the first hit with a modification date of 2/8, and indeed it's used by the camera driver ("drivers/media/video/victory/ce147.c", itself last modified on 12/1). Again, we don't have DK28 sources for comparison, but fortunately header files typically don't change too significantly and a comparison (diff) against the DI18 version was rather easy to follow.
And yes, a snippet of code stood out right away as rather strange, especially given the cirumstances of the problem:
Code:
enum v4l2_iso_mode {
ISO_AUTO = 0,
ISO_50,
ISO_100,
ISO_200,
ISO_400,
ISO_800,
ISO_1600,
ISO_FIREWORKS, // Added since DI18.
ISO_SPORTS,
ISO_NIGHT,
ISO_MOVIE,
ISO_MAX,
};
For folks less-familiar with C, this code defines an enumerated type, basically a mapping of "descriptive labels" to numeric values; in this case: ISO_AUTO=0 ISO_50=1, ISO_100=2, etc. This enables kernel code to contain descriptive statements like "iso_mode = ISO_200;" instead of the more arbitrary "iso_mode = 3;".
Now, as the above comment (which I added, but the diff points it out) suggests, ISO_FIREWORKS is a new speed that was added to the middle of the enum since DI18. Seasoned C programmers will recognize that, this is often something that leads to trouble. To understand why, compare the "before" and "after" enum mappings:
Code:
Before: After:
ISO_AUTO: 0 ISO_AUTO: 0
ISO_50: 1 ISO_50: 1
ISO_100: 2 ISO_100: 2
ISO_200: 3 ISO_200: 3
ISO_400: 4 ISO_400: 4
ISO_800: 5 ISO_800: 5
ISO_1600: 6 ISO_1600: 6
ISO_SPORTS: 7 ISO_FIREWORKS: 7
ISO_NIGHT: 8 ISO_SPORTS: 8
ISO_MOVIE: 9 ISO_NIGHT: 9
ISO_MOVIE: 10
The addition of ISO_FIREWORDS to the middle of the enum shifts the mapping of any labels below it, in this case ISO_SPORTS, ISO_NIGHT, and ISO_MOVIE. This isn't fatal, but it does mean that all code that uses the enum needs to be recompiled to reflect the new mapping. Often, kernel header files contain data types that are exclusive to the kernel, so any relevant code gets recompiled as part of the process of compiling a kernel.
But as it turns out, the entries in this enum are used in exactly one location (on the Epic anyways) in the kernel: as a case in a switch statement in the camera driver that sets the ISO mode in a camera hardware register. This means, assuming these values are used at all, they must be provided by a user-space library. In other words, the enum mapping is an integral part of the driver API, and not something that can be altered willy-nilly.
So basically, on EB13 when the Camera app goes to record a movie, it sets mode ISO_MOVIE (9), which the kernel interprets as ISO_NIGHT and sends to the camera hardware. Presumably ISO_NIGHT biases picture quality over shutter speed, hence the blurry laggy video when recording. Similarly, ISO_NIGHT => 8 => ISO_SPORTS (which no one noticed), and ISO_SPORTS => 7 => ISO_FIREWORKS. Except ISO_FIREWORKS isn't implemented, so the driver call fails which results in the force close. Oops!
The fix is fairly simple, just remove ISO_FIREWORKS from the enum. This allows the kernel and the user-space libraries to agree on the mapping. And since ISO_FIREWORKS isn't even implemented in the kernel, no harm can possibly come from it.
Finally, as I stated earlier, this is a bug that never should've happened, for two reasons. First, it was introduced into the Epic kernel source tree after DK28. Now, keep in mind that DK28 was effectively a Froyo "release candidate", especially given that it was packaged up as an OTA update and accidentally pushed to some handsets. Any changes made to the kernel post-DK28 should be limited to strict bug fixes only. The addition of ISO_FIREWORKS to the enum is not part of any bug fix (indeed it introduces one), rather one would consider it a "new feature". But "new features" shouldn't creep into stable code trees. This suggests poor code management.
Second, this alteration would've been a non-issue had ISO_FIREWORKS been appended to the end of the enum, just before ISO_MAX (which, presumably just reports the numer of entries in the enum as opposed to describing a particular mode). This would've assiged ISO_FIREWORKS to an unused value, instead of remapping existing values. Adding ISO_FIREWORKS to the middle of the enum is a particularly short-sighted choice, as it immediately renders any code that uses it unnecessarilly incompatible with new kernels. Adding ISO_FIREWORKS to the end preserves backwards compatibility, for free, with absolutely no downsides--why not do that instead?
So, in short, the failure to properly consider both of these issues, as well as the neglect to notice the change, bespeaks of an incompetent moment on the part of Samsung. If the change really was made on 2/8, one can't really blame Sprint for failing to pick it up during last-minute testing. I'm not sure how much this particular bug was a factor in Sprint pulling the EB13 update, but it's pretty embarassing that it made it out there in the first place.
Mirror links (does not require forum login):
epic_camera_fix-EB13.diff
epic_camera_fix-EB13.tar
epic_stock-EB13.tar (for flashing back to the stock EB13 kernel)
Thank you! This will be in the ACS kernel team's kernel.
Excellent, patching up as we speak.
Sent from my SPH-D700 using XDA App
Just wanted to be 3rd
Sent from my SPH-D700 using Tapatalk
Cool, looks good.
Sent from my SPH-D700 using Tapatalk
patching myself too thx will be in Genocide Kernel 0.3a
THANKS! leave it up to xda to do a better job then Samsung lol
Sent from my SPH-D700 using XDA App
Sweet,
tested working perfect. the LSD trails in video are gone and no FC in sports mode. TY so much.
fix worked great! i just released genocide 0.3a with this patch included! thanks again!
Gotta love 1 line fixes
Would like to try this but only have mac os so odin...
Awesome, thanks man!
Sent from my SPH-D700 using XDA App
Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
-Edit-
Okay, used Odin, put patch in PDA with nothing else set. Worked perfectly! Thanks to all!
You sir a genius....thx for this fix!!!
What is sports mode? I can't find it.
Silent25r said:
What is sports mode? I can't find it.
Click to expand...
Click to collapse
Still camera, settings (gear button)>Scene Mode> Sports Before the fix it's an automatic FC
Can't wait to hear the details behind the bug.
Sent from my SPH-D700 using XDA App
This patched worked perfectly on the genocide kernal!! Thanks For Your Hard Work!!
Now Just Waiting For Bonsai!!
The geniuses at XDA strike again! Brilliant! Thanks!
MoCoTerp said:
Noob question.
Do you put this in PDA? Also no need for PIT or modem file right?
Via TapaTalk on Nook Tablet
Click to expand...
Click to collapse
Help please? I've flashed lots of roms but never a kernal like this. i'd like to stay with the stock ROM. Can't find anything on a search. Can someone either post a link or instructions.
AerialX said:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default... I decided on the "slow" version - 8bdefb7e - as it's the most compatible option. The "fast" version can be chosen as a preference for those who prefer the speed. It may not work on all devices, and seems to produce artifacts and some tearing, though it probably is preferable for most simply due to the speed.
So, here you go, latest version: Download
Built for ARM and ARMv7, does not include the NEON extensions. You may want to uninstall the old one before installing this.
EDIT: Fine, have a NEON build too: Download
Hint: the main change is the inclusion of settings. I consider this build to be very close to the initial release for the application on the Android Market. Just a few things remain...
What's Left
In order of priority...
Filtering of non-white-screen presets. The app will include the projectM preset library by default, excluding any that just result in a white screen. I don't believe I will be able to distribute any of the Winamp/MilkDrop library itself, as awesome as it is.
Stability enhancements. It's probably still somewhat crashy. I'm not sure how much, though. I'd love to get some detailed reports on how stable/crashy it is for you guys.
snoop() support, otherwise the wallpaper requires 2.3... I don't have anything older though. Would anyone be able to test on an older OS for me if I supplied a build?
x86 support. Means writing a few missing STL pieces.
NEON detection, and the loading of an appropriate optimized library. I get the feeling that this is just a placebo, but will try to get it in.
Optimizations. Would be nice if it didn't essentially restart every time you visit your home screen. I'm probably leaving this for a 1.1 release though.
Localizations. If anyone wants to help translate the settings page into their native tongue, I'll happily include them.
Anything else I forgot...
What I Need
It would be great if anyone who tries it can comment on its stability. Whether it often dies, reverts to some other wallpaper, completely kills your system, or whatever. Just give me your overall experience with the wallpaper. I'm not necessarily interested in hearing about its performance at this point - if it runs slowly on your phone, I suggest switching to the "fast" render method and only using presets that run speedily. Of course, miscellaneous suggestions / comments / criticism are welcome as well!
Another thing I was hoping someone could do is go through all the presets and filter out the bad "white" ones. The new settings page makes it easy to test a single preset at will. So if anyone is willing to do this, I could really use two zips: one containing all working presets from the projectM set, one containing all from the MilkDrop set.
As a base for the projectM set, please use this: Download
For the base MilkDrop set, find the attachment from a few pages ago.
You may also want to note any that run particularly slow, but please don't exclude them from these packages.
EDIT: As a test, feel free to try the exact same preset on both the non-NEON and NEON builds and see if there's any noticeable improvement there.
Click to expand...
Click to collapse
Hands down best app ever
Sent from my LG-P999 using XDA App
Any screenshots?
Um seems to be a few post missing in this thread... Usually when something starts like this:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default...
Click to expand...
Click to collapse
What results are we talking about here? What is this exactly? Kinda like writing a book that starts:
But when the baby came out looking like death on a hot tin roof, Jim finally found the nerve to call her out and say, "Devil wench, I will not accept that thing as my my spawn! I know you have been sleeping with your brother!"
Dear all,
I am going to start a new post for the new 1.7b1 & 1.7b2 beta such that all members are able to see them.
First, specially thanks to UnknownzD for providing the source codes for Voodoo Sound enhancements to Galaxy R. You are the man!
Now, after posting the v1.7 beta kernel to some Chinese forum, it is discovered that kernel based on ZCLD4 will cause 'auto rotation' malfunction on non-Chinese ROMs (such as XWLA4, ZSKK5, etc...)
It is also proved that kernel based on XWLA4 will not cause any 'auto rotate' problems, but it does not support 2-way voice recording & off-machine alarm.
So, I have revised 2 versions of v1.7 beta. Both version inherits all features from v1.6 & Voodoo Sound enhancements.
v1.7b1 (beta 1) (based on ZCLD4 Chinese kernel)
==================================
- Well support for Chinese based ROM (such as ZCKK1, ZCLA1, ZCLD4, etc...)
- Will not cause any 'auto rotate' problems on Chinese based ROM, but will have rotate problem on European ROMs
- Support 2-way voice recording & off-machine alarm (Chinese-based ROMs only)
File: ardatdat_9103_kernel_v1.7b1_voodoo.zip
Link: http://www.mediafire.com/?bga4dzubid3sbe2
Mirror: http://115.com/file/dpjuugye#ardatdat-9103-kernel-v1.7b1-voodoo.zip
v1.7b2 (beta 2) (based on XWLA4 European kernel)
==================================
- Well support for non-Chinese based ROM (such as XWLAL4, ZSKK5, etc...)
- Will not cause any 'auto rotate' problems on any ROM
- Doesn't support 2-way voice recording & off-machine alarm
File: ardatdat_9103_kernel_v1.7b2_voodoo(XWLA4).zip
Link: http://www.mediafire.com/?by26ah33aw2cdv9
Mirror: http://115.com/file/benbs1h9#ardatdat-9103-kernel-v1.7b2-voodoo(XWLA4).zip
Please feel free to choose the one that suits your ROM.
v1.6 could be found there:
http://forum.xda-developers.com/showthread.php?t=1620900
Again, I need some time to organize the source codes, please accept my apology as I am really busy in my work. I will push it to github once I organize them & am free.
Finally, flash at your own risk Please feed back how you feel and don't hesitate to give me a 'thank' if the kernel works great for you
** The source code has just been pushed to my github. Please kindly share our knowledge to make this phone better!
reserved for future use...
Files are uploaded Thanks for waiting ~!
ardatdat said:
Dear all,
I am going to start a new post for the new 1.7b1 & 1.7b2 beta such that all members are able to see them.
First, specially thanks to UnknownzD for providing the source codes for Voodoo Sound enhancements to Galaxy R. You are the man!
Now, after posting the v1.7 beta kernel to some Chinese forum, it is discovered that kernel based on ZCLD4 will cause 'auto rotation' malfunction on non-Chinese ROMs (such as XWLA4, ZSKK5, etc...)
It is also proved that kernel based on XWLA4 will not cause any 'auto rotate' problems, but it does not support 2-way voice recording & off-machine alarm.
So, I have revised 2 versions of v1.7 beta. Both version inherits all features from v1.6 & Voodoo Sound enhancements.
v1.7b1 (beta 1) (based on ZCLD4 Chinese kernel)
==================================
- Well support for Chinese based ROM (such as ZCKK1, ZCLA1, ZCLD4, etc...)
- Will not cause any 'auto rotate' problems on Chinese based ROM, but will have rotate problem on European ROMs
- Support 2-way voice recording & off-machine alarm (Chinese-based ROMs only)
File: ardatdat_9103_kernel_v1.7b1_voodoo.zip
Link: http://www.mediafire.com/?bga4dzubid3sbe2
Mirror: http://115.com/file/dpjuugye#ardatdat-9103-kernel-v1.7b1-voodoo.zip
v1.7b2 (beta 2) (based on XWLA4 European kernel)
==================================
- Well support for non-Chinese based ROM (such as XWLAL4, ZSKK5, etc...)
- Will not cause any 'auto rotate' problems on any ROM
- Doesn't support 2-way voice recording & off-machine alarm
File: ardatdat_9103_kernel_v1.7b2_voodoo(XWLA4).zip
Link: http://www.mediafire.com/?by26ah33aw2cdv9
Mirror: http://115.com/file/benbs1h9#ardatdat-9103-kernel-v1.7b2-voodoo(XWLA4).zip
Please feel free to choose the one that suits your ROM.
v1.6 could be found there:
http://forum.xda-developers.com/showthread.php?t=1620900
Again, I need some time to organize the source codes, please accept my apology as I am really busy in my work. I will push it to github once I organize them & am free.
Finally, flash at your own risk Please feed back how you feel and don't hesitate to give me a 'thank' if the kernel works great for you
Click to expand...
Click to collapse
Actually 2 way calling recording can be enabled on XW firmware as well, you just need to enable the config in the defconfig file. However as I believe it may conflict with the voodoo sound, I have hold the process of enabling it.
I am on thurs kernel.it's awesome. Voodoo too awesome
Sent from my GT-I9103 using XDA
UnknownzD said:
Actually 2 way calling recording can be enabled on XW firmware as well, you just need to enable the config in the defconfig file. However as I believe it may conflict with the voodoo sound, I have hold the process of enabling it.
Click to expand...
Click to collapse
Even if it could be enabled, there is one great feature of "off-machine" alarm in Chinese based ROM only. This feature allows you to set an alarm and then you shutdown your phone (while keeping your cable charging the phone). Just before 2 minutes before the alarm, the phone will be turned on automatically and the alarm will ring!
For example, the time now is 10:00, you set an alarm at 10:10 and you turn off your phone. At around 10:08, the phone will boot up automatically! And the alarm rings precisely at 10:00!
You can try that feature using Chinese based ROM such as ZCKK1, ZCLA1, ZCLD3, ZCLD4, etc... Thanks
ardatdat said:
Even if it could be enabled, there is one great feature of "off-machine" alarm in Chinese based ROM only. This feature allows you to set an alarm and then you shutdown your phone (while keeping your cable charging the phone). Just before 2 minutes before the alarm, the phone will be turned on automatically and the alarm will ring!
For example, the time now is 10:00, you set an alarm at 10:10 and you turn off your phone. At around 10:08, the phone will boot up automatically! And the alarm rings precisely at 10:00!
You can try that feature using Chinese based ROM such as ZCKK1, ZCLA1, ZCLD3, ZCLD4, etc... Thanks
Click to expand...
Click to collapse
btw please upload your kernel src asap, I have already heard some complaints in project voodoo, saying that the kernel src not in public is violating the GPL (General public license) :\
thnks, the accelerometer works fine now
UnknownzD said:
btw please upload your kernel src asap, I have already heard some complaints in project voodoo, saying that the kernel src not in public is violating the GPL (General public license) :\
Click to expand...
Click to collapse
No worry, actually, not exposing the kernel src is actually violating the general rules in XDA. Give me some time, I am working on that
ardatdat said:
No worry, actually, not exposing the kernel src is actually violating the general rules in XDA. Give me some time, I am working on that
Click to expand...
Click to collapse
btw I have another performance boost for your kernel build.
Check here for more info :
https://github.com/UnknownzD/I9103_XW_Kernel/commit/5272617914704968960e16e68e6a62150434c5a9
You need to add the following things to KBUILD_CFLAGS
-O2 -march=armv7-a -mtune=cortex-a9 -mcpu=cortex-a9 -D__ARM_ARCH_7__ -D__ARM_ARCH_7A__ -D__VFP_FP__ -D__ARM_HAVE_VFP -mfloat-abi=softfp -mfpu=vfpv3-d16
That will boost the performance as generating the best code for our device. For example, enabling hardware floating point calculation is already a boost for our device because it is not enabled by default.
UnknownzD said:
btw I have another performance boost for your kernel build.
Check here for more info :
https://github.com/UnknownzD/I9103_XW_Kernel/commit/5272617914704968960e16e68e6a62150434c5a9
You need to add the following things to KBUILD_CFLAGS
-O2 -march=armv7-a -mtune=cortex-a9 -mcpu=cortex-a9 -D__ARM_ARCH_7__ -D__ARM_ARCH_7A__ -D__VFP_FP__ -D__ARM_HAVE_VFP -mfloat-abi=softfp -mfpu=vfpv3-d16
That will boost the performance as generating the best code for our device. For example, enabling hardware floating point calculation is already a boost for our device because it is not enabled by default.
Click to expand...
Click to collapse
Thanks! That's great
ardatdat said:
Even if it could be enabled, there is one great feature of "off-machine" alarm in Chinese based ROM only. This feature allows you to set an alarm and then you shutdown your phone (while keeping your cable charging the phone). Just before 2 minutes before the alarm, the phone will be turned on automatically and the alarm will ring!
For example, the time now is 10:00, you set an alarm at 10:10 and you turn off your phone. At around 10:08, the phone will boot up automatically! And the alarm rings precisely at 10:00!
You can try that feature using Chinese based ROM such as ZCKK1, ZCLA1, ZCLD3, ZCLD4, etc... Thanks
Click to expand...
Click to collapse
well I will try to port that off-machine alarm to XW build later Now I need to head off for making my own ROM with specific build.prop and init script that can boost performance as I don't want to see two people working on 2 'different' kernel with same patches (wasted too much resources and those users are hard to follow).
I have actually made a ROM for I9003 before with a OC kernel which has boosted the performance better than the I9000. However I didn't release it on the xda as I have found that the I9003 forum is like a mess. And I am going to make all those patches I have made for I9003 ROM back to I9103 ROM so that further boost the android VM performance.
btw after 4~6 full days of work (I have made all my kernels and findings in these days), I need to head off for playing some games now
btw, watch out the SGS3 live stream boardcast as well!
UnknownzD said:
well I will try to port that off-machine alarm to XW build later Now I need to head off for making my own ROM with specific build.prop and init script that can boost performance as I don't want to see two people working on 2 'different' kernel with same patches (wasted too much resources and those users are hard to follow).
I have actually made a ROM for I9003 before with a OC kernel which has boosted the performance better than the I9000. However I didn't release it on the xda as I have found that the I9003 forum is like a mess. And I am going to make all those patches I have made for I9003 ROM back to I9103 ROM so that further boost the android VM performance.
btw after 4~6 full days of work (I have made all my kernels and findings in these days), I need to head off for playing some games now
btw, watch out the SGS3 live stream boardcast as well!
Click to expand...
Click to collapse
YES! I am waiting for the live broadcast, haha, same as you!
By the way, the kernel source has been organized (by merging some similar commits & re-ordering) and just pushed to github!
You may find it here:
https://github.com/ardatdat/GalaxyR-i9103-Kernel/commits/wxla4-1.3G-voodoo
ardatdat said:
YES! I am waiting for the live broadcast, haha, same as you!
By the way, the kernel source has been organized (by merging some similar commits & re-ordering) and just pushed to github!
You may find it here:
https://github.com/ardatdat/GalaxyR-i9103-Kernel/commits/wxla4-1.3G-voodoo
Click to expand...
Click to collapse
Well Samsung Galaxy S3 has nothing special after all, except for the wireless charger + quad core CPU
All those other technologies they made on the phone are already mentioned or developed for other devices already.
For example, the pre-capture thing and best photo technology were used in camera like Nikon J1.
Edited : Okay, I have chosen to take back what I said above just because the SGS3 gets a wolfson chipset WM1811 (although it is not good as the WM8994 used in our phone), however WM1811 should still shine for better audio output as well as getting the next version of voodoo sound, Kaudio kernel module. Read more about the difference between WM1811 and WM8994, and follow supercurio post there :
http://www.wolfsonmicro.com/products/audio_hubs/ (Comparison chart)
http://www.wolfsonmicro.com/products/audio_hubs/WM1811/
http://www.wolfsonmicro.com/products/audio_hubs/WM8994/
http://twitter.com/#!/supercurio
Kernal looks and works great.
But how do u enable Voodoo ??
It is enabled by default in the kernel already, just plug in a headphone to listen the difference plx. Btw check my kernel thread for the voodoo sound apk if you want to chech whether voodoo is enabled or not.
Sent from my GT-I9103 using XDA
UnknownzD said:
It is enabled by default in the kernel already, just plug in a headphone to listen the difference plx. Btw check my kernel thread for the voodoo sound apk if you want to chech whether voodoo is enabled or not.
Sent from my GT-I9103 using XDA
Click to expand...
Click to collapse
Testing this kernel, awesome sound with earphones!!!!!!
This is the link to the Voodoo sound apk for config some things:
http://forum.xda-developers.com/showpost.php?p=25582701&postcount=45
Thanks.
esteras said:
Testing this kernel, awesome sound with earphones!!!!!!
This is the link to the Voodoo sound apk for config some things:
http://forum.xda-developers.com/showpost.php?p=25582701&postcount=45
Thanks.
Click to expand...
Click to collapse
Thanks for link to the app.
NOW i can HEAR the difference.
Thanks to UnknownzD, artdatdat and u.
I do see that there is a great difference in the amplifier for the headphones. Great work guys, Thanks a ton.
However, the Bass Boost does not seem to be working, I do not hear any difference, am I missing anything here?!!
Cheers!
coolcorner said:
I do see that there is a great difference in the amplifier for the headphones. Great work guys, Thanks a ton.
However, the Bass Boost does not seem to be working, I do not hear any difference, am I missing anything here?!!
Cheers!
Click to expand...
Click to collapse
I will check whether the bass boost works or not with my high-end earbud, so if that occurs I will make some patches and test in my kernel and then make a pull request to ardatdat kernel to fix the problem.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What is this?
Basically by installing this application, as soon as you receive a notification there is a flash as your phone starts blinking for the LED notification.
It can be useful to anyone that has a device without the LED notification, but instead have a flash next to the selfie camera.
It also extends the concept of notification to the unread badges received from the applications (ex. the "Facebook like"). So, when an unread badge pops up, in the same way as a "normal" notification the flash starts blinking and you will be notified of what's going on.
Various settings are also available to better configure the application to suit your needs.
It works on all devices equipped with a front flash, regardless of whether or not they have the hardware LED notification. (read also the Hardware limitations section for more details)
Main features
customizable activation based on the current display status and audio mode
pocket mode and recovery options
Samsung AOD support
single or double blink
optional custom delay for the first blink
use also the rear flash when the device is upside down
additional flashing loop with customizable frequency
three different gestures to dismiss the flashing loop
customizable exclusions for the incoming call, the missing call and the text messages
customizable exclusions for all the installed user applications
flash notifications for the unread badges received from compatible applications and customizable by app exclusions (only on Samsung devices with TouchWiz based ROM)
suspend on low battery
suspend during a customizable time slot
integration with the Android "Do not disturb" settings
custom quick setting tile in the quick settings panel to easily turn on/off the service (only on Android 7.x+ devices)
custom shortcut pressing the application icon to easily turn on/off the service (only on supported launchers and on Android 7.1.1+ devices)
built-in black list to avoid the flash for useless, fake or annoying notifications from some applications
optimized for memory usage
battery-friendly (usually takes up 2% in each 24 hour period)
dark theme
RTL support for Arabic languages
no ADS
no ROOT ACCESS needed to work
and more...
Languages
English
Italian
Arabic (Egyptian) @yshalsager
Arabic (Syrian) @mozzafar alali
Croatian @dugi9991
Czech @novas78
French @Primokorn
German @supergrobi94 / @Oswald Boelcke
Greek kynigosg
Polish @emcom
Portuguese (Brazilian) @Taivotat2 / @justjr
Russian @gaich
Simplified Chinese @ContactFront
Slovak @kubalav
Spanish @JHAM2005
Turkish @Fatih Fırıncı
Ukrainian @Alexiy_ua
Vietnamese @tphg
Privacy
This application is not ad-supported and can not collect and transmit any sort of privacy sensitive information.
This application can not collect, store or publish any user information.
This application can not use any data connection, detect your location or access your contacts. It also can not read any sensitive information stored on your device. This guarantees maximum security for your data and your privacy.
Permissions
This application does not need any special permissions except for the one to bind the Android notification listener service. [android.permission.BIND_NOTIFICATION_LISTENER_SERVICE]
This is the only authorization required to properly interact with your incoming notifications (you will be asked about it explicitly when it is run for the first time).
Devices with Camera Hardware level: LIMITED (partial Camera2 API support)
On some devices the manufacturer implemented only partially the Android Camera2 API; this means limited hardware access to the camera for the developers. In this case the only way to let this application properly take control of the front flash is to use the old Android API and that's why you may also have to authorize the application to use the hardware camera. [android.permission.CAMERA]
With the first run and only if the application detects this limitation, as per the above case you will be asked explicitly to grant full camera access permission (even if the application should only use the front flash, the flash is strictly part of the hardware camera).
You must agree with providing access to your device camera, file system and audio recording for the application to function. This access is limited to user only. None of the data present in your device can be shared with me or any other person.
Keep in mind that if you deny any of these permissions the application will not work!
If you know how Android works and the meaning of application permissions, you can easily verify by yourself all the above statements.
So please, avoid claiming that we are a bunch of criminals here just to steal your data with this application... in doing that, you would be such an IDIOT!
Hardware limitations
Lately several devices (mainly, but not only, running Android 8.x) are equipped with front flash with custom hardware that developers can not have access to. Furthermore, with the introduction of the new firmware based on Android 8.x, Samsung has inexplicably inhibited the use of front flash to developers on a wide range of devices.
Strangely enough, the front camera of your device may not be equipped with a "real" front flash for this application. When it "asks" through the Android API to your front camera some information about its front flash, the answer may be "no front flash available". There is no workaround this!
This is a software/hardware limitation imposed by the manufacturer (don't ask me why) and at the moment unfortunately there's nothing I can do. I understand your amazement, but if you experience this kind of issue at 99% of the time that's the reason why this application may not work and could report the non-availability of a front flash despite your eyes seeing a front flash.
Mainly only the branded (stock) camera application can handle this kind of front flash, using owned and reserved API.
Try it by yourself to install (from the app Store) an alternative camera application. Then shoot a front selfie and check if the front flash can turn on... or use any other application you expect to use the front flash (usually Instagram and Snapchat fail as well) and then let me know the results.
In addition, you can also try to install Device Info HW and then select the "Camera" tab and check all detailed information about the front camera of your device.
Finally, let me remind you that this app can't take control over the brightness, the color and the speed (On-Off phase) of a flash; unfortunately it isn't a LED... no way for the developers to handle these features.
All of them are strictly related to the hardware and its manufacturer and therefore vary from model to model.
Main functioning
As you can imagine, this application must be able to take control of the front flash of your device to work properly. In an Android phone this can only happen in one way: through the front camera as the flash is strictly connected to it.
The developers in fact through dedicated instructions, can turn it on and off at will. But it always has a connection to the camera and not directly to the flash itself.
To handle all the incoming notifications, an Android service will run in background on your device.
These are the main functioning at the root of this application.
Troubleshooting
If you installed any startup manager application (such as Startup Manager, Autorun Manager, AutoStart Manager, Advanced Task Manager, BootManager, etc) or any battery manager/optimizer application (such as Greenify, Doze, Brevent, Hibernator, App Freezer, etc) pay attention to avoid killing the running "Flash notification service" otherwise this application will not work!
I also want to draw your attention to the importance of the Android wakelocks in the lifecycle of this application (if you don't know what wakelocks are, disregard the sentance below).
If your device is running an application that detects and blocks wakelocks (such as Wakelock Detector, WakeBlock, No Wakelock, Wake Lock - PowerManager, etc), keep in mind that the main features of this application will not work as you expect. So add it to the white list if any, or if you are interested in using this application in any way avoid blocking the wakelocks.
In other words, because of unreasonable battery optimizations implemented by some brands but not only, you have to be careful not to put this application in hibernation without realizing it or maybe killing or blocking the background service without noticing it. These are the most common causes of the main problems you may experience!
Please verify the impact over this application by any system tools / Magisk - Xposed modules which you heavily rely on (especially if your device is ROOTED).
So, double check your system settings before reporting any issues, thanks.
Battery consumption
It isn't strictly related to the application itself. What drains the battery is the flash not the background service in charge of managing your incoming notifications, I can't do more in terms of optimization.
Battery consumption mainly depends on how long you will let the flashing loop run before you dismiss it (the shorter it is the better for your battery) and also on how many notifications you receive a day.
Issues & Known bugs
with the introduction of the new firmware based on Android 8.x, Samsung has inexplicably inhibited the use of front flash to developers on a wide range of devices, so this application stop working!!
System requirements
Android 6.x Marshmallow or later
a device with front camera and front flash (read also the Hardware limitations section for more details)
five minutes of your free-time and a little piece of your brain (just in case)
you do not need ROOT ACCESS for this application to work
Installation instructions
Just download the apk and open it as a normal application.
Download
This application is available on the Google Play Store.
In order to keep in touch with the latest updates, I suggest you uninstall any previous version you downloaded here from XDA and then install the official version of the Play Store.
Get FrontFlash Notification
Credits / Thanks to
thanks to @supergrobi94 for the graphic support
thanks to @Alexiy_ua, @ContactFront, @dugi9991, @emcom, @Fatih Fırıncı, @gaich, @JHAM2005, @justjr, @kubalav, kynigosg, @mozzafar alali, @novas78, @Oswald Boelcke, @Primokorn, @supergrobi94, @Taivotat2, @tphg, @yshalsager for the translations
Donation
Your donations are welcomed and appreciated, press the thanks button instead of saying it.
PayPal
FrontFlash Notification
Version Information
Status: Stable
Current Stable Version: 2.5
Stable Release Date: 2019-04-24
Created: 2018-01-13
Last Updated: 2019-04-24
Screenshots
Changelog
2.5 (current release)
migration to native Android Pie 9 (API 28)
updated internal black-list for the auto-excluded applications
minor bug fixes
2.4.9 (stable)
minor bug fixes
2.4.7 (stable)
under the hood fixes and optimizations
2.4.5 (stable)
minor bug fixes
2.4.2 (stable)
fixed the custom shortcut icon issue on Android 7.1.x devices
minor bug fixes
2.4.1 (stable)
migration to native Android Oreo 8.1 (API 27)
added the option to delay the first blink
added a custom shortcut pressing the application icon to easily turn on/off the service only on supported launchers and on Android 7.1.1+ devices
added the Simplified Chinese translation
added the Greek translation
added the Ukrainian translation
updated all translations
updated internal black-list for the auto-excluded applications
lots of under the hood fixes and optimizations
2.3.3 (stable)
Android 8.x users may experience general malfunctions
added the sub-option to keep screen on if the "Turn display on" option when a notification occurs is selected
added the Slovak translation
added the Turkish translation
added the Vietnamese translation
updated the Czech and Russian translations
stability improvement
minor bug fixes
2.3 (stable)
This update will reset all user preferences to default at first run!
fixed the pocket mode issue
fixed the time slot suspension issue
added a custom quick setting tile on the quick settings panel to easily turn on/off the service only on Android 7.x+ devices
major code rewrite for the graphical user interface (flash notifications settings)
updated internal black-list for the auto-excluded applications
minor bug fixes and various adjustments
2.2.7 (stable)
fixed the pocket mode issue on some devices
fixed the time slot suspension issue on Android 8.x devices
fixed the incoming call flash notification issue
fixed the consecutive notifications issue
renewed badge notification service for Samsung devices (some tests may be needed)
minor bug fixes and various adjustments
2.2.5 (stable)
fixed the issue of annoying blinks while the device is in use (user present/screen on) in some particular conditions or by specific applications
fixed the issue of the suddenly stop working blink loop
battery life improved
new max limit for the blink loop duration
new increase values for the blink loop frequency
minor bug fixes and various adjustments
2.2.1 (stable)
fixed the service force close issue on Android 6.0 devices
minor adjustments
2.2 (stable)
minor bug fixes
2.1.6 (stable)
minor bug fixes
translation update for some languages
2.1.4 (stable)
minor bug fixes
2.1 (stable)
main code reengineering
stability and compatibility improvement
removed the flashing loop duration setting, from now is always unlimited
better performance
2.0 (stable)
code optimization
stability improvement
1.9.5 (stable)
code optimization
minor bug fixes
unlimited duration for the flashing loop
1.9.4 (stable)
added the Portuguese (Brazilian) translation
added the Arabic (Egyptian) translation
added the French translation
added the Czech translation
added the Croatian translation
added the Russian translation
added the Arabic (Syrian) translation
new range values for the duration and the frequency of the flashing loop
1.9.2 (stable)
added the option to force the English language
fixed the Samsung Email application issue
stability improvement
added the light sensor management (if present) for the flash type auto-adjustment (single/double)
added the option to use the rear flash when device is turn upside down
added RTL support for Arabic languages
1.9 (stable)
fixed the service force close issue and runtime exception on some Motorola devices
minor bug fixes
added the Spanish translation
1.8.3 (stable)
official Play Store release
minor bug fixes in the notifications detection engine
added compatibility to Android 8.0 Oreo (API 26)
added the Polish translation
1.7 (stable)
extended support to both Camera and Camera2 API to properly detect and manage the front flash also on devices with limited access to the camera (e.g. new Samsung device series)
fixed the issue with Gmail notifications on Android 6.0 devices
fixed the missing installed applications issue in the excluded applications list
fixed the wrong low battery detection issue on some devices
added a "select/unselect all" toggle switch in the excluded applications list
integration with the current Android "Do not disturb" settings as an additional way to disable the service in certain situations
minor fixes and code optimizations
updated internal black list for the auto-excluded applications
some GUI improvements and adjustments
new dark theme
new application icon
some corrections to writing errors
added the German translation
1.6 (stable)
added the option to choose a custom time slot for the service suspension (tap on time slot)
minor fixes
1.5 (stable)
added Samsung AOD detection and support
added the option to choose which applications exclude from the unread badges notification (tap on See list)
added the option to choose a custom sound for the unread badges notification (tap on Set sound)
improved both memory and cpu consumption
1.4 (release)
added the accelerometer sensor management and the relative “by shake” option
fixed the issue with duplicate items between the unread badges notification and the "normal" notification from the same application
new GUI
added the Italian translation
1.3 (beta 2)
added compatibility to Android 7.1.1 Nougat (API 25)
added the option to choose which applications exclude from flash notification (black list)
added the unread badges detection and the relative flash notification for all supported applications (only on Samsung devices with TW rom)
lots of under the hood fixes and optimizations
1.2 (beta 1)
added the proximity sensor option and its management
added the notifications badge count over the application icon in the app drawer and its relative option (only on supported device: Asus, Huawei, LG, HTC, Oppo, Samsung, Sony, Xiaomi, ZTE)
fine tuning in the notifications detection engine to avoid fake flash notifications from system and user applications
performance improvements
1.1 (alpha)
added the option to enable a blinking loop for all the incoming notifications
added the low battery status detection and the relative service suspension option
added an option to suspend the service during a specific time slot
bug fixes
1.0
initial release
Support
Feedback
Please write in this thread any suggestions or bugs you come to know to help me make this application better and better.
What's coming next
none
Translations
All translations are created by community volunteers and open for contribution. If you want this application in your language and you are interested in cooperate, please send me a PM.
Hardware limitations
Lately several devices (mainly, but not only, running Android 8.x) are equipped with front flash with custom hardware that developers can not have access to. Furthermore, with the introduction of the new firmware based on Android 8.x, Samsung has inexplicably inhibited the use of front flash to developers on a wide range of devices.
Strangely enough, the front camera of your device may not be equipped with a "real" front flash for this application. When it "asks" through the Android API to your front camera some information about its front flash, the answer may be "no front flash available". There is no workaround this!
This is a software/hardware limitation imposed by the manufacturer (don't ask me why) and at the moment unfortunately there's nothing I can do. I understand your amazement, but if you experience this kind of issue at 99% of the time that's the reason why this application may not work and could report the non-availability of a front flash despite your eyes seeing a front flash.
Mainly only the branded (stock) camera application can handle this kind of front flash, using owned and reserved API.
Try it by yourself to install (from the app Store) an alternative camera application. Then shoot a front selfie and check if the front flash can turn on... or use any other application you expect to use the front flash (usually Instagram and Snapchat fail as well) and then let me know the results.
In addition, you can also try to install Device Info HW and then select the "Camera" tab and check all detailed information about the front camera of your device.
Finally, let me remind you that this app can't take control over the brightness, the color and the speed (On-Off phase) of a flash; unfortunately it isn't a LED... no way for the developers to handle these features.
All of them are strictly related to the hardware and its manufacturer and therefore vary from model to model.
Main functioning
As you can imagine, this application must be able to take control of the front flash of your device to work properly. In an Android phone this can only happen in one way: through the front camera as the flash is strictly connected to it.
The developers in fact through dedicated instructions, can turn it on and off at will. But it always has a connection to the camera and not directly to the flash itself.
To handle all the incoming notifications, an Android service will run in background on your device.
These are the main functioning at the root of this application.
Common issues & Troubleshooting
If you installed any startup manager application (such as Startup Manager, Autorun Manager, AutoStart Manager, Advanced Task Manager, BootManager, etc) or any battery manager/optimizer application (such as Greenify, Doze, Brevent, Hibernator, App Freezer, etc) pay attention to avoid killing the running "Flash notification service" otherwise this application will not work!
I also want to draw your attention to the importance of the Android wakelocks in the lifecycle of this application (if you don't know what wakelocks are, disregard the sentance below).
If your device is running an application that detects and blocks wakelocks (such as Wakelock Detector, WakeBlock, No Wakelock, Wake Lock - PowerManager, etc), keep in mind that the main features of this application will not work as you expect. So add it to the white list if any, or if you are interested in using this application in any way avoid blocking the wakelocks.
In other words, because of unreasonable battery optimizations implemented by some brands but not only, you have to be careful not to put this application in hibernation without realizing it or maybe killing or blocking the background service without noticing it. These are the most common causes of the main problems you may experience!
Please verify the impact over this application by any system tools / Magisk - Xposed modules which you heavily rely on (especially if your device is ROOTED).
So, double check your system settings before reporting any issues, thanks.
Battery consumption
It isn't strictly related to the application itself. What drains the battery is the flash not the background service in charge of managing your incoming notifications, I can't do more in terms of optimization.
Battery consumption mainly depends on how long you will let the flashing loop run before you dismiss it (the shorter it is the better for your battery) and also on how many notifications you receive a day.
Hope I have been helpful in understanding.
Thank you nice work
I will add Arabic language
Can't enable the front flash.. Its not enabling.. Greyed out.. I have j7 pro.. Ty..
The app doesn't know I have Front Flash (J7 2016)
Sent from my j7xelte using XDA Labs
ickoslash said:
Can't enable the front flash.. Its not enabling.. Greyed out.. I have j7 pro.. Ty..
Click to expand...
Click to collapse
Oh... this sounds strange! Be more specific please.
Which android version?
Which label is displayed at the left of the greyed switch?
Did the app ask for "Notification access permission" at first run?
Open Options --> Lock screen and security --> Other security settings and check manually the notification access permission (if it's disabled, activate it now) and let me know.
Thanks
Arnaud Créative Studios said:
The app doesn't know I have Front Flash (J7 2016)
Sent from my j7xelte using XDA Labs
Click to expand...
Click to collapse
You mean did you received the "Front flash not present, service disabled" message?
Thanks
spacejam said:
You mean did you received the "Front flash not present, service disabled" message?
Thanks
Click to expand...
Click to collapse
Yes
Sent from my j7xelte using XDA Labs
spacejam said:
Oh... this sounds strange! Be more specific please.
Which android version?
Which label is displayed at the left of the greyed switch?
Did the app ask for "Notification access permission" at first run?
Open Options --> Lock screen and security --> Other security settings and check manually the notification access permission (if it's disabled, activate it now) and let me know.
Thanks
Click to expand...
Click to collapse
Got error message front flash not present.. Already enabled it in notifications under lock screen and security.. My phone's j7 pro.. So technically it's nougat..
Arnaud Créative Studios said:
Yes
Click to expand...
Click to collapse
SM-J710F model right?
Chipset Exynos or Snapdragon?
Stock ROM, Custom TWLauncher rom, AOSP rom... or what?
(I'm sorry for so many questions, but the more I know and the more it becomes easy to solve the problem, I hope)
ickoslash said:
Got error message front flash not present...
Click to expand...
Click to collapse
SM-J730G model right?
Seems like something go wrong during the front flash detection phase.
This app uses the standard Android Camera2 API to get access to the flash.
So, is something strictly related to your device model and Samsung hardware/firmware.
Maybe is the Exynos chipset variant... not so easy to investigate but I will try.
Thanks
spacejam said:
SM-J710F model right?
Chipset Exynos or Snapdragon?
Stock ROM, Custom TWLauncher rom, AOSP rom... or what?
(I'm sorry for so many questions, but the more I know and the more it becomes easy to solve the problem, I hope)
SM-J730G model right?
Seems like something go wrong during the front flash detection phase.
This app uses the standard Android Camera2 API to get access to the flash.
So, is something strictly related to your device model and Samsung hardware/firmware.
Maybe is the Exynos chipset variant... not so easy to investigate but I will try.
Thanks
Click to expand...
Click to collapse
Yep.. Exynos chipset.. It would be awesome if you could fix it dude.. Tnx a lot for making this app.. Will wait for the update.. :fingers-crossed:
spacejam said:
SM-J710F model right?
Chipset Exynos or Snapdragon?
Stock ROM, Custom TWLauncher rom, AOSP rom... or what?
(I'm sorry for so many questions, but the more I know and the more it becomes easy to solve the problem, I hope)
SM-J730G model right?
Seems like something go wrong during the front flash detection phase.
This app uses the standard Android Camera2 API to get access to the flash.
So, is something strictly related to your device model and Samsung hardware/firmware.
Maybe is the Exynos chipset variant... not so easy to investigate but I will try.
Thanks
Click to expand...
Click to collapse
SM-J710FN,Exynos,Stock TW Nougat Rom with Stock Launcher
Sent from my j7xelte using XDA Labs
FrontFlash Notification
Issues & known bugs:
on some Exynos chipset based devices, take control over the front flash fails. Check yours by yourself and let me know. (I'm working to understand how to fix it)
Thank you for this app, I will try it.
Works great on my Moto Z2 Play. Even dual flash works too. Awesome work !
This will be very useful on my Honor 7 since the notification LED is so small it's almost invisible.
Haven't been able to get it to work yet though.
First issue I got was that the service was running but not enabled. I figured out it was due to the "suspend on low battery" setting even though my battery was at 80%.
I unticked that and now the service is running and enabled.
I'm trying to get a notification when receiving an e-mail(gmail) but nothing is happening. Gmail is not in the possible exclusion list at all, maybe that has something to do with it?
Edit: It works for other apps like the calendar app.
Thanks for the work so far.
FrontFlash Notification
Just an update for Exynos chipset based device users... the front flash detection issue is not related to the chipset.
For some strange reasons (don't ask me why), on the new devices series (Exynos of course), Samsung has implemented only partially the Camera2 API for the developers. Hardware level: LIMITED (partial Camera2 support)
This is why at the time been my app can't use the front flash on your device.
In the next few days I'm going to produce a new 1.7 version, where if Camera2 fails the app takes control over the camera and his front flash using the old Android API.
Based on the first tests, fortunatelly this seems to fix the problem.
Keep in touch
Fair warning: I know only mostly what I want, I have no clue how difficult it will be to achieve, and therefor have no idea how to price the work. There are several people interested in this project though, so I'm sure a good budget can be reached.
I have several copies of Lenovo+Google's ill-fated virtual reality headset, which I would like to turn into actually functional devices. The kernel is Android 8 with some additional hooks (I have a copy with the additional required files). I also have one that has developer access of some kind, which may make the process easier.
The primary problems the device needs fixed:
Needs USB File transfer (disabled completely currently)
Needs access to cameras (Especially necessary for AR passthrough)
Needs Task Manager
Needs better widget and notification area systems (Currently, to skip a song on, say, spotify, you have to exit the app you're in, navigate to spotify, switch the song, restart the app you were in. The notifications are also not context aware, so you can't click on one to go to the referenced app)
Support for alternate controllers (basic, such as keyboard or bluetooth PSX)
According to the last person I attempted to hire for this, it would be easier to start from scratch than to implement an altered rom, but I don't think he understood how the 360 virtual environment and camera tracking systems were integrated (not that I do, but I know enough to know that building them out from scratch would be a massive undertaking).
Here is the current road map document, which is still a work in progress.
Any assistance, direction, or paid work would be appreciated, as I've been stumped on where to even begin for over a year.
MOD ACTION:
Thread closed since bounty threads are not allowed on XDA.
@bridgebrain