You have to configure the network on youre router to wpa2 if thats youre wifi source
You have to configure the network on youre router to wpa2 if thats youre wifi source
Yea i checked that option but that wasnt the issue, i wiped indeed the dalvik cache becus my phone was acting weird but that was solved with it. i cant remember it auto launches but guess its just meWorks fine, did you check "disable autostart on boot" in debug menu?
Sometimes it can take longer, especially after wiping dalvik-cache.
So you may didn't wait enough.
Also if you launch the app yourself then it'll not launch once again.
It's not a stupid app.
Well i did the fix permissions thing and rebooted, and the app auto launched fine afterwards. So i guess something happend with itYea i checked that option but that wasnt the issue, i wiped indeed the dalvik cache becus my phone was acting weird but that was solved with it. i cant remember it auto launches but guess its just meanyway, i keep a eye out if it rlly happens or it is just my imagination lol
Hmm weird, on start up there runs barely anything so i dont see rlly a reason why lmk is triggered.Yeah, or if it really didn't launch, then the only possible reason could be that the system was heavy overloaded and got killed by LMK, since it's a user process.
Hmm seems to be right then, anyway got also bad news, becus i switch in few weeks to new phone when i extend my phone subscription so guess im then less active to test stuff lolNope, on boot there is high load and high RAM usage, a lot of things starts up. In fact on fresh booted Android, RAM is already completely full and therefore you see even swap usage even if you didn't actually start any user app. That's just the Android design. But some RAM usage apps will show you that there is around 2200 MB free RAM. That's more or less right, because cache (anonymous pages) are seen as free pages to calm paranoid users that don't know how the Linux memory management works. Yes, even if there are a lot of apps in store like "task killer". Anyway, never faced this issue on stock ROM, so I suspect that it's another issue for custom ROMs.
Checked here on stock ROM with all 3 available resolutions from Android settings. Tested with auto orientation on chrome browser app and YouTube app (vanced). Tested all available resolutions on YouTube too, found zero issues.@ace2nutzer I went back to the previous version and the screen rotation is much better than the last version, it's not that fast, but it's not that slow. I generated the logs right after changing the orientation.
Tested, it looks like it's magisk module incompatibility issue with our audio drivers, since it works fine if you choose "internal audio + mic".Alright
Well you need first to install screencam from playstore and afterwards flash the screencam module in magisk (module is uploaded here)" and reboot. After that you need to setup screencam to use internal audio for recordings, so select "internal audio (root + magisk module). After that, just record Something with it ex twitch/youtube etc what has also audio in it and record that for few several secs/mins and stop the recording. Afterwards playback the file and check if theres a desync and if the video duration is incorrect.
Sometimes I'm using my cell phone and out of nowhere it starts to crash too much, like now when I'm writing this. It also happened in Eclipse ROM. I can't say what it could be.Probably not, works only over soft codec and uses too much CPU power, therefore I suggest to not use HDR at all on S8. Even the fact that it works smooth up to 720p with HDR. While on stock kernel it laggs at 720p HDR.
Hmm interesting. Anyway it isnt worth to patch it in my case and i dont have knowledge for it lolChecked here on stock ROM with all 3 available resolutions from Android settings. Tested with auto orientation on chrome browser app and YouTube app (vanced). Tested all available resolutions on YouTube too, found zero issues.
You may need to use VP9 codec from vanced settings, it's much better, but HDR will not work.
Tested, it looks like it's magisk module incompatibility issue with our audio drivers, since it works fine if you choose "internal audio + mic".
To fix, it's needed to patch the module or to add some workarounds in kernel. But honestly I don't care much about this screencam app.
It's in hand!You should generate logcat right after the crash. Check post #3 how to report bugs.
I see. That is a really tough situation. I really hope that you can somehow find a way to increase your income very soon mate. You do not deserve a struggle like that. Probably the new app can turn out to be a solid source of income. Root users in general are much more frequent than S8 root users. A vastly bigger userbase, so. As always with developments from you, I'll buy it and use it on my other devices, so in my little lane I do help.Yeah thanks. It's a problem with time and money. I've calculated how much money the app should cost for just covering the costs I need for a month.
That must be 100 € for every app as an minimum to just survive the month like a poor guy. So I even don't think to try it at all, because likely nobody is willing here to pay 100 € for a better kernel and manager app. This is calculated according to the data provided by Google Play. The problem is that not enough S8 users did actually a purchase. So that's about the amount of sells. If much more users would by the app then it's of course possible to provide the app for just 1 € reaching the same result.
But the new app will cost 1 € and you will be able to use it on every rooted Android device.
Also I would like to fix random reboots for my Philips 3D smart TV.
Yeah that company literally stopped firmware updates without to fix random reboots. It's not possible to watch a film without to face a reboot.
I'm not sure if it's powered by the Linux kernel, if so maybe I can help.
I think a lot of people who have this TV would be happy.
If reboot is required the app would tell you. So not needed.
Yeah thanks. It's a problem with time and money. I've calculated how much money the app should cost for just covering the costs I need for a month.
That must be 100 € for every app as an minimum to just survive the month like a poor guy. So I even don't think to try it at all, because likely nobody is willing here to pay 100 € for a better kernel and manager app. This is calculated according to the data provided by Google Play. The problem is that not enough S8 users did actually a purchase. So that's about the amount of sells. If much more users would by the app then it's of course possible to provide the app for just 1 € reaching the same result.
But the new app will cost 1 € and you will be able to use it on every rooted Android device.
I see. That is a really tough situation. I really hope that you can somehow find a way to increase your income very soon mate. You do not deserve a struggle like that. Probably the new app can turn out to be a solid source of income. Root users in general are much more frequent than S8 root users. A vastly bigger userbase, so. As always with developments from you, I'll buy it and use it on my other devices, so in my little lane I do help.
Old or not, he made this S8 feel always new. Unironically S10 level of snappiness. A 5 years old device, yet its design still feels so modern. And with Ace's Kernel, it performs like a modern flagship without the 120hz screen. He did WONDERS for this device.TechNoob well said.
i've bought your app since my first day using this kernel to support all of your hard work and definitely would do it again if i can.
I understand your concerns and knows exactly that sooner or later our device will be just another thing in the past, i've been there many times.
I can only wish you luck on your projects, and may they'll be your stable source of income, but whatever you're doing i hope it's in line with your passions.
ouh iknow this product that cheap i was tought that have 2x usb 3.0 hahaha okey bro thx for the pict
hmmm if you bored maybe you can make youtube channel maybe can make more income for youSo I'm not saying that I'll newer build a custom kernel again. I did that for years because I did really liked it, but now somehow it became a bit annoying and boring to me. Because if I start to build kernel for e.g. S21 then it's more or less the same. All the features and improvements can be applied with small changes to almost every modern Android phone, especially from Samsung.
It was 100% not due GPU instability but due to lower power from battery. There were 0 graphical glitches. No blackscreens. Nothing. Just stuttering, temp was low and GPU usage kept going from 0 to 40 then 99 then back to 0. It's definitely a battery problem. I will go at it like I did in the past, and keep the charging cable in.Hmm strange. Later i'll check the GPU governor, maybe it can't handle those higher steps. On the other hand it's known that a GPU that is actually not running fully stable due to too high freq or too low power will cause such bad performance. You may can face even some graphical glitches.
Yeah because I've increased voltage for the highest CPU steps, same for the big core. What you say is right about cold battery --> less power.
But you can bypass this with charger cable, just use any powerful charger like the original one and enable battery idle. This will give to the phone 3 Ampere constant. You even don't need to set charging current @ max possible because the driver do this automatically now on latest release.
Another weird thing is that I didn't manage to run 2,8 GHz stable. Original voltage for me was 1,2 V and even with 1,4 or 1,5 V it didn't run stable. Now you will be probably surprised once again, what we actually did was to unlock voltage regulator and ability to increase max allowed voltage for each regulator.
E.g. original GPU max allowed voltage was 850 mV and I've set it @ 1000 mV and after several test it seems that the voltage above 850 mV is accepted since I can track higher GPU temp.
So this works. Then later just because 2,8 GHz never worked stable even with insane OV (overvolting) DVFS 95 °C instead of 100 °C to be sure that it doesn't crash due to overheating... I was reading some documentation in source code about the regulators and found out that there is even the ability to throttle the max current (uA) from the regulator. But I didn't pay much attention because it doesn't seem to be used in our source code. But it's supported, that means if I specify a max allowed current then maybe that will be used lets say instead to used a max default current hardcoded in the hardware itself. Maybe I try this hack next time. If that will not work, then it's just hardware limitation that it can't provide enough power. If so, you should be able to reach higher Freqs when OC only CPU or GPU !
su // only for termux app
cd /sys/module/abox/parameters
cat user_pm_qos_lit // check current value
echo 949000 > user_pm_qos_lit // e.g. set to 949 MHz
# To apply the change at boot, like always, copy paste the cmds to
# /system/etc/init.d/99_user without the "su" cmd of course.
Ace it's best you don't do Custom ROMs or higher android versions support. IMO higher Android versions custom ROMs are very pointless if updated over the "sweet spot" point for the hardware. The more you update the OS, the slower it becomes, it's inevitable. Android versions become heavier and meant for more powerful hardware.Ok but don't expect that i'll fix that.
This phone is now old. Support and development is now lowered.
Also there will be no custom ROM from my side. Also I'll not add support for higher Android versions. But i'll try to keep this kernel alive by fixing critical bugs or critical security leaks. I'm working on a new Android app.
Also this is likely the last custom kernel / app project from me. If someone want to know why, just ask.
su // only for termux app
cd /sys/module/abox/parameters
cat user_pm_qos_lit // check current value
echo 949000 > user_pm_qos_lit // e.g. set to 949 MHz
# To apply the change at boot, like always, copy paste the cmds to
# /system/etc/init.d/99_user without the "su" cmd of course.
adb shell
su
cd /sys/power
# print dvfs table so we can see current votlage table !
echo 1 > print_dvfs_table
dmesg
[ 5808.312763] dvfs_type : dvfs_mif - id : 0
[ 5808.312784] num_of_lv : 12
[ 5808.312791] num_of_members : 4
[ 5808.312802] lv : [2093000], volt = 850000 uV
[ 5808.312814] lv : [2002000], volt = 850000 uV
[ 5808.312825] lv : [1794000], volt = 762500 uV
[ 5808.312835] lv : [1540000], volt = 712500 uV
[ 5808.312846] lv : [1352000], volt = 675000 uV
[ 5808.312856] lv : [1014000], volt = 637500 uV
[ 5808.312867] lv : [ 845000], volt = 606250 uV
[ 5808.312877] lv : [ 676000], volt = 593750 uV
[ 5808.312887] lv : [ 546000], volt = 587500 uV
[ 5808.312896] lv : [ 421000], volt = 581250 uV
[ 5808.312907] lv : [ 286000], volt = 581250 uV
[ 5808.312917] lv : [ 208000], volt = 581250 uV
[ 5808.312938] dvfs_type : dvfs_int - id : 1
[ 5808.312945] num_of_lv : 7
[ 5808.312951] num_of_members : 16
[ 5808.312962] lv : [ 667000], volt = 781250 uV
[ 5808.312972] lv : [ 533000], volt = 756250 uV
[ 5808.312982] lv : [ 400000], volt = 643750 uV
[ 5808.312991] lv : [ 333000], volt = 612500 uV
[ 5808.313001] lv : [ 267000], volt = 587500 uV
[ 5808.313011] lv : [ 178000], volt = 575000 uV
[ 5808.313020] lv : [ 107000], volt = 575000 uV
[ 5808.313040] dvfs_type : dvfs_cpucl0 - id : 2
[ 5808.313047] num_of_lv : 18
[ 5808.313053] num_of_members : 1
[ 5808.313062] lv : [2808000], volt = 1300000 uV
[ 5808.313071] lv : [2704000], volt = 1175000 uV
[ 5808.313082] lv : [2652000], volt = 1150000 uV
[ 5808.313092] lv : [2574000], volt = 1081250 uV
[ 5808.313102] lv : [2496000], volt = 1037500 uV
[ 5808.313113] lv : [2314000], volt = 962500 uV
[ 5808.313123] lv : [2158000], volt = 906250 uV
[ 5808.313133] lv : [2002000], volt = 868750 uV
[ 5808.313144] lv : [1937000], volt = 850000 uV
[ 5808.313154] lv : [1807000], volt = 812500 uV
[ 5808.313164] lv : [1703000], volt = 781250 uV
[ 5808.313175] lv : [1469000], volt = 737500 uV
[ 5808.313185] lv : [1261000], volt = 706250 uV
[ 5808.313196] lv : [1170000], volt = 687500 uV
[ 5808.313206] lv : [1066000], volt = 668750 uV
[ 5808.313216] lv : [ 962000], volt = 656250 uV
[ 5808.313227] lv : [ 858000], volt = 643750 uV
[ 5808.313237] lv : [ 741000], volt = 625000 uV
[ 5808.313256] dvfs_type : dvfs_cpucl1 - id : 3
[ 5808.313262] num_of_lv : 12
[ 5808.313268] num_of_members : 1
[ 5808.313279] lv : [2002000], volt = 1300000 uV
[ 5808.313289] lv : [1898000], volt = 1200000 uV
[ 5808.313300] lv : [1794000], volt = 1137500 uV
[ 5808.313310] lv : [1690000], volt = 1062500 uV
[ 5808.313321] lv : [1456000], volt = 937500 uV
[ 5808.313331] lv : [1248000], volt = 831250 uV
[ 5808.313342] lv : [1053000], volt = 775000 uV
[ 5808.313352] lv : [ 949000], volt = 743750 uV
[ 5808.313363] lv : [ 832000], volt = 712500 uV
[ 5808.313373] lv : [ 715000], volt = 675000 uV
[ 5808.313384] lv : [ 598000], volt = 643750 uV
[ 5808.313394] lv : [ 455000], volt = 618750 uV
[ 5808.313413] dvfs_type : dvfs_g3d - id : 4
[ 5808.313419] num_of_lv : 9
[ 5808.313426] num_of_members : 1
[ 5808.313436] lv : [ 839000], volt = 750000 uV
[ 5808.313447] lv : [ 764000], volt = 750000 uV
[ 5808.313457] lv : [ 683000], volt = 700000 uV
[ 5808.313467] lv : [ 572000], volt = 718750 uV
[ 5808.313478] lv : [ 546000], volt = 706250 uV
[ 5808.313488] lv : [ 455000], volt = 693750 uV
[ 5808.313499] lv : [ 385000], volt = 693750 uV
[ 5808.313509] lv : [ 338000], volt = 693750 uV
[ 5808.313520] lv : [ 260000], volt = 693750 uV
[ 5808.313539] dvfs_type : dvfs_intcam - id : 5
[ 5808.313545] num_of_lv : 4
[ 5808.313551] num_of_members : 4
[ 5808.313561] lv : [ 690000], volt = 812500 uV
[ 5808.313572] lv : [ 680000], volt = 687500 uV
[ 5808.313583] lv : [ 670000], volt = 637500 uV
[ 5808.313593] lv : [ 640000], volt = 575000 uV
[ 5808.313610] dvfs_type : dvfs_cam - id : 6
[ 5808.313616] num_of_lv : 7
[ 5808.313623] num_of_members : 22
[ 5808.313633] lv : [ 690000], volt = 793750 uV
[ 5808.313644] lv : [ 680000], volt = 793750 uV
[ 5808.313654] lv : [ 670000], volt = 756250 uV
[ 5808.313665] lv : [ 660000], volt = 693750 uV
[ 5808.313675] lv : [ 650000], volt = 693750 uV
[ 5808.313685] lv : [ 640000], volt = 575000 uV
[ 5808.313696] lv : [ 630000], volt = 575000 uV
[ 5808.313713] dvfs_type : dvfs_disp - id : 7
[ 5808.313719] num_of_lv : 5
[ 5808.313725] num_of_members : 2
[ 5808.313735] lv : [ 630000], volt = 750000 uV
[ 5808.313746] lv : [ 533000], volt = 712500 uV
[ 5808.313756] lv : [ 356000], volt = 631250 uV
[ 5808.313767] lv : [ 214000], volt = 587500 uV
[ 5808.313777] lv : [ 134000], volt = 575000 uV
[ 5808.313794] dvfs_type : dvs_g3dm - id : 8
[ 5808.313800] num_of_lv : 9
[ 5808.313807] num_of_members : 1
[ 5808.313817] lv : [ 839000], volt = 0 uV
[ 5808.313827] lv : [ 764000], volt = 0 uV
[ 5808.313837] lv : [ 683000], volt = 0 uV
[ 5808.313847] lv : [ 572000], volt = 718750 uV
[ 5808.313858] lv : [ 546000], volt = 712500 uV
[ 5808.313869] lv : [ 455000], volt = 700000 uV
[ 5808.313880] lv : [ 385000], volt = 700000 uV
[ 5808.313890] lv : [ 338000], volt = 700000 uV
[ 5808.313900] lv : [ 260000], volt = 700000 uV
[ 5808.313917] dvfs_type : dvs_cp - id : 9
[ 5808.313924] num_of_lv : 3
[ 5808.313930] num_of_members : 1
[ 5808.313940] lv : [1500000], volt = 850000 uV
[ 5808.313951] lv : [1066000], volt = 731250 uV
[ 5808.313961] lv : [ 800000], volt = 731250 uV
# lets say you want to undervolt big CPU Freq step 2314 MHz @ 900 mV:
# the format string is here: "rate volt" (KHz uV)
echo "2314000 900000" > cpu_big_volt
# after that you could again print the dvfs table to verify if new voltage was successfully applied.
echo 1 > print_dvfs_table
dmesg
# now lets say you want to undervolt little CPU Freq step 1690 MHz @ 950 mV:
# the format string is here: "rate volt" (KHz uV)
echo "1690000 950000" > cpu_lit_volt
# now likely you want to undervolt GPU Freq step 546 MHz @ 650 mV:
# the format string is here: "rate volt" (KHz uV)
cd /sys/kernel/gpu
# first check current GPU volt table:
cat gpu_asv_table
GPU, vol, min, max, down_stay, mif, cpu0, cpu1
839000, 750000, 43, 75, 1, 2093000, 0, 0
764000, 750000, 42, 75, 1, 2093000, 0, 0
683000, 700000, 38, 75, 1, 2093000, 0, 0
572000, 718750, 47, 75, 1, 2093000, 0, 0
546000, 706250, 37, 75, 1, 2093000, 0, 0
455000, 693750, 38, 75, 1, 2093000, 0, 0
385000, 693750, 41, 75, 1, 2093000, 0, 0
338000, 693750, 33, 75, 1, 2093000, 0, 0
260000, 693750, 33, 75, 1, 1352000, 0, 0
echo "546000 650000" > gpu_volt
# and check ...
cat gpu_asv_table
GPU, vol, min, max, down_stay, mif, cpu0, cpu1
839000, 750000, 43, 75, 1, 2093000, 0, 0
764000, 750000, 42, 75, 1, 2093000, 0, 0
683000, 700000, 38, 75, 1, 2093000, 0, 0
572000, 718750, 47, 75, 1, 2093000, 0, 0
546000, 650000, 37, 75, 1, 2093000, 0, 0
455000, 693750, 38, 75, 1, 2093000, 0, 0
385000, 693750, 41, 75, 1, 2093000, 0, 0
338000, 693750, 33, 75, 1, 2093000, 0, 0
260000, 693750, 33, 75, 1, 1352000, 0, 0
# you can undervolt every single step, so lets undervolt 455 MHz step as well @ 650 mV:
echo "455000 650000" > gpu_volt
# now maybe you want even to undervolt RAM.
# we need to go again to /sys/power ...
cd /sys/power
# take a look at the dvfs table, the very first entry "dvfs_mif - id : 0"
this is RAM freq - volt table and our max_freq is 1794 MHz.
# we will undervolt Freq step 1794 MHz @ 700 mV:
# the format string is here: "id rate volt" (intent KHz uV)
# this sysfs interface is universal and you can undervolt any voltage table you want by using the corresponding "id":
echo "0 1794000 700000" > update_dvfs_table
# and verify:
echo 1 > print_dvfs_table
dmesg
# id 4 would be for GPU (dvfs_g3d) and so on ...
# to run all the cmds for undervolting at boot, just do something like this:
# open the script /system/etc/init.d.a2n/a2n_user and copy paste your cmds:
cd /sys/power
echo "2314000 900000" > cpu_big_volt
echo "1690000 950000" > cpu_lit_volt
echo "0 1794000 700000" > update_dvfs_table
cd /sys/kernel/gpu
echo "546000 650000" > gpu_volt
echo "455000 650000" > gpu_volt
# under the line: "# A2N init.d Script"
# save and enjoy !