unisoc or api >= 34: fast thaw . add perl script

[john-peterson]

unisoc or api >= 34: fast thaw . add perl script

vim:ft=text

on unisoc boards api 33 hang and resume API connection with this

termux-volume
/system/bin/am freeze $(pidof com.termux.api) f
termux-volume
/system/bin/am freeze $(pidof com.termux.api) unf

the second call hangs forever when the socket is running but frozen

this might be the same issue reported for all android 34 and up

termux/termux-api#638

compaction and freeze are unisoc patches that hasn't made it up stream . or back ported to 33

restore socket connection and thaw instead of broad cast

I tried the proposed solution for my phone by lowering it to my API 33 and it's horribly slow

if (android_get_device_api_level() < 33) {
time build/termux-api-broadcast Volume
real 0m0.455s

compared to socket connection with no freeze check

real 0m0.047s

thaw fast

this patch use minimal over head not even noticeable usually

time dumpsys activity -p com.termux.api p com.termux.api |grep isFrozen
hasPendingCompaction=true isFreezeExempt=false isPendingFreeze=true isFrozen=false
real 0m0.020s

time /system/bin/am freeze $(pidof com.termux.api) unf
real 0m0.066s

time $P/libexec/termux-api Volume
real 0m0.043s

this has no freeze info

time dumpsys procstats --current --section proc com.termux.api
real 0m0.023s

all Linux commands are in the centi second range. nothing is instant

time ps -o stat -p $(pidof com.termux.api) h
Sl
real 0m0.034s

no API check needed

the api check

vim $P/include/bits/get_device_api_level_inlines.h
getprop ro.build.version.sdk

was lost in translation to perl and is not needed if dumpsys works

if this problem applies to all boards for 34 and up not just unisoc . it should be either unisoc 33 and up or any 34 and up

if ($api >= 34 || $api >= 33 && $board eq "unisoc") {
system '/system/bin/am freeze $(pidof com.termux.api) unf';

todo close onFreeze or timeout API process after ten minutes and remove freeze check

if there is onFreeze event the app can be closed instead and remove freeze check

or time out API app after ten minutes idle. with results repeated calls are still fast . but first time use for a long time is slow . freeze check can be avoided entirely

this is the best middle ground between closing the API client socket every time and running it forever

the command will work every time with out thaw check

for example TTS may run dumpsys hundreds of times with the current solution . freeze can be avoided entirely instead with I only drawback that the call is slow the first time

cancelled idea optional thaw

at some point I considered making this optional

use Getopt::ArgParse;
my $ap = Getopt::ArgParse->new_parser(
$ap->add_argument('--thaw', '-t', type => 'Bool', help => 'thaw process on unisoc if API calls hang. example thaw and print volume: termux-api -t Volume');

but it's meaningless

keep alive service drain battery hog memory

the service prevent this problem but now you have disabled battery manager . and battery stats will probably show that you ran the socket for ten hours and used it twice. not the best solution

termux-api-start
am startservice -n com.termux.api/.KeepAliveService

the problem with keep alive is I rarely use the API and don't want the stress of it running all the time for no reason . it's like running pulse audio service all the time. no it's on demand . it's not all the time . I like a clean pstree not full of stuff that I might use once or twice

a service drains more battery the system can't manage battery anymore . apps are closed or frozen for a reason . a service use more battery and hog memory longer

I don't want to pile on the memory trash pile with another service . my biggest problem with android is the gigantic back ground heap of trash that is always running or hogging memory if paused . even battery saver can't stop it

this command shows the enormous amount of use less jobs that run all the time even with battery save

dumpsys batterystats|ack "(Apk|Job|Proc|Service) "

many apps are programmed to do something useless every ten minutes and there is no way to stop it. it will launch several hundred meg ram process and close it after ten seconds. over and over

battery saver greatly improve this disaster but not completely . the only sensible idle drain off line is zero. absolute zero

kill start too slow

another way might be kill it after use

killall com.termux.api

the problem with kill is repeat calls. I usually use API in burst several times . if my wrapper kill it every time repeat calls take forever . it takes one second to start API every time. thaw is ten times faster and feels nearly instant

add perl script for testing redundancy readability

I had no connection and could not edit the source . I had no idea what the problem was and had no source to find the hang . incredible frustrating running strace and elf inspection

there has to be a script in the packet also for finding bugs . I appreciate the effort to cut call time

time build/termux-api-broadcast Volume
real 0m0.045s
time termux-api Volume
real 0m0.110s

but so many other things favour script . if some thing goes wrong like it always does script is better