Related
Hi Folks
Here's a quick script I knocked up to select a device from a list when you have multiple devices connected with adb.
Forgive me If something similar has already been posted.... I had a search but nothing obvious came up.
Code:
#!/bin/bash
## A Cheeky Wrapper For ADB and Multiple Devices
if [ $1 == "devices" ] ; then
adb devices
exit;
fi
select DEV in $(adb devices | awk 'NR>1 && $2="device"''{print $1}');
do
adb -s $DEV $*;
break
done
If you don't know what this is, It's probably not any use to you!
Thanks
Trev
Is there anyone working on it? Its really worth a shot. Even for the Aroma installer.
Özgürce said:
Is there anyone working on it? Its really worth a shot. Even for the Aroma installer.
Click to expand...
Click to collapse
Blefish is porting touch recovery, he tweeted that he will be releasing it with CM9 0.03 in mid July.
Yea, its working well, but its missing the atmel support again (...). I will tweet as soon as I get it properly working on both touch panels.
Sent from my U8800 using Tapatalk 2
Can you release it? At atmel will work with hardware buttons until you fix this..
Sent from my U8800
Why release it since the touch wont work for Atmel users, so no TOUCH recovery.
AceDroidX said:
Why release it since the touch wont work for Atmel users, so no TOUCH recovery.
Click to expand...
Click to collapse
Yes, but Blefish could release a version for those with synaptics... I think it wouldn't hurt
Sent from my U8800
It will be only for U8800 (not for pro) I think??
fjsferreira said:
Yes, but Blefish could release a version for those with synaptics... I think it wouldn't hurt
Sent from my U8800
Click to expand...
Click to collapse
Yes, and we could act as beta testers, so if there is some bug it could be fixed on next, atmel support version.
Blefish said:
Yea, its working well, but its missing the atmel support again (...). I will tweet as soon as I get it properly working on both touch panels.
Sent from my U8800 using Tapatalk 2
Click to expand...
Click to collapse
Thats great! Glad to hear someone working on it. I'm using 4EXT Touch recovery on my Incredible S. Its awesome.
Blefish said:
Yea, its working well, but its missing the atmel support again (...). I will tweet as soon as I get it properly working on both touch panels.
Sent from my U8800 using Tapatalk 2
Click to expand...
Click to collapse
Will it support Universal Flasher Tool for theming?
With your CyanogemMOD ROM that will be a must have!!!
For the moment it is only supported by 5.0.2.7 CWM...
sr21 said:
Will it support Universal Flasher Tool for theming?
With your CyanogemMOD ROM that will be a must have!!!
For the moment it is only supported by 5.0.2.7 CWM...
Click to expand...
Click to collapse
Can you get me the log? Try to flash it and after that go to advanced options, you should find it there.
About recovery - I'll cook it up, it will not have "offmode" charging as it's not handled by recovery nowadays. And of course, no Atmel support just yet.
Blefish said:
Can you get me the log? Try to flash it and after that go to advanced options, you should find it there.
About recovery - I'll cook it up, it will not have "offmode" charging as it's not handled by recovery nowadays. And of course, no Atmel support just yet.
Click to expand...
Click to collapse
LOG:
Code:
failed to open /sys/class/android_usb_/android0/state: No such file or directory
Universal Flasher Tool 3.6
sr21 said:
LOG:
Code:
failed to open /sys/class/android_usb_/android0/state: No such file or directory
Universal Flasher Tool 3.6
Click to expand...
Click to collapse
That error is common in 2.6.35 kernel with CWM 5.5.0.4. I'd need the whole log to help you. Or, you can send me the updater-script that should be located at zip-file/META-INF/com/google/android.
Blefish said:
That error is common in 2.6.35 kernel with CWM 5.5.0.4. I'd need the whole log to help you. Or, you can send me the updater-script that should be located at zip-file/META-INF/com/google/android.
Click to expand...
Click to collapse
You can see the script in the Universal Flasher Tool link that I provided before. The zip is a template.
It uses a script to do the modding in the recovery.
You can also check one of my flashable zips that I use in my TouchWiz MOD/ADDON PACK: Touchwiz_for_u8800_u8800pro_v4.1.0.1u1_signed.zip
You need to check the /META-INF/com/google/android/, the /tools/, /MORPH/ (themed apps goes here) and the MOD.config file.
I think the script fails here (/tools/run.sh):
Code:
################### MORPHING ##################
UI_PRINT " "; LOG="MORPHING >>"; LOGS "$LOG"; UI_PRINT "$LOG"
CHECK2=0
x=1
until [ $x = 0 ]; do
if [ -d $PATHDATA ];then
WORK=$PATHDATA
SYSTEM="/data/app"
elif [ ! -d $PATHDATA ] && [ -d $PATHFRAM ];then
WORK=$PATHFRAM
SYSTEM="/system/framework"
elif [ ! -d $PATHDATA ] && [ ! -d $PATHFRAM ] && [ -d $PATHAPP ]; then
WORK=$PATHAPP
SYSTEM="/system/app"
elif [ ! -d $PATHDATA ] && [ ! -d $PATHFRAM ] && [ ! -d $PATHAPP ]; then
x=0
fi
if [ $x = 1 ]; then
for f in $(ls $WORK); do
if [ -e $SYSTEM/$f ];then
if [ `/cache/tools/tar -tPf $RESTORE/backup.tar $SYSTEM/$f | wc -l` = 0 ]; then
/cache/tools/tar -prPf $RESTORE/backup.tar $SYSTEM/$f
fi
mkdir -p /$APPLY
f2="`echo $f | cut -d "." -f 1`.zip"
mv $SYSTEM/$f /$APPLY/$f2
#FIX -V4 SUFFIXES IN FOLDERS
if [ $V4MORPHING = "yes" ] && [ -d $WORK/$f/res ];then
FILES=`/system/xbin/7z l $APPLY/$f2 | awk '{print $6}'`
cd $WORK/$f/res
find * -type d | while read i;do
if [ `echo $FILES | grep $i-v4 | wc -l` != 0 ]; then
mv $WORK/$f/res/$i $WORK/$f/res/$i-v4
fi
done
fi
#CYANOGENMOD vs STOCK BASED ROM
if [ $MULTIPLATTFORM = "yes" ];then
cd $WORK/$f
find * -type f | while read i;do
if [ $CYANO = "yes" ] && [ `basename $i | cut -d "#" -f 1` = "CMOD" ];then
mv $WORK/$f/$i $WORK/$f/`dirname $i`/`basename $i | cut -d "#" -f 2`
elif [ $CYANO = "no" ] && [ `basename $i | cut -d "#" -f 1` = "CMOD" ];then
rm $i
fi
done
fi
#MORPH, ZIP & ZIPALIGN
if [ $CLEANMORPHING = "yes" ];then
MORPH=`/system/xbin/7z a -ur0x2y2z2w2 $APPLY/$f2 $WORK/$f/* | grep -o -E "Everything is Ok" | wc -l`
else
MORPH=`/system/xbin/7z a $APPLY/$f2 $WORK/$f/* | grep -o -E "Everything is Ok" | wc -l`
fi
/cache/tools/zipalign -f 4 $APPLY/$f2 $SYSTEM/$f
rm -Rf $APPLY $WORK/$f
chown 0.0 $SYSTEM/$f && chmod 644 $SYSTEM/$f
if [ ! -e $SYSTEM/$f ] || [ $MORPH = 0 ]; then
/cache/tools/tar -pxPf $RESTORE/backup.tar $SYSTEM/$f
LOG="[X] Error with $f!"; LOGS "$LOG"; UI_PRINT "$LOG"
LOG="[<] Restored original $f"; LOGS "$LOG"; UI_PRINT "$LOG"
let CHECK2=$CHECK2-1
else
LOGS "[v] $SYSTEM/$f morphed"; UI_PRINT "[v] $f morphed"
let CHECK2=$CHECK2+2
fi
else
LOG="[!] $f not found, ignoring"; LOGS "$LOG"; UI_PRINT "$LOG"
fi
done
rm -R $WORK
fi
done
if [ $CHECK2 -le 0 ];then
LOG="[!] Nothing to morph"; LOGS "$LOG"; UI_PRINT "$LOG"
fi
I figured I'd post this request for help in these forums, as I'm not getting much of a response in the T-Mobile forum. Instead of re-writing anything, I'll just quote my original post below.
Aou said:
As some of you know, I'm working on porting both Ubuntu Touch and Ubuntu Desktop to the Galaxy S5 (natively booting). I had partially succeeded in doing this with AT&T Galaxy S4, but with locked bootloaders, I ran into too much trouble to make it fun anymore. All that being said...
On the Galaxy S4, it was easily possible to read and write to the framebuffer. It was located at /dev/graphics/fb0, unless you enable DEVTMPFS in the kernel (in this case, I have), which ultimately moves it to /dev/fb0 if remounting /dev correctly. Examples of screwing around with the framebuffer include:
cat /dev/urandom>/dev/fb0
(shows random garbage all over the screen - more helpful if android is stopped)
cat /dev/zero>/dev/fb0
(blanks the screen)
cat /dev/fb0>output.png
(effectively takes a screenshot .... kinda)
(note: the same above applies to /dev/graphics/fb0 if not remounting /dev - such trying this straight from android)
All fun and games, until you need it to load Xorg server and lightdm - at which point this sort of access to the framebuffer is absolutely critical.
My problem with the Galaxy S5: I can't do anything with the framebuffer device! If I try some of the above commands with it, all I get is:
Code:
cat: fb0: No such device
(or similar, depending on what I'm trying to do). Additionally, I can't get the framebuffer console to work, either - nor can I get it to output a getty shell on the framebuffer. All of this I could "easily" do on the Galaxy S4.
The above applies whether I'm in Android, within an Ubuntu within Android, or natively booting to Ubuntu (which I'm currently able to do, btw... just no video!). For the record, I most certainly do have the FB (and FB_MSM) and corresponding options enabled in my kernel config.
So I'll ask again, where is my framebuffer? (and further, how do I get it back?)
If you can answer my questions, I might be able to provide you some Ubuntu goodness.
Click to expand...
Click to collapse
Did you ever figure this out? I'm having the same issue on several devices - Galaxy Note i717 (CM10), Galaxy Note 3 (CM11 and stock), HP TouchPad (CM11). I have a Debian chroot on all of them and am trying to stop Android and run xorg. I don't have devtmpfs, just bind-mounting /sys, /proc, and /dev into chroot from Android but I did make a symlink /dev/fb0 -> /dev/graphics/fb0. I ssh into the Debian session and then kill Android using "stop" from terminal emulator or adb. This blanks the screen on the Note 3 and TouchPad but on the Note 1 it just freezes the display. On all three, writing to /dev/fb0 (via cat or via starting lightdm session) results in no activity on the screen, X halting or erroring, or sometimes "/dev/graphics/fb0: no such device" messages. I also tried using fb1, which should be MHL HDMI but my MHL adapter doesn't appear to work on my Note 3 (flashed it back to stock from CM11 and still nothing) though some HDMI related stuff does appear in dmesg. I'm stumped at this point. There's a bunch of interesting stuff in sysfs that may be of interest:
/sys/class/lcd/panel - contains a bunch of stuff related to the LCD (AMOLED) panel device, including lcd_power which may be necessary to re-turn-on the screen after Android shuts it off
/sys/class/graphics/fb0 - contains a bunch of framebuffer related entries, including an option to blank the display (cat 1 > blank does blank the screen even if Android is running) and mode setting
/sys/class/graphics/fb1 - contains the same stuff from fb0 plus a bunch of HDMI/MHL related information, including HDMI connected state
It definitely seems something else is either locking the framebuffer or there is some security thing preventing access to it. Not sure what would be the cause of this weirdness but I don't like it.
CalcProgrammer1 said:
Did you ever figure this out? I'm having the same issue on several devices - Galaxy Note i717 (CM10), Galaxy Note 3 (CM11 and stock), HP TouchPad (CM11). I have a Debian chroot on all of them and am trying to stop Android and run xorg. I don't have devtmpfs, just bind-mounting /sys, /proc, and /dev into chroot from Android but I did make a symlink /dev/fb0 -> /dev/graphics/fb0. I ssh into the Debian session and then kill Android using "stop" from terminal emulator or adb. This blanks the screen on the Note 3 and TouchPad but on the Note 1 it just freezes the display. On all three, writing to /dev/fb0 (via cat or via starting lightdm session) results in no activity on the screen, X halting or erroring, or sometimes "/dev/graphics/fb0: no such device" messages. I also tried using fb1, which should be MHL HDMI but my MHL adapter doesn't appear to work on my Note 3 (flashed it back to stock from CM11 and still nothing) though some HDMI related stuff does appear in dmesg. I'm stumped at this point. There's a bunch of interesting stuff in sysfs that may be of interest:
/sys/class/lcd/panel - contains a bunch of stuff related to the LCD (AMOLED) panel device, including lcd_power which may be necessary to re-turn-on the screen after Android shuts it off
/sys/class/graphics/fb0 - contains a bunch of framebuffer related entries, including an option to blank the display (cat 1 > blank does blank the screen even if Android is running) and mode setting
/sys/class/graphics/fb1 - contains the same stuff from fb0 plus a bunch of HDMI/MHL related information, including HDMI connected state
It definitely seems something else is either locking the framebuffer or there is some security thing preventing access to it. Not sure what would be the cause of this weirdness but I don't like it.
Click to expand...
Click to collapse
Unfortunately, I never did figure this out. Because of this roadblock, I have pretty much given up on the idea (not to mention I had a baby and I've started in the Alpha for an upcoming MMO). I did poke around a little with /sys/class/graphics/fb0 before I quit, but didn't get far.
I'm wondering if "what changed" was SELinux, or something like that? Perhaps it is a security "feature" written into modern bootloaders that prevents direct access to the framebuffer?
Aou said:
Unfortunately, I never did figure this out. Because of this roadblock, I have pretty much given up on the idea (not to mention I had a baby and I've started in the Alpha for an upcoming MMO). I did poke around a little with /sys/class/graphics/fb0 before I quit, but didn't get far.
I'm wondering if "what changed" was SELinux, or something like that? Perhaps it is a security "feature" written into modern bootloaders that prevents direct access to the framebuffer?
Click to expand...
Click to collapse
Ofcourse, ****ing qualcomm freaks made it atlast, good for them!!! From OpenSource to closed source == from free to jail!
Recently got a Oneplus One, and am facing the same problem trying to port desktop distributions to this device.
I've tried disabling SELinux entirely, but this gives the same result, which leads me to believe it's something in the kernel.
I'm currently configuring a customized Cyanogenmod 11 kernel, but am not sure what to look for.
I suspect that switching to an older Android version (and thus older kernel) would make it "just work" on this device, but the OnePlus One, as far as I'm aware, doesn't have any pre-KitKat 4.4.2 Android roms.
Did any of you get anywhere with this issue, or am I on my own on this one?
Update: I decided to see if this would work in TWRP recovery. Interestingly, I could cat /dev/graphics/fb0 and get the right output, but writing to it did nothing. I tried blanking and writing random data in several ways, including cat and dd, but the screen would stay unchanged.
That, however, is a different issue than the one we experienced so far. Now to get it working within Android.
Hi does anyone know how to get this to work.
I have an Alcatel OT918D ANDROID 2.3.5.
I have managed to compile my own kernel and boot it. But for adding the frame buffer option in the makefile I get this error during compilation:
**************************************************************************************************************
drivers/video/console/fbcon.c:638: note: expected 'struct file *' but argument is of type 'struct fb_info *'
drivers/video/console/fbcon.c:638: error: too few arguments to function 'info->fbops->fb_open'
drivers/video/console/fbcon.c: In function 'con2fb_release_oldinfo':
drivers/video/console/fbcon.c:670: warning: passing argument 1 of 'oldinfo->fbops->fb_release' from incompatible pointer type
drivers/video/console/fbcon.c:670: note: expected 'struct file *' but argument is of type 'struct fb_info *'
drivers/video/console/fbcon.c:670: error: too few arguments to function 'oldinfo->fbops->fb_release'
drivers/video/console/fbcon.c:673: warning: passing argument 1 of 'newinfo->fbops->fb_release' from incompatible pointer type
drivers/video/console/fbcon.c:673: note: expected 'struct file *' but argument is of type 'struct fb_info *'
drivers/video/console/fbcon.c:673: error: too few arguments to function 'newinfo->fbops->fb_release'
drivers/video/console/fbcon.c: In function 'fbcon_startup':
drivers/video/console/fbcon.c:868: warning: passing argument 1 of 'info->fbops->fb_open' from incompatible pointer type
drivers/video/console/fbcon.c:868: note: expected 'struct file *' but argument is of type 'struct fb_info *'
drivers/video/console/fbcon.c:868: error: too few arguments to function 'info->fbops->fb_open'
drivers/video/console/fbcon.c: In function 'fbcon_exit':
drivers/video/console/fbcon.c:3388: warning: passing argument 1 of 'info->fbops->fb_release' from incompatible pointer type
drivers/video/console/fbcon.c:3388: note: expected 'struct file *' but argument is of type 'struct fb_info *'
drivers/video/console/fbcon.c:3388: error: too few arguments to function 'info->fbops->fb_release'
make[3]: *** [drivers/video/console/fbcon.o] Error 1
make[2]: *** [drivers/video/console] Error 2
make[1]: *** [drivers/video] Error 2
make: *** [drivers] Error 2
make: *** Waiting for unfinished jobs....
CC [M] ../mediatek/source/kernel/drivers/lttng/probes/net-extended-trace.o
CC [M] ../mediatek/source/kernel/drivers/lttng/probes/block-trace.o
CC ../mediatek/source/kernel/kernel/trace_mt65xx_mon.o
LD [M] ../mediatek/source/kernel/drivers/lttng/ltt-relay.o
CC ../mediatek/source/kernel/drivers/m4u/m4u_kernel.o
../mediatek/source/kernel/drivers/m4u/m4u_kernel.c: In function 'm4u_user_v2p':
../mediatek/source/kernel/drivers/m4u/m4u_kernel.c:66: warning: format '%d' expects type 'int', but argument 3 has type 'struct task_struct *'
************************************************************************************************************
How about populating with mdev?
Aou said:
I figured I'd post this request for help in these forums, as I'm not getting much of a response in the T-Mobile forum. Instead of re-writing anything, I'll just quote my original post below.
Click to expand...
Click to collapse
Hey, I am not a S5 owner, but I recently ported Debian to my Samsung Captivate Glide with Xorg and XFCE:
http://forum.xda-developers.com/captivate-glide/general/samsung-captivate-glide-debian-chatter-t3233807
The trick that I used was during the init scripts I call upon busybox's mdev to populate the nodes like fb0 and fb1:
Code:
#!/sbin/busybox sh
/sbin/busybox echo "mounting proc,sys,dev" > /log/boot.log
/sbin/busybox mount -t proc none /proc
/sbin/busybox echo "mounted proc" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox mount -t sysfs none /sys
/sbin/busybox echo "mounted sys" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox mount -t tmpfs none /dev
/sbin/busybox echo "mounted dev" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox echo "Populating mdev" >> /log/boot.log
/sbin/busybox mdev -s
/sbin/busybox ls /dev > /log/dev.log
/sbin/busybox echo "mdev populated" >> /log/boot.log
/sbin/busybox sleep 1
#export PATH=/sbin:/usr/sbin:/bin:/usr/bin
#/etc/init.d/rc.local start
#/sbin/busybox echo "All done" >> /log/boot.log
# Launch delayed init script
/etc/init.stage2 >/android/log/boot.log 2>&1 &
I have not messed with Ubuntu Touch yet myself, but I know that this works for Debian so that I can use /dev/graphics/fb0 in my xorg.conf file to start my x display.
AlaskaLinuxUser said:
Hey, I am not a S5 owner, but I recently ported Debian to my Samsung Captivate Glide with Xorg and XFCE:
http://forum.xda-developers.com/captivate-glide/general/samsung-captivate-glide-debian-chatter-t3233807
The trick that I used was during the init scripts I call upon busybox's mdev to populate the nodes like fb0 and fb1:
Code:
#!/sbin/busybox sh
/sbin/busybox echo "mounting proc,sys,dev" > /log/boot.log
/sbin/busybox mount -t proc none /proc
/sbin/busybox echo "mounted proc" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox mount -t sysfs none /sys
/sbin/busybox echo "mounted sys" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox mount -t tmpfs none /dev
/sbin/busybox echo "mounted dev" >> /log/boot.log
/sbin/busybox sleep 1
/sbin/busybox echo "Populating mdev" >> /log/boot.log
/sbin/busybox mdev -s
/sbin/busybox ls /dev > /log/dev.log
/sbin/busybox echo "mdev populated" >> /log/boot.log
/sbin/busybox sleep 1
#export PATH=/sbin:/usr/sbin:/bin:/usr/bin
#/etc/init.d/rc.local start
#/sbin/busybox echo "All done" >> /log/boot.log
# Launch delayed init script
/etc/init.stage2 >/android/log/boot.log 2>&1 &
I have not messed with Ubuntu Touch yet myself, but I know that this works for Debian so that I can use /dev/graphics/fb0 in my xorg.conf file to start my x display.
Click to expand...
Click to collapse
That seems interesting, I'll dig up my OPO soon to see what I can do with that.
Did you base your project on an Android kernel, or did you manage to compile a "real" Linux kernel? What kernel version?
From what I can find the Glide (officially) only supports up to Android 4.0, did you start from an Android version and, if so, what version?
The problem I had on my OPO seemed to be specific to Android 4.4+, although your solution may still work.
I'm definitely going to play with this. Thanks for reporting your findings.
The FB_TARGET layer is where GLES composition output goes. Since all layers shown above are using overlays, FB_TARGET isn’t being used for this frame. The layer's name is indicative of its original role: On a device with /dev/graphics/fb0 and no overlays, all composition would be done with GLES, and the output would be written to the framebuffer. On recent devices there generally is no simple framebuffer, so the FB_TARGET layer is a scratch buffer.
Note: This is why screen grabbers written for old versions of Android no longer work: They're trying to read from the Framebuffer, but there is no such thing.
Click to expand...
Click to collapse
Found this on http://source.android.com/devices/graphics/architecture.html
All about Android graphics. For my build on the Samsung Captivate Glide, I am using an Android kernel, but not a stock one. Cranium is the name of it. Anyways, it is an older ROM that I took it from, 2.3.7, I believe. So I bet you are right, if you take an older Android environment it would most likely work that way.
However, busybox's mdev -s option simply creates all the "standard" things you need, making nodes for all the standard things that are not there. So it *should* work, and busybox is plenty small enough to put on there. Also, you could do it the old fashion way with mknod, but I have not tried that myself, as mdev did it for me. In any event, good luck, and I hope that helps!
Guys, Im in the same situation and figured it out partially.
I can now see garbage data on screen with fast alteration between android screen and the urandom garbage after disabling hardware overlay :
b) debug.composition.type = gpu
c) dev.pm.gpu_samplingrate = 1
d) debug.sf.hw = 1
e) debug.egl.hw = 1
^ In build.prop, though i still recieve no such device, still works
The garbage data is updated while having graphical changes in Android, like scrolling menus updates the garbage data...
The main issue is, killing Android (surfaceflinger etc) results in black screen. Ofc all this worked after doing what OP has done in kernel config. Tried on both s5 and tab s, gotta check TWRP/CWM source code and device tree specific files for our devices to see how it works. (Hate that proprietary Mali gpu)
I met this issue too when I want to write something to /dev/graphics/fb0. Yeah, I got this info "/dev/graphics/fb0 no such device" as well.
And then I tried to use "adb reboot recovery" command to come to Recovey mode. (I'm an Android smart phone developer, so I have many test phones.)
I found I can read and write data from/to /dev/graphics/fb0 node in Recovery mode.
Share this information with you guys, hope it's helpful.
Hey guys, I've just decided to get inside of the Android development world. Anyways, I'm mostly a fan of Linux, so I've made my first Linux script, I know it's simple, but I've never interacted with the user before, or picked an output. When I knew that Android made use of Linux in its core, my interest on working inside it grew up faster than ever.
In my script, firstly, you type the filename. For compatibility reasons, it'll everytime save to /sdcard/filename. Then, it will ask you how many times you want the script to log everything, and lately, every how many seconds should it save everything to the file.
The script will save, before every entry at the log, the screen status (if it's on or off), that can help to, for example, if your device has been lagging as a result of a bad screen driver or UI error.
Last thnig: it also works on recovery (maybe it give some error, and if no dumpsys is present on your recovery's ramdisk, it'll save everything as OFF).
Remember to send it anywhere excepting from /storage and any sbudir, it won't work as the Android permissions system blocks script execution on those dirs.
Code:
clear
# Wipe $logfile content in /sdcard (if any existing)
echo "Please type the filename where you want to save the log: "
read -r logfile
echo "" > /sdcard/$logfile
echo "Deleted previous log."
echo "SCREEN | CPU" >> /sdcard/$logfile
#cont=60
cont=1
#SHOWLOG=X
echo "Please type how many times the cycle must repeat: "
read -r maxcont
echo "Please type how many seconds will the interval take: "
read -r maxmin
clear
# Here it counts how many times the logging script has been ran
while [ $cont -lt $((maxcont + 1)) ];
do
# That nested while takes control of how many seconds have passed in the current cycle
while [ "$contmin" -lt "$maxmin" ];
do
contmin=$((contmin + 1))
sleep 1
clear
echo "C: $cont/$maxcont - T: $contmin/$maxmin"
done
# echo "$maxmin seconds passed."
# Logs the fist line of "busybox top" to a var
LOGVAR=$(busybox top -d 1 -n 1 | grep "idle")
# Logs the screen state (on or off) to another var
SCREENSTATE=$(dumpsys input_method | grep mScreenOn | tr -dc '[:alnum:]\n\r' | tr '[:upper:]' '[:lower:]')
# Saves a string that tells what it should expect if the screen is on
SCREENSTATEON="msystemreadytruemscreenontrue"
if [ "$SCREENSTATE" == "$SCREENSTATEON" ]
then
echo "ON: $LOGVAR" >> /sdcard/$logfile
else
echo "OFF: $LOGVAR" >> /sdcard/$logfile
fi
cont=$((cont + 1))
contmin=0
done
echo "Show logged values? [Y/N]"
read -r SHOWLOG
case $SHOWLOG in
[yY] | [yY][Ee][Ss] )
cat /sdcard/$logfile
;;
[nN] | [n|N][O|o] )
echo "Ok, goodbye. You'll see a what you've asked me to log in /sdcard/$logfile";
exit 1
;;
*) echo "You must write Y or N to continue."
;;
esac
exit 0
For example, save it as script.sh (remember to save it using Unix codifcation, if you're running Windows, else, it'll tell you that it's unable to find many binaries, as long as Linux isn't ok with CR+LF and requires LF as newline). Then, send it to the sdcard (over USB or adb push script.sh /sdcard/) , now, run ADB shell. Type the following commands:
Code:
su -c "cp -f /sdcard/script.sh /data/local/;chmod 777 /data/local/script.sh"
Then, if you want to run it:
Code:
su
sh /data/local/script.sh
That's all, I hope you enjoy it and not so many people kills me for explaining and feeling so grateful for that simple script.
Although Aroma installer is great, development on it stopped a while ago and many devices aren't compatible with it. However the ability for selections in an installer hasn't been completely lost. You can use the volume keys to make selections through a couple different methods.
Note that this needs put into a shell script so either you need to have the updater-script call a shell script or use a dummy updater-script and have it in the update-binary
This combines both methods of volume key selection that I've stumbled across.
The one in the choose method is by @Chainfire and is from his VerifiedBootSigner zip.
The one in the chooseold method uses the keycheck binary by someone755. The original idea was by @Zappo here which I modified a bit to not use the timeout binary since it was a bit wonky when I tested it and to work with any volume key setup. I think the keycheck binary is arm compiled but not sure.
First thing that happens though is that it attempts to get the selection from the zip name. The user can add new or old to the zip (make sure there are no spaces) and skip the whole volume key thing (useful if neither vol key method works on their device - note that this won't work with tools like magisk manager which rename the zip to "install.zip" when flashing).
Second is that the keytest function is run. This is by me tests the chainfire method. One of his comments is that his method needs to be tested with older versions of android and sure enough, it doesn't work properly on many. So the keytest function tests the chainfire method and checks for an error. If there is no error, the installer will use the choose (chainfire) method. If there is an error, it'll use the chooseold (keycheck) method. I favor chainfire's because it's not reliant on a 3rd part binary that may not work with x86 and other devices with unusual cpu architectures
Third, the selection process is run. If using choose, the user makes their selection and the installer continues. If using chooseold, the installer will prompt the user to enter volume up, then volume down. This "programs" the vol keys for that device since it may vary between devices. Then the user makes their selection and the installer moves on.
Here's the code. At the bottom of it are 2 comments where you can put your stuff you want to have happen depending on the selection.
Code:
# Get option from zip name if applicable
case $(basename $ZIP) in
*new*|*New*|*NEW*) NEW=true;;
*old*|*Old*|*OLD*) NEW=false;;
esac
# Change this path to wherever the keycheck binary is located in your installer
KEYCHECK=$INSTALLER/keycheck
chmod 755 $KEYCHECK
keytest() {
ui_print "- Vol Key Test -"
ui_print " Press a Vol Key:"
(/system/bin/getevent -lc 1 2>&1 | /system/bin/grep VOLUME | /system/bin/grep " DOWN" > $INSTALLER/events) || return 1
return 0
}
choose() {
#note from chainfire @xda-developers: getevent behaves weird when piped, and busybox grep likes that even less than toolbox/toybox grep
while true; do
/system/bin/getevent -lc 1 2>&1 | /system/bin/grep VOLUME | /system/bin/grep " DOWN" > $INSTALLER/events
if (`cat $INSTALLER/events 2>/dev/null | /system/bin/grep VOLUME >/dev/null`); then
break
fi
done
if (`cat $INSTALLER/events 2>/dev/null | /system/bin/grep VOLUMEUP >/dev/null`); then
return 0
else
return 1
fi
}
chooseold() {
# Calling it first time detects previous input. Calling it second time will do what we want
$KEYCHECK
$KEYCHECK
SEL=$?
if [ "$1" == "UP" ]; then
UP=$SEL
elif [ "$1" == "DOWN" ]; then
DOWN=$SEL
elif [ $SEL -eq $UP ]; then
return 0
elif [ $SEL -eq $DOWN ]; then
return 1
else
ui_print " Vol key not detected!"
abort " Use name change method in TWRP"
fi
}
ui_print " "
if [ -z $NEW ]; then
if keytest; then
FUNCTION=choose
else
FUNCTION=chooseold
ui_print " ! Legacy device detected! Using old keycheck method"
ui_print " "
ui_print "- Vol Key Programming -"
ui_print " Press Vol Up Again:"
$FUNCTION "UP"
ui_print " Press Vol Down"
$FUNCTION "DOWN"
fi
ui_print " "
ui_print "- Select Option -"
ui_print " Choose which option you want installed:"
ui_print " Vol Up = New, Vol Down = Old"
if $FUNCTION; then
NEW=true
else
NEW=false
fi
else
ui_print " Option specified in zipname!"
fi
if $NEW; then
# insert stuff for new here
else
# insert stuff for old here
fi
Attached is the keycheck binary. The original source of it is here along with the timeout binary if you want to give that a go
If you want to have more than 2 selections, you can just add more selections by adding conditionals and calling $FUNCTION again. The V4A mod I help with here is a good example of this
If you have a device with a bixby button and want to use it or you have awk bundled in your installer and/or on target device (it's a part of busybox) and want to use an alternative getevent method, check out this post. Big thanks to @ianmacd
If you know of any other methods or of any improvements (since much of this is kind of hacky), let me know! I'll add it here :fingers-crossed:
Hey @Zackptg5, Ive been making a module that is kinda based entirely around this Volume key thing, not gonna give anything away just yet, but it requires a lot of choices to be made using the volume keys. Based on what the script above shows, the key inputs are tested for everytime you want to get an input, with the keytest function, then the choose port function is decided on that.
From the above code, for my device, the keytest would recognise the newer method and do that one the first time around, but whenever an input is required a second time, it would revert to the legacy ,ethod. Time consuming. So what I did was store tje exit status of the keytest function as a variable keytest_status, and always make a check against that variable whenever an input is needed.
For those with a modern keytest method, this would solve the function reverting to the legacy one. Check the attached file for a better description. I'm still working away so if i find anything else I'll let you know:good:
Also added a couple functions for size benefits etc
Sent from my OnePlus5T using XDA Labs
OldMid said:
Hey @Zackptg5, Ive been making a module that is kinda based entirely around this Volume key thing, not gonna give anything away just yet, but it requires a lot of choices to be made using the volume keys. Based on what the script above shows, the key inputs are tested for everytime you want to get an input, with the keytest function, then the choose port function is decided on that.
From the above code, for my device, the keytest would recognise the newer method and do that one the first time around, but whenever an input is required a second time, it would revert to the legacy ,ethod. Time consuming. So what I did was store tje exit status of the keytest function as a variable keytest_status, and always make a check against that variable whenever an input is needed.
For those with a modern keytest method, this would solve the function reverting to the legacy one. Check the attached file for a better description. I'm still working away so if i find anything else I'll let you know:good:
Also added a couple functions for size benefits etc
Sent from my OnePlus5T using XDA Labs
Click to expand...
Click to collapse
Not quite sure what you mean but the keytest function is only run once when the script is initially run to determine whether the new or old choose function should be used. It also looks like you based yours on v4a (the one in the OP here has been reworked a bit to make it easier/more efficient). Also changed it up a bit to make it easier for you, let me know if this does what you want
Zackptg5 said:
Not quite sure what you mean but the keytest function is only run once when the script is initially run to determine whether the new or old choose function should be used. It also looks like you based yours on v4a (the one in the OP here has been reworked a bit to make it easier/more efficient). Also changed it up a bit to make it easier for you, let me know if this does what you want
Click to expand...
Click to collapse
No attachement:laugh: What I meant was that it would to the legacy key programming function every second time an input was needed, and the normal one every first time.
It would:
Initial key programming
detect modern version and continue
if an input is required it would switch back to legacy method
switch back to modern when another input is needed
switch back to legacy again
repeat until no more inputs are needed and script is finished running. But this may also be because I'm using the old logic:silly:
Sent from my OnePlus5T using XDA Labs
OldMid said:
No attachement:laugh: What I meant was that it would to the legacy key programming function every second time an input was needed, and the normal one every first time.
It would:
Initial key programming
detect modern version and continue
if an input is required it would switch back to legacy method
switch back to modern when another input is needed
switch back to legacy again
repeat until no more inputs are needed and script is finished running. But this may also be because I'm using the old logic:silly:
Sent from my OnePlus5T using XDA Labs
Click to expand...
Click to collapse
Oh, that may be because of the old logic. Does that happen with the one I attached on the last post?
Zackptg5 said:
Oh, that may be because of the old logic. Does that happen with the one I attached on the last post?
Click to expand...
Click to collapse
I don't see anything attached
Sent from my OnePlus5T using XDA Labs
OldMid said:
I don't see anything attached
Sent from my OnePlus5T using XDA Labs
Click to expand...
Click to collapse
Sorry, forgot that xda doesn't like .sh files
Zackptg5 said:
Sorry, forgot that xda doesn't like .sh files
Click to expand...
Click to collapse
Yeah it fixes it:good:
Sent from my OnePlus5T using XDA Labs
HMMM... It doesn't work for me. I am trying to create a ZIP file to do some updates into the system requiring basic A/B selections. I am trying to implement this in a basic TWRP ZIP module. Have you managed to include it in a flashable ZIP file without Magisk? I could adapt V4A FX installer, but I don't want this to be a Unity module since it doesn't install anything. For some reason removing that unity thing is creating all the problem. Any clue?
Oki said:
HMMM... It doesn't work for me. I am trying to create a ZIP file to do some updates into the system requiring basic A/B selections. I am trying to implement this in a basic TWRP ZIP module. Have you managed to include it in a flashable ZIP file without Magisk? I could adapt V4A FX installer, but I don't want this to be a Unity module since it doesn't install anything. For some reason removing that unity thing is creating all the problem. Any clue?
Click to expand...
Click to collapse
I'll need to see it to find what the problem is. You can pm me if you don't want it public yet
Zackptg5 said:
I'll need to see it to find what the problem is. You can pm me if you don't want it public yet
Click to expand...
Click to collapse
I solved it using only the keycheck program. getevent was not working fine for me. You can download and inspect my code here.
This is my version:
Code:
#!/sbin/sh
ui_print() {
echo -n -e "ui_print $1\n" > /proc/self/fd/$OUTFD
echo -n -e "ui_print\n" > /proc/self/fd/$OUTFD
}
keytest() {
$KEYCHECK
KEYCODE=$?
if [ "$KEYCODE" = 42 ] ; then
return 0
else
return 1
fi
}
customkey() {
# Calling it first time detects previous input. Calling it second time will do what we want
$KEYCHECK
#$KEYCHECK
SEL=$?
if [ "$1" == "UP" ]; then
UP=$SEL
elif [ "$1" == "DOWN" ]; then
DOWN=$SEL
elif [ $SEL -eq $UP ]; then
return 0
elif [ $SEL -eq $DOWN ]; then
return 1
else
ui_print " Vol key not detected!"
abort " Use name change method in TWRP"
fi
}
##### THE PARTY STARTS HERE ########
# INITIAL CLEANUP
cd /tmp
rm -rf $INSTALLER 2>/dev/null
mkdir -p $INSTALLER
# extract files
ui_print "Extracting files."
cd $INSTALLER
unzip -o "$ZIP"
chmod 777 $KEYCHECK
ui_print " "
ui_print " #########################################"
ui_print " PROGRAM NAME"
ui_print " #########################################"
ui_print " "
ui_print " Welcome message"
ui_print " "
ui_print " Press Vol Up to continue..."
if keytest; then
FUNCTION=keytest
else
FUNCTION=customkey
ui_print " - Device detected! but using custom key method"
ui_print " "
ui_print " - Vol Key Programming -"
ui_print " Press Vol Up Again..."
$FUNCTION "UP"
ui_print " Press Vol Down..."
$FUNCTION "DOWN"
fi
# QUESTION 1 ##########
ui_print " - Continue?"
ui_print " Vol UP = YES, Vol DN = NO"
if ! $FUNCTION ; then
ui_print " "
ui_print " - Loser...."
exit 0
fi
# QUESTION 2 ##########
ui_print " "
ui_print " - Do you like this script?"
ui_print " Vol UP: YES / Vol DN: NO"
if $FUNCTION ; then
ui_print " - THANKS!!!!!"
else
ui_print " - I'm so sorry."
fi
# MORE QUESTIONS... ##########
Thanks!
Oki said:
I solved it using only the keycheck program. getevent was not working fine for me. You can download and inspect my code here.
This is my version:
Code:
#!/sbin/sh
ui_print() {
echo -n -e "ui_print $1\n" > /proc/self/fd/$OUTFD
echo -n -e "ui_print\n" > /proc/self/fd/$OUTFD
}
keytest() {
$KEYCHECK
KEYCODE=$?
if [ "$KEYCODE" = 42 ] ; then
return 0
else
return 1
fi
}
customkey() {
# Calling it first time detects previous input. Calling it second time will do what we want
$KEYCHECK
#$KEYCHECK
SEL=$?
if [ "$1" == "UP" ]; then
UP=$SEL
elif [ "$1" == "DOWN" ]; then
DOWN=$SEL
elif [ $SEL -eq $UP ]; then
return 0
elif [ $SEL -eq $DOWN ]; then
return 1
else
ui_print " Vol key not detected!"
abort " Use name change method in TWRP"
fi
}
##### THE PARTY STARTS HERE ########
# INITIAL CLEANUP
cd /tmp
rm -rf $INSTALLER 2>/dev/null
mkdir -p $INSTALLER
# extract files
ui_print "Extracting files."
cd $INSTALLER
unzip -o "$ZIP"
chmod 777 $KEYCHECK
ui_print " "
ui_print " #########################################"
ui_print " PROGRAM NAME"
ui_print " #########################################"
ui_print " "
ui_print " Welcome message"
ui_print " "
ui_print " Press Vol Up to continue..."
if keytest; then
FUNCTION=keytest
else
FUNCTION=customkey
ui_print " - Device detected! but using custom key method"
ui_print " "
ui_print " - Vol Key Programming -"
ui_print " Press Vol Up Again..."
$FUNCTION "UP"
ui_print " Press Vol Down..."
$FUNCTION "DOWN"
fi
# QUESTION 1 ##########
ui_print " - Continue?"
ui_print " Vol UP = YES, Vol DN = NO"
if ! $FUNCTION ; then
ui_print " "
ui_print " - Loser...."
exit 0
fi
# QUESTION 2 ##########
ui_print " "
ui_print " - Do you like this script?"
ui_print " Vol UP: YES / Vol DN: NO"
if $FUNCTION ; then
ui_print " - THANKS!!!!!"
else
ui_print " - I'm so sorry."
fi
# MORE QUESTIONS... ##########
Thanks!
Click to expand...
Click to collapse
I prefer the getevent one because it doesn't involve any binaries but it is more finicky than the keycheck method. Since your mod is for arm devices, keycheck should be fine. The keytest stuff all looks good except that in the keytest function, you probably would want it to be
Code:
if [ $KEYCODE -eq 42 ]; then
since it's integer comparison. You could keep as string the way you have it but you would need a '==' rather than a '='
Also, the keytest function doesn't program volume down key at all (it's typically 21). I just always use the custom key logic just in case there's that one weird device
Zackptg5 said:
I prefer the getevent one because it doesn't involve any binaries but it is more finicky than the keycheck method. Since your mod is for arm devices, keycheck should be fine. The keytest stuff all looks good except that in the keytest function, you probably would want it to be
Code:
if [ $KEYCODE -eq 42 ]; then
since it's integer comparison. You could keep as string the way you have it but you would need a '==' rather than a '='
Also, the keytest function doesn't program volume down key at all (it's typically 21). I just always use the custom key logic just in case there's that one weird device
Click to expand...
Click to collapse
I totally agree. I don't want to load the TWRP Zip with unnecessary tools. My problem was that for some reason the getevent method was colliding with some libraries in the implementation for my device, an Axon 7. So I decided to go this way. I would like to convert it to pure getevent method.
Regarding the comparison, you are right, I will have to change that. The link is the very first working version of the tool and there is a lot of code cleanup required. The tool I have developed is a TWRP Zip module that splits a vendor partition from system or userdata, so developers could create treblerized roms for legacy devices. I have an Axon 7, released with Android M, and we have now unofficial Android P, LOS 16.0 and a couple of treble roms supporting a lot of GSI. My objective is to make it as general and compatible as I could.
Thanks Again!
Zackptg5 said:
You could keep as string the way you have it but you would need a '==' rather than a '='
Click to expand...
Click to collapse
Actually, a single '=' is fine for string comparison, and is actually the only string comparison operator accepted by the [ and test commands of POSIX-compliant shells.
ianmacd said:
Actually, a single '=' is fine for string comparison, and is actually the only string comparison operator accepted by the [ and test commands of POSIX-compliant shells.
Click to expand...
Click to collapse
Thanks for the correction, guess a single '=' could work. However, Android shell isn't posix compliant. It's its own beast :/
Zackptg5 said:
Thanks for the correction, guess a single '=' could work. However, Android shell isn't posix compliant. It's its own beast :/
Click to expand...
Click to collapse
The Android shell nowadays is mksh, and yes, you're right, it isn't terribly POSIX-compliant, even when started with -o posix.
Just be aware that the '==' comparison operator doesn't work in some shells in combination with single brackets, whereas the single '=' always will. zsh, for example:
Code:
$ zsh -c '[ x = y ]'
$ zsh -c '[ x == y ]'
zsh:1: = not found
The single '=' predates '==' by quite a margin. The double '==' is best reserved for the double bracket command: [[
Anyway, I don't want to go too far off-topic. It's just that shells are an area of particular interest to me.
Thanks for starting this thread, by the way. I now user a modified version of this code in the installer of my S9/S9+ kernel, APGK, to allow the user to interactively select certain features at install-time. The only gotcha is that I have to manually mount /system to gain access to the getevent binary.
I prefer to pipe the output through awk and output only the penultimate field:
Code:
local key=$( getevent -lqc 1 | awk '{ print $(NF-1) }' )
And since the S9/S9+ also has a Bixby button, I add a line of code to return something more legible than the raw keycode when this is pressed:
Code:
[ $key = 02bf ] && key=KEY_BIXBY
Perhaps these details will be of some use to someone.
ianmacd said:
The Android shell nowadays is mksh, and yes, you're right, it isn't terribly POSIX-compliant, even when started with -o posix.
Just be aware that the '==' comparison operator doesn't work in some shells in combination with single brackets, whereas the single '=' always will. zsh, for example:
Code:
$ zsh -c '[ x = y ]'
$ zsh -c '[ x == y ]'
zsh:1: = not found
The single '=' predates '==' by quite a margin. The double '==' is best reserved for the double bracket command: [[
Anyway, I don't want to go too far off-topic. It's just that shells are an area of particular interest to me.
Thanks for starting this thread, by the way. I now user a modified version of this code in the installer of my S9/S9+ kernel, APGK, to allow the user to interactively select certain features at install-time. The only gotcha is that I have to manually mount /system to gain access to the getevent binary.
I prefer to pipe the output through awk and output only the penultimate field:
Code:
local key=$( getevent -lqc 1 | awk '{ print $(NF-1) }' )
And since the S9/S9+ also has a Bixby button, I add a line of code to return something more legible than the raw keycode when this is pressed:
Code:
[ $key = 02bf ] && key=KEY_BIXBY
Perhaps these details will be of some use to someone.
Click to expand...
Click to collapse
Good to know. I link this to the OP, thanks!
Sorry to revive an old thread but I need some help guys. I'm converting GSI's to flashable zips and for my custom stock rom installation, I want Xposed to be installed with Vol+ and not installed(updater-script continues) with Vol-. Also, i'll be using just the old method with keycheck. Any pointers on how I would accomplish that? Thanks much
Del
Optimization details:
Added double quotes around variables to handle potential issues with spaces in filenames.
Replaced the use of backticks with the $(command) syntax for command substitution.
Used the -q option with grep to suppress output and replaced /dev/null redirection.
Removed unnecessary calls to cat.
Simplified comparisons by directly using the variable values.
Removed redundant blank lines and unnecessary ui_print statements.
Bash:
# Get option from zip name if applicable
case $(basename "$ZIP") in
*[nN][eE][wW]*) NEW=true;;
*[oO][lL][dD]*) NEW=false;;
esac
# Change this path to wherever the keycheck binary is located in your installer
KEYCHECK="$INSTALLER/keycheck"
chmod 755 "$KEYCHECK"
keytest() {
ui_print "- Vol Key Test -"
ui_print " Press a Vol Key:"
/system/bin/getevent -lc 1 2>&1 | /system/bin/grep -q "VOLUME.* DOWN" > "$INSTALLER/events"
return $?
}
choose() {
ui_print "- Vol Key Programming -"
ui_print " Press Vol Up Again:"
$KEYCHECK
$KEYCHECK
SEL=$?
if [ "$1" == "UP" ]; then
UP=$SEL
elif [ "$1" == "DOWN" ]; then
DOWN=$SEL
elif [ "$SEL" -eq "$UP" ]; then
return 0
elif [ "$SEL" -eq "$DOWN" ]; then
return 1
else
ui_print " Vol key not detected!"
abort " Use name change method in TWRP"
fi
}
ui_print " "
if [ -z "$NEW" ]; then
if keytest; then
FUNCTION=choose
else
FUNCTION=chooseold
ui_print " ! Legacy device detected! Using old keycheck method"
ui_print " "
$FUNCTION "UP"
$FUNCTION "DOWN"
fi
ui_print " "
ui_print "- Select Option -"
ui_print " Choose which option you want installed:"
ui_print " Vol Up = New, Vol Down = Old"
if $FUNCTION; then
NEW=true
else
NEW=false
fi
else
ui_print " Option specified in zipname!"
fi
ui_print " "
if "$NEW"; then
# insert stuff for new here
else
# insert stuff for old here
fi
This is untested but since i am investigating into a new AROMA Replacement this might be interesting as alternative. I will play around with it later...