Database Users

busybox, shell scripts, and device sleep

Is it okay to ask development questions here? I asked one a little while ago, and it got moved over to the General section, which doesn't make sense to me. Anyway, I'm sure the mod will move this one too if it's inappropriate to ask development questions in the development forum (puzzling, if true).
Regardless, on to the question:
I've been developing hardware and software for 25 years, much of it on UNIX and Windows. Know .NET, and other frameworks (X, in terms of UNIX) well. I'm brand-new to Android, though, and haven't taken the plunge yet to get a dev environment set up, and start learning the app frameworks. So, I'm working on some things via creating some rather sophisticated shell scripts.
I've run into two seeming bugs: Looping scripts, using sleep to go dormant, then wake up and do something, don't transition through a device suspend/wakeup cycle.
Intermittently, the OS will come back up with the sleep command stuck, pinning the CPU. This sometimes happens with the hosting shell, ash, as well.
In reality, both these processes are just invocations of busybox. So it's really busybox that's having the problem.
If I can work around this, I will have a very nice, clean, near zero-load ALSA solution for the pathetic default sound chip settings, adding substantial boost (configurable), balance control, and (future) control over output device (earphones, speaker, BT, earpiece)... and much more going forward.
I plan to reimplement all this with native code in a nice GUI app, but for now I'm doing proof of concept with shell scripting, and have hacked up a pretty cool real-time interactive configuration interface using curses-like ANSI terminal controls in ConnectBot (should work with any terminal app on the Epic as long as it supports ANSI standard cursor controls).
So, anyone have any insight/advice/help on this issue with busybox in it's "sleep" and "ash" command personas? One idea I had was to create a cron job to run every 5 minutes or so to check via top and see if either of these processes is running and chewing up the CPU, and if so, kill them off. I notice, though, that crond isn't running, so I'm concerned about what effect it will have if I start it up... Will it wake the phone up every minute to do it's job, thereby killing the battery? (that's how cron works, see the manpage).
Another solution would be to just put the native sleep and shell binaries on my phone, and call them. Sleep will be tiny, so no big deal there. But what about sh/ash/ksh/bash? In theory, should be comparable to busybox (in fact, I'd supect smaller), and as a side-benefit, could get the full scripting functionality of one of these shells (busybox has a few limitations).
Best of all, if there was a "I'm going to suspend" signal I could just trap in the script then I could deal with this in the most logical, direct way. Nirvana would be that signal, and a corresponding trappable "I just woke up" signal.
I'd really appreciate knowlegable dev's comments on these ideas, and any other suggestions/advice for how to deal with this.

Please post questions in General section.

We really need a trollface smiley.

[Mod][MotoActv] Tweaks+Mods Pack!

ive gathered some things and did a few tests on my MotoActv since ive gotten it and did some tweaks here and there and i added the following features to mine and put them into a flashable zip for u all
-init.d support (plus some scripts to make it faster then ever) (tested and working (makes two files in sdcard on boot to show it) (picks and chooses when to work now for some reason, so i put an app i made that loads scripts when onCreate()'d and sometimes on-boot)
-Viper4Android sound system (only works for bluetooth headsets if enabled, but its sounds better with good settings)(see credits)
-OpenVPN (idk if theres a use for us but i added the required files (no GUI)
-UsbEnabler.apk (see credits)
-Adblock host (hopefully it works i havent been able to test yet)
-lag-free entropy (so far seems to work, as im not lagging switching launchers anymore)
-MotoActv DPI (my own personall app i made for Changing dpi from 90,100, and stock(120)
-Sqlite3 + init.d sqlite3 optimizer
-Busybox Run-parts (for init.d, still picks and chooses when to work)
-100 Dpi When-Flashed (can be changed back to stock with the MotoActv DPI app i made)
-minor-to-major tweaks from init.d scripts and other methods
-DalvikCache2Sd (not sure if it truly tested working, but i do have a tiny bit more space+no lag like other 2SD methods
soon to be added:
I take bare minimum credit for these, i mostly used this personal zip for when i update my MotoActv's rom, this can be universal for other androids, but it was initially made to the MotoActv watch running custom roms
Credits to give:
(will edit when i get forum post urls and OP's names)
Viper4Android:
OP = @zhuhang
Thread = http://forum.xda-developers.com/showthread.php?t=2191223
UsbEnabler:
OP = @fagalto
Thread = http://forum.xda-developers.com/showthread.php?t=2396138
init.d scripts, OpenVpn, Entropy:
i extracted from the rom on my phone so idk where they originally came from
Init.d App(unreleased w/o mod_pack)+MotoActv DPI:
OP:me @jkok for developing and publishing
Thread (MotoActv DPI):
http://forum.xda-developers.com/showthread.php?t=2435370
Gallery+Live Wallapapers:
Google, But @ClearD for giving me the zip with the script+apks
the zip:
i put together, made the script, signed+released for general use for others:
future credits will be made when i add more things.
Download:
Reusable Download Link

Awesome!
Here's a zip (with changed mounting, again; this time using the exact same one that I use for the rom) of the Live Wallpapers + Gallery apks. Hopefully, this one will work fine.

ClearD said:
Awesome!
Here's a zip (with changed mounting, again; this time using the exact same one that I use for the rom) of the Live Wallpapers + Gallery apks. Hopefully, this one will work fine.
Click to expand...
Click to collapse
well thanks ClearD i can do the script just fine, some of the mountpoints are universal like what i use
umount("/system");
or
run_program("xbin/mount", "/system"); (might be wrong on the xbin part, just going by memory
run_program("xbin/umount", "/system");
but the resolution on the galery on your motoactv rom is too big for it, it resizes dont get me wrong, but it needs to do a single horizontal row cause if u overscroll to the farest right u see there is second or more rows going down, imma fine the sourcecode for the galery2.apk, and make a single-row version when i find it =)

jkok said:
well thanks ClearD i can do the script just fine, some of the mountpoints are universal like what i use
umount("/system");
or
run_program("xbin/mount", "/system"); (might be wrong on the xbin part, just going by memory
run_program("xbin/umount", "/system");
but the resolution on the galery on your motoactv rom is too big for it, it resizes dont get me wrong, but it needs to do a single horizontal row cause if u overscroll to the farest right u see there is second or more rows going down, imma fine the sourcecode for the galery2.apk, and make a single-row version when i find it =)
Click to expand...
Click to collapse
Ah, sweet! That sounds good. I couldn't get it to mount properly any other way so far, but it could have been something as simple as a typo. If it does actually work, then I might use that in the future. That's the one I tried with the last iteration.

ClearD said:
Ah, sweet! That sounds good. I couldn't get it to mount properly any other way so far, but it could have been something as simple as a typo. If it does actually work, then I might use that in the future.
Click to expand...
Click to collapse
the universal way i do my scripts is
mount("ext3", "MTD", "system", "/system");
unmount("/system");
and it always seemed to work for me, so thats why i call it universal anyways
but the other ways i posted seemed to work for me when i tried em, i just used this way cause it was in a zip for a motoactv rom (i think it was yours or the battery mod)

Opps! i was wrong, its not
run_program("xbin/mount", "system");
its
run_program("sbin/mount", "system");
lol i had to check my other mod zips lol

jkok said:
the universal way i do my scripts is
mount("ext3", "MTD", "system", "/system");
unmount("/system");
and it always seemed to work for me, so thats why i call it universal anyways
but the other ways i posted seemed to work for me when i tried em, i just used this way cause it was in a zip for a motoactv rom (i think it was yours or the battery mod)
Click to expand...
Click to collapse
Lol no doubt, I went through the same thing with the battery mod, looking over and over for one that worked better. I'd prefer the xbin/mount method, but for some reason, it was hit and miss on my end with end users. Not sure why, unless busybox wasn't set up right somehow.

Just updated the mod_pack with more features!
Sorry but the only thing i havent really been able to fix that well way the init.d it seemed to workwhen i first released this mod_pack, but it seems to pick+choose when to work, so i added 2 other methods for init.d (one of which is an app i made, yet to release that loads the scripts when the app is onCreate()'d and sometimes on-boot when SuperUser allows it)
but there are some great new features that WILL work, along with some of my own personall apps, tweaks, and clock faces =)
Again: this mod_pack is meant for MotoActv's running a custom rom, and Not meant for AOSP based MotoActv Roms
Tested and confirmed working (except init.d that picks and chooses) on @ClearD 's ClearRom 1.2.0 T2 (and my own personal (un)Official 1.2.1 T1 i made for him)

For some reason all of the mods are being denied superuser, any ideas? I am setup to automatically allow all requests
Edit: Installed SuperSU and my problem has been resolved

Has there been anything definitive about the entropy thing? The last consensus I saw by anyone not potentially making money from a fix is that at best it's just forcing the processor to stay awake, decreasing battery life.

Saeviomage said:
Has there been anything definitive about the entropy thing? The last consensus I saw by anyone not potentially making money from a fix is that at best it's just forcing the processor to stay awake, decreasing battery life.
Click to expand...
Click to collapse
well by my testing before my motoactv went kaput it didnt affect the battery any noticeable amount, but it did solve some-to-all of the lag from switching launchers on the ClearDroid 1.2.0_T2 rom, i cannot make or update this mod-pack anymore because i dont like submitting a mod-pack that is untested, and since my motoactv went kaput i cannot test it anymore but if u have any questions feel free to ask and ill try to answer the best i can for now =)

not sure what is the right place to ask this... How does DPI change work? Does it mean the "system" screen resolution is changed? Let say, what is the "Full Screen" resolutions in 90/100/stock(120?) dpi's??? Where to read about it if it is not so simple???

yuiop0 said:
not sure what is the right place to ask this... How does DPI change work? Does it mean the "system" screen resolution is changed? Let say, what is the "Full Screen" resolutions in 90/100/stock(120?) dpi's??? Where to read about it if it is not so simple???
Click to expand...
Click to collapse
Dont worry its ok to ask here, since i made this app after all , i might as well answer how this works =)
well to make it shorter and more understandable to alot more people:
Yes, it is the overall resolution of the screen:
DPI (dots-per-inch) is more like the size range to view images/displays/graphics on ANY of your LCD/LED Screened devices including androids, I-craps(iPhones/ipods )(sorry i dont like apple too much, bad excperiences, dont get offended if u like it as its just my personal preferences), blackberries, windows phones, TV's, computer Monitors, etc:
the stock setting for HDPI phones (the more common screened ones now) is 240, say if u lower it, the images get smaller, if u raise it it gets bigger (maybe even too big for the screen to handle correctly);
but since the MOTOACTV has a smaller screen as u can obviously see (if u have one that is, as i dont know others posesions =P), its default for the stock rom is 120 (1/2 of HDPI if u notice the math) and 120 is as big as it should go cause say for example 130 dpi, it makes the images slightly too big for the screen, but slightly smaller values (100 is usually smallest for alot of peoples eyes for the watch, but for some people like me that like them a tad smaller for sharp small details, i put 90), but literally the smaller the amounts go, the smaller the images(and possible errors, i.e ES File Explorer crashes below 120 DPI untill u restore to 120+) , and for the smaller screen we have u cant go too big (121+), or too small (>=90-100), so i put those details of 90,100,and 120 (no 110 as it doesnt make too much of a difference by what i saw)
but there is (a) way(s) to check what DPI u are at currently:
METHOD1.check your build.prop file under /system/build.prop by doin these ADB commands (**new line is a new command**) (commands stop at <EOC>)
adb remount
adb pull /system/build.prop
<EOC>
check somewhere using notepad for this line (NOTE: if u want to edit to push to your device use notepad++, search for it on google if u dont already have it, as regular notepad corrupts it)
ro.sf.lcd_density=(your current DPI is displayed here)
if u decide to change it that way and want to apply it MAKE A BACKUP!!!, then change it in notepad++ and save it, then goto the directory it is in in the terminal/command prompt and do (**new line is a new command**) (commands stop at <EOC>)
adb remount
adb push build.prop /system/build.prop
adb shell chmod 644 /system/app/build.prop
adb reboot
<EOC>
METHOD 2: Any DPI Checking/changer app (there might be some good free ones, i.e. pimpmyrom has a density changer (DPI changer) that works the same as mine i think, it changes the DPI value in the Build.prop and it WILL stick over reboots, just not rom flashes (as it overwrites it and my change)
if u want to see how i did this(if u understand java/android applications) u can check This app on my github, its acually fairly easy and lightweight compared to others
https://github.com/kittleapps/MotoActvDPI
and the exact class that does this (using a library), is this
https://github.com/kittleapps/MotoA...om/KittleApps/app/motoactvdpi/MainScreen.java
as u can see it changes it to 90,100, and 120 quite simply (with root access of course)
and sorry for this long message but it explains not only your question, but possible future questions on how this app works =)

jkok said:
but there is (a) way(s) to check what DPI u are at currently:
METHOD1.check your build.prop file under /system/build.prop by doin these ADB commands (**new line is a new command**) (commands stop at <EOC>)
adb remount
adb pull /system/build.prop
<EOC>
check somewhere using notepad for this line (NOTE: if u want to edit to push to your device use notepad++, search for it on google if u dont already have it, as regular notepad corrupts it)
ro.sf.lcd_density=(your current DPI is displayed here)
if u decide to change it that way and want to apply it MAKE A BACKUP!!!, then change it in notepad++ and save it, then goto the directory it is in in the terminal/command prompt and do (**new line is a new command**) (commands stop at <EOC>)
adb remount
adb push build.prop /system/build.prop
adb shell chmod 644 /system/app/build.prop
adb reboot
<EOC>
METHOD 2: Any DPI Checking/changer app (there might be some good free ones, i.e. pimpmyrom has a density changer (DPI changer) that works the same as mine i think, it changes the DPI value in the Build.prop and it WILL stick over reboots, just not rom flashes (as it overwrites it and my change)
if u want to see how i did this(if u understand java/android applications) u can check This app on my github, its acually fairly easy and lightweight compared to others
https://github.com/kittleapps/MotoActvDPI
and the exact class that does this (using a library), is this
https://github.com/kittleapps/MotoA...om/KittleApps/app/motoactvdpi/MainScreen.java
as u can see it changes it to 90,100, and 120 quite simply (with root access of course)
and sorry for this long message but it explains not only your question, but possible future questions on how this app works =)
Click to expand...
Click to collapse
There is a 3rd method as well.
Method 3 = Install the Xposed framework and app settings apk found here: http://forum.xda-developers.com/showpost.php?p=44034334&postcount=2315
This will allow per app DPI settings rather than one global setting.
In order for this to work correctly, make sure you move both the Xposed Installer and App Settings apks to the phone after installation and reboot as well.
I like running some apps at 120, others at 100, 90, and even 70 w/ modded font sizes and this allows for all those combinations.

Artimis said:
There is a 3rd method as well.
Method 3 = Install the Xposed framework and app settings apk found here: http://forum.xda-developers.com/showpost.php?p=44034334&postcount=2315
This will allow per app DPI settings rather than one global setting.
In order for this to work correctly, make sure you move both the Xposed Installer and App Settings apks to the phone after installation and reboot as well.
I like running some apps at 120, others at 100, 90, and even 70 w/ modded font sizes and this allows for all those combinations.
Click to expand...
Click to collapse
that is true, but i didnt include that cause i was seeing people having issues with xposed-framework on the MOTOACTV on a few threads, and tbh i made this app+inlcuded in modpack before that method was usable for MOTOACTV (or gingerbread in general), thats kinda why i havent updated the modpack in a while (including the fact mine is damaged for some time now), i managed to fix mine up somewhat but it only turns on the backlight and no button combos work but to turn on backlight XD, so no fastboot recovery, boot-to-system, or quickboot :S and since the device is discontinued i cant get a real fix XD, so unless i personally test the things i put in this modpack, i cant make new versions to distribute for device stability reasons (e.g. in case it is corrupted and breaks someone elses device, as it is un-tested, since i dont have a device to test it on)

jkok said:
that is true, but i didnt include that cause i was seeing people having issues with xposed-framework on the MOTOACTV on a few threads, and tbh i made this app+inlcuded in modpack before that method was usable for MOTOACTV (or gingerbread in general), thats kinda why i havent updated the modpack in a while (including the fact mine is damaged for some time now), i managed to fix mine up somewhat but it only turns on the backlight and no button combos work but to turn on backlight XD, so no fastboot recovery, boot-to-system, or quickboot :S and since the device is discontinued i cant get a real fix XD, so unless i personally test the things i put in this modpack, i cant make new versions to distribute for device stability reasons (e.g. in case it is corrupted and breaks someone elses device, as it is un-tested, since i dont have a device to test it on)
Click to expand...
Click to collapse
Sorry to hear that. I personally haven't loaded the mod pack yet. Was looking into cherry picking parts of it when I saw the question on DPI. I thought it was a general question.
In any case, I personally have not had any issues with Xposed on my actv. What issues have you heard about?

jkok - thank you so much for the explanations. It's become more clear for me but I'm not so experienced in android/development so I have some more questions related to dpi on actv.
My practical interest in this is - to investigate the possibility to run igo primo on this device (for route planning/voice navigation) because I'm not happy with Motorola map application (walk/run outdoor mode). I have some ideas how to modify igo's data.zip for specific screen resolutions (at least I managed to make "custom 640x480" data.zip for primo 2.4.0 WM for htc DIAM100) but I need to know what is the "Full Screen" resoluton (for igo and other applications) in different dpi modes on actv (ClearD 1.2.0 rom currently, just in case). Is it the same - 176x220 for all dpi's (I don't think so as the size of icons/fonts/etc are different). So, the real question is - what is the screen resolution I need to set up in data.zip to try to run igo primo on motoactv. To know that I need to understand if dpi change affects the "full screen resolution" in motoactv/android. And, once more, sorry if the question looks stupid (already explained etc) as I'm not developer...

yuiop0 said:
jkok - thank you so much for the explanations. It's become more clear for me but I'm not so experienced in android/development so I have some more questions related to dpi on actv.
My practical interest in this is - to investigate the possibility to run igo primo on this device (for route planning/voice navigation) because I'm not happy with Motorola map application (walk/run outdoor mode). I have some ideas how to modify igo's data.zip for specific screen resolutions (at least I managed to make "custom 640x480" data.zip for primo 2.4.0 WM for htc DIAM100) but I need to know what is the "Full Screen" resoluton (for igo and other applications) in different dpi modes on actv (ClearD 1.2.0 rom currently, just in case). Is it the same - 176x220 for all dpi's (I don't think so as the size of icons/fonts/etc are different). So, the real question is - what is the screen resolution I need to set up in data.zip to try to run igo primo on motoactv. To know that I need to understand if dpi change affects the "full screen resolution" in motoactv/android. And, once more, sorry if the question looks stupid (already explained etc) as I'm not developer...
Click to expand...
Click to collapse
well im not familiar with those apps, as for the resolutions/dpi im not sure of that :S it could possible be found on google, as basic hdpi (240 dpi), usually is around 480*800, and 120 dpi is like the motoactv 220*176, so i guess there isnt a ratio it follows, just sizing of images maybee :S, but i also just became a developer more resently withing the last 2 years so im still learning

[TUTE][TIPS] Android RAM Management

Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"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"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill
* processes with a oom_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips

B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.

[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?

Just in case..

mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!

@androcheck
Thanks for the encouragement..

nice tutorial with full descriptions...great..:good:

This is wonderfull! I will add this to the tutorial Index this weekend

mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you

thx u very much for the detailed explanation, gonna try ur recommended values later

great bro can be a sticky thread

mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire

zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.

@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..

mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS

This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.

I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?

Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think

Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...

Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).

[Q] Reducing Audio Latency Through Mods

I'm using a USB MIDI keyboard (through a mini USB connector) and trying to use my Galaxy S4 to drive the sound. The reason is that it's a small, portable, solid state computing device (stage vibrations already killed a couple hard drives in the last few months) that I already own. The drawback, of course, is latency. The delay between key press and sound generation makes this unworkable.
Here's a list of what I've done, I'd love to hear any advice for making this possible. I'm hoping to update this into a complete tutorial if it is successful:
1) The best app as far as sounds available (for the music I play, this may vary for you) AND allowing external keyboard control is Music Synthesizer (https://play.google.com/store/apps/details?id=com.levien.synthesizer). It would be ideal if there was an app that allowed VST plugins for custom sounds or had its own internal latency controls, but none seem to exist on Android. Please, please notify me if I'm wrong. That would make this whole setup better.
2) Because stock Android is super bloated, I wiped and flashed TriFroceRom onto my device using TWRP. This was harder for me than I'd like to admit, so allow me to point future people to what worked for me:
First you'll need to get TWRP up and running. Here's the walk through that worked for me: http://wccftech.com/install-twrp-recovery-on-samsung-galaxy-s4-i9505/
This is the best tutorial I've found for installing TriForce: http://wccftech.com/flash-triforcerom-54-samsung-galaxy-s4-sphl720/. MAKE SURE you do not just reboot straight away. Follow that last step about going back to home, reboot menu, into system. And it may ask to fix your root permissions too. I skipped that part and had a dead phone for a while.
Also, if you're on this stage and wondering about the best way to back everything up before you do it, G Cloud (https://play.google.com/store/apps/details?id=com.genie9.gcloudbackup&hl=en) is your answer. It is free, works perfect on upload and download, and lets you look at what is on their server at any time (including browsing photos, not just file names). Text messages and contacts sync too. If you pay a little bit of money for the full version, it will even keep your application data. If you're super cool and want to put in my referral number, it's BG2III (gives me more storage, and those are uppercase letter i not number 1s).
3) I then added Ktweaker so that I could overclock and improve the system performance. I watched this video to figure it out: https://www.youtube.com/watch?v=w5hcuLG-xp0. He has a link to download the files for Ktweaker which is this: http://forum.xda-developers.com/showthread.php?t=2294083 but you ALSO need to know that, with the links provided, you PROBABLY need 4.3 touchwiz version. TriForce Rom is a touchwiz rom for sure, and depending on when in the future you see this, check your device's about page (in the settings on your phone) to make sure which version of android you're running.
ALL OF THIS SAID, I have noticed zero improvement. I've read some documentation on Ktweaker and watched some videos on optimizing it and tried several different settings (overclocking, changing the CPU governor, reducing internal and external read ahead (and increasing, for kicks and giggles, though it seemed counter to my intuition), and ultimately have found not a single detectable millisecond of improvement in the latency.
Does anybody have any ideas? I understand that the Nexus devices are supposed to have lower latency, but a new device is not currently in my budget. It seems to me that MIDI controllers have been possible with very low latency since far before the computing power of even this phone was available, so conceivably there should be a way.

deleted

Microwear H5 MT6737M Android 6

Very scarce info everywhere, but quite a few people already use this $80 super-powerful watch including me (which is basically a micro-smartphone).
Many video reviews already.
I personally think that such powerful watch (much more powerful than my cheap 2016 tablet on previous Mediatek chip with less RAM) is a such small smartphone with illusion like it’s watch made by very modified version of Circle launcher with edited Android 6. I don’t see any limitations on this watch to run full stock Android OS here from the M6737M series smartphones, if ported. Even now all full-featured apps from Google store made for smartphones are perfectly runs here, including very big navigation apps and even the full “battery saver” function present from smartphones (first one which I see on Android watch ever). The only limitation which I noticed is very small display (specific apps cannot fit) and badly edited Android OS (like completely deleted status bar from OS, any 3rd-party status bar apps are installing fine but crashing on settings). Most 3rd-party launchers from Google store and open sources are installing here (only with few exceptions) - the most stable one I’ve found is open source “Essential Launcher” ver. 1.3.
My feeling from “lift wrist turn on” function with “swipe pages” makes almost iPhone X experience here, no any buttons needed, very stable power on only by view and swiping windows (including closing them by swiping to the right) makes very good feedback to the user.
Everything spoiled only by edited OS - awful work with fonts, too many illogical Menu lists, deleted functions like not present “Storage” in OS settings(only shortcut to file explorer) - the USB storage media not adding because of edits on OS level, considering normal micro-USB & even if you turn on “usb media” in developer settings.
Very few watch-faces with no way to install any others, it’s obviously fake feature to make you feel and use them as watch.
So, what I think many would be glad to see here - the root is the most important goal for now(developer menu allows bootloader unlock-not sure if it’s true because USB media settings there not works), maybe putting the normal Android is the next goal.
The root is very needed to firewall for very shady apps here, it’s very powerful device so it have full smartphone spyware, like notorious MTK Logger & Thermal Manager, which can work at sleep mode (it is almost suspicious that they broke USB media function so user can’t bypass network connection for installs). Root needed to work with display resolution and etc.
Edit: the processor by Aida app recognized as MT6737M but on Aliexpress you can find watch easily by search term processor "MTK6737M" (only like 7 sellers total).

I have the H5 as well, and you're correct! The main draw back is the stripped down OS, for example the call forwarding features are missing..

Ordered one of these a few weeks ago, should be getting delivery soon. Interesting to see how it performs, my last android watches have been mt6572 & mt6580, both of these I ported full Android versions to, I may give it a go at porting a full Android version to this in the future

Check this also:
https://forum.xda-developers.com/sm...dorid-6-0-finow-q1-pro-smartwatch-4g-t3745271

Well I got mine today, seems good so far. As for alternative launchers tried a few that work OK, if you want to change the clockskins for now I have found that Universal Launcher New Gen works just fine (you add clockskin folder +clockskins)
https://play.google.com/store/apps/details?id=com.ricktop.ClockSkinCoco

I use mine at least 2 weeks maybe. Without root (which I plan to do but don't have time right now) I do not connect them to any Internet, so I'm using them as just watch (it's my first smartwatch). Files I'm sending through bluetooth from my Android phone, quite neat that you can install apps from bluetooth menu right away.
About battery - very good, if you don't connect them to networks at all, with battery Saver on & "wrist move activation" off they can work whole week on 1 charge (this includes some extensive using in 2 days on winter street with GPS apps, camera-video, constant time checking and etc.). They CAN HOLD MORE days, after the full charge, watch calculated the battery to the 15 days of work - which is believable, as I see now if you will check only time manually they can easily save 1 charge to 12-13 days. I use charger with them only once at week, it's quite shocking to read Apple Watch forums where people making that every 2-3 days.
They're quite powerful - making the zip archive internally from 250Mb photos/videos takes something like 2 minutes.
Because the step-counter here work always (even if you take them to the other room) - this device is just made for the SmartNavi (open source navigation app which use mainly step-counter with rare or no GPS connection for battery saving).

Can't wait for a custom recovery to be made for it, so I can root it. Tried all the rooting apps out on the web and none work so far.

Well I have managed to get Root access, using Magisk, and flashing patched boot image, struggling to create a TWRP recovery. Hoping someone out there can come up with a custom recovery.

Managed to port TWRP to it, but it is in miniature! going to have a play around with it to see if I can make it usable. Anyone with suggestions be grateful - well gave up on trying to amend TWRP resolution, and installed flashify - just flashed an AOSP ROM to the H5, happy days!

Well done stevea76
A step by step or point in the right directions kinda 'guide' would be really appreciated, cos the H5 with its stock funos is far from fun... sure its usable but no fun.

Wizard2004 said:
Well done stevea76
A step by step or point in the right directions kinda 'guide' would be really appreciated, cos the H5 with its stock funos is far from fun... sure its usable but no fun.
Click to expand...
Click to collapse
I will put something together at the weekend, by then I should have something usable, don't want people breaking their new toys!

stevea76 said:
I will put something together at the weekend, by then I should have something usable, don't want people breaking their new toys!
Click to expand...
Click to collapse
It would be interesting to find if there's any "recovery mode" on stock ROM image at all, considering that there's only 1 button. On similar watches from Samsung and etc they have quite awkward way to enter recovery - like some swipe to the left in time of logo showing and etc. I tried to repeat any swiping during boot - nothing...
Also, by the usual use of watch (almost a month now) I can say that in my case of use the battery holding 1 full charge for 7 days, so a week, the same amount calculated by OS also. That's the battery regime or mode which is now constant in my case (it can be different in situation of other people).

The battery here can be saved even more for a week - I managed to notice that "sleep stat" function are working here at all times and cannot be turned off like step counter in this Android OS, at the night time it randomly turning on the pulse checker light even if you not wearing them, which using the battery (not a big deal, but using some).

Wizard2004 said:
Well done stevea76
A step by step or point in the right directions kinda 'guide' would be really appreciated, cos the H5 with its stock funos is far from fun... sure its usable but no fun.
Click to expand...
Click to collapse
Here is the link to the AOSP ROM I ported to the H5.
I must express it is a long winded way to flash it as I am not technically minded, just playing at it, and only do this if you have the stock ROM downloaded as a backup to revert back to and don't mind the possibility of wrecking your toy!, the only reason for me doing it this way is that the recovery TWRP I ported is functional, but not set for the screen size for the H5 so unless you have bionic eyes it is nearly impossible to use, hence the reason for my 'workaround' (note: If anyone can make the TWRP scaled for the watch, just flash the ROM in the usual way)
Here is a 'sort of' guide and link to files.
https://www.androidfilehost.com/?w=files&flid=252561
1. Flash
Microwear_Magisk_Patched_Boot_IMG using splash tool, reboot device.
2. Install Magisk Manager from here: https://forum.xda-developers.com/apps/magisk/official-magisk-v7-universal-systemless-t3473445/page4
Open Magisk manager and go to settings, set default action to 'Grant'
You now have root.
3. Flash
Microwear_H5_Recovery_TWRP using spflashtool.
4. Install
Flashify (for root users) from the Playstore.
5. Download directly to the watch (or to Computer and transfer to the watch) Microwear_H5_AOSP ROM AND the GAPPS of your choice (Open Gapps arm64 nano was my choice)
6. Use Flashify to install zip(s) making sure you click TWRP as recovery option and also tick the wipe cache, data etc (add the Gapps as well if you want Google)
Click Reboot on flashify.
Hopefully the watch boots to recovery and installs the ROM and gapps!
First boot sticks on boot animation, so if not starting after 3 or 4 minutes power off the watch and reboot, after another 5 to 10 minutes you should see 'android is starting'
Nav Bar is by default on permanently, to make this and notification bar 'hide' (fully Immersive) I used this method.
1. install on pc ADB (Guide below)
2. Enable developer options and USB debugging on watch.
3. connect watch (switched on)
4. Open ADB on pc.
5. Type: adb devices (click enter)
(should see you device is connected)
6. Then type: adb shell - (click enter)
7. Then type this line:
settings put global policy_control immersive.full=*
Now the navigation bar will pop up when you pull down or up slightly on the screen and will auto hide after a couple of seconds.
As for sensors I don't think any are working.
I have included 3 launchers on this ROM, so make your choice!
Please, please, please DO NOT ATTEMPT THIS if you don't know how to revert back to stock rom. I bear no responsibility for broken toys!

Guys, who already have a scatter file for this watch, i really want to make a backup of current ROM before checking for any new updates (which is quite good version from January and there's nowhere on Internet any firmware files for this watch, so saving and sharing ROM is important). If i manage to download ROM i will post it on Google drive.
I wanted to force watch go into it's own recovery but my ADB installation don't see this watch connected - there's a primitive subsystem on watch beside Android OS, it can be seen when you turn Android OS "power off" and connect USB for charging - it will show the battery, i'm puzzled how to enter into any settings of that subsystem.

The stock firmware is on the Microwear Website.
http://m.microweartech.com/en/MicrowearFirmware.html

stevea76 said:
The stock firmware is on the Microwear Website.
http://m.microweartech.com/en/MicrowearFirmware.html
Click to expand...
Click to collapse
Yeah, i noticed only now, strangely but i remember that a month ago there was nothing about H5 model on their site when i searched…maybe because they just released it.
Also the firmware have the same scatter file - the first one which i found myself for some cheap smartphone on 6737 chip, as i remember i found it on reddit.
As i seen no updates of firmware for now.

crustier said:
Yeah, i noticed only now, strangely but i remember that a month ago there was nothing about H5 model on their site when i searched…maybe because they just released it.
Also the firmware have the same scatter file - the first one which i found myself for some cheap smartphone on 6737 chip, as i remember i found it on reddit.
As i seen no updates of firmware for now.
Click to expand...
Click to collapse
No updates as yet. I have ported an AOSP version, pretty much stock Android to the H5, it is basic, but I like the 'stock experience' on a square watch. Not got the sensors set up, but not really bothered about how many steps I have done on any given day or my heart rate for that matter.
Also if you want fancy clockskins then Eric's launcher works just fine on it.

stevea76 said:
No updates as yet. I have ported an AOSP version, pretty much stock Android to the H5, it is basic, but I like the 'stock experience' on a square watch. Not got the sensors set up, but not really bothered about how many steps I have done on any given day or my heart rate for that matter.
Also if you want fancy clockskins then Eric's launcher works just fine on it.
Click to expand...
Click to collapse
As i understand correctly - here they simulated or just copied clock skins from Apple watch?
Where to find Eric launcher?
For everyone else i will write again link to the firmware from Microwear site here – https://drive.google.com/drive/folders/1WaktAl-cjCTE1l0jffA7BnevzESdlCwc?usp=sharing
because chinese support is very short in time and can vanish with website very easily (for example to find an older firmwares to my Onyx Boox ereader i used "webarchive" service, thanks gods we have it - only from this saved archived copies of pages i found the sharing links to the older firmwares, still i cannot find the first version of RemixOS release for KitKat-if anyone have the alpha - please message me)

Eric's launcher is here:
https://play.google.com/store/apps/details?id=com.ricktop.ClockSkinCoco
All about the clockskins mainly for round Full Android watches here:
https://plus.google.com/communities/109827242607524552712
For square Full Android Watches here:
https://plus.google.com/communities/118413074291213420811
A useful forum for Full Android watches (round) with guides how to install custom watch faces:
http://roundandroidwatches.proboards.com