Hello. I'm having a problem keeping scripts running (in background) through ADB on my non-rooted Mate 10 after the phone has been unplugged.
I've tried to use the nohup command which has always worked out for me before with other Android devices, to no avail. I know that nohup only protects from SIGHUP and SIGQUIT signals and so the device might be sending a different signal to kill the process. I have also tried spawning a child task to try to 'hide' the spawned process and /system/bin/sh to spawn a shell within a shell which have both also failed.
My only theory as to why this is happening is that the device wants to optimize power usage and therefore kills all backgrounded processes that are not apps..
Does anyone have some ideas on how to solve this issue?
I think with this phone behaviour, you might need to root it to gain such privillege
Related
I am using sgs with miuiv4 by andy,
the media storage got duplicated every boot,
i have an idea that every time clear media storage's data at boot before scanner action.
i tried to use init.d with an script i created in /data/local/userinit.sh
i tried
pm clear com.android.providers.media,
it works in adb, but when i try it in terminal emulator, it keep showing me "segmentation fail"
any idea to achieve this tweak, i am just a newbie. help
I am trying to do the same thing, except I put it into GScript.
Also segmentation fault.
Anyone has any ideas?
i have bought an i9100... so... say bye to my i9000~
Does anyone have a solution to this problem?
I'm having the same problem.
Running "pm clear" by adb shell works normally.
But when I run via "sh script.sh" does not work.
It seems that running does not find the package.
If I include in the script command "pm list packages com.myapp" nothing is returned.
I'm trying to get a script to launch. I've done quite a bit of research; nothing I've found has proved very useful. I'm trying to do this on a Galaxy S3 with Cyanogenmod 10.2 Stable. Since it looks like this is a neglected issue on XDA, I'll also reference the other posts which I've read.
Running it as root at startup with SManager works, but I would really prefer to bypass a 3rd-party app.
My script doesn't seem to be loading at boot; it should create a PID file in my /sdcard folder, but it doesn't. Without knowing the PID, I have no way of verifying whether or not it's even running.
Code:
#!/system/bin/sh
(while [it's a never-ending loop]...do [stuff]; busybox sleep 900s...done) & echo $! > /sdcard/myscript.pid &
I've tried a couple different ways of calling this script from init.rc:
Code:
on boot
sh /system/bin/myscript.sh
and
Code:
service myscript(*I also tried "myscript_boot") /system/bin/myscript.sh
user root (*also tried it without the user command)
oneshot (*and without oneshot)
I also find it strange that my changes to init.rc are persistent after reboot since many, many articles suggest that it should be reset after reboot (I've noticed that many of these articles date back to ~2010).
Since I can't find any conclusive documentation on this issue. I hope someone here can shed some insight.
# Editing init.rc
http://forum.xda-developers.com/showthread.php?t=2069928
# Tried following this article to edit/flash the boot image, but I don't have "/proc/mtd"
http://droidcore.blogspot.com/2012/12/how-to-edit-initrc-in-android.html
# A neglected post very similar to mine
http://forum.xda-developers.com/showthread.php?t=1894607
# Another neglected post which addresses this issue
http://forum.xda-developers.com/xperia-u/issues/xperia-cm9-unable-to-launch-script-init-t2089749
One more thing. My script runs fine if I issue the command in the Terminal emulator, adb shell, and, as mentioned earlier, if launched with SManager. It's only init.rc that's giving me issues.
Although I've made fundamental protection in the Xposed module of Greenify (especially in 2.6 beta 10), some of you are still experiencing bootloop if experimental Xposed-based features are activated.
It's really hard to dig these issue without logcat since Android devices and ROMs are highly diverse (fragmented). But logcat in the bootloop case is understandable harder to capture than regular crash issues.
If you are one of the bootloop victims, and would like to help me on this issue. Please follow this instructions to capture a proper logcat for the bootloop issue:
1. Download and install ADB tool, either as standalone package or from the Android SDK.
2. Connect your device with a PC or laptop with USB cable.
3. Enable developer options on your device. (this must be done before the bootloop happens)
4. Test logcat capturing by typing this command in shell (or command prompt): "adb logcat -v time -d" (without quote marks), if you see plenty of log scrolling through the screen and finished, it's ready.
5. Trigger the bootloop, then after the device reboot, type this command in shell: "adb logcat -v time > logcat.txt", if you read "waiting for device" and the command continues running, that's OK.
6. Wait until the last command to finish and return to the shell, then you will get a "logcat.txt" file in the current path (usually the root path of your user home / folder). Send it to me via email (or pastebin.com).
If the command does not finish in a long time, just press "Ctrl + C" to end it, and send me the logcat.txt if it's not empty.
Thanks very much for your effort to help diagnosing this issue.
I had some severe boot loops on a CM12 device last night, I think it was just soft reboots not hard (no way to confirm it, sorry). It was running in root mode. I think a play store update cured that one. The SuperSU logs confirmed it was the item requesting access just before soft reboot.
I also had severe soft boot loops on my Moto X OTA 4.4.4, running in boost mode. Updating from play store (to 2.6.1), or disabling the xposed module auth for Greenify would not fix it. Only blocking SuperSU access fixed it. I just verified that granting SU back again to Greenify immediately causes soft boot loop.
Unfortunately, the effected device is a work unit with sensitive information, so I cannot post anything. I can try limited requests if you have any.
Waking a hibernated system app (Spotlight Player) caused a soft reboot, but it appears its working properly now going back into hib and back.
Dear users,
I read multiple threads throughout internet and couldn't find working solution. My lg with kitkat 4.4.2 had lagged so I removed battery. After this phone is boot-looping with startup animation forever.
I can explore files with adb shell when phone is in recovery mode but don't have access to dalvik-cache. Command "su rm -rf /system/data/dalvik-cache" gives "permission denied nor "adb backup -all" cause "unlock your device and confirm...".
I cannot root phone by copying SuperSu files into /system/app. The command "su cp.. " gives no answer and later when exploring /app there's no SuperSu program.
I was trying to explore through sudo nautilus on Ubuntu during using one of rooting tutorial but the phone just disappears in the list of mounted devices.
I have important data like phone contacts, messages and some pictures inside phone memory. I didn't backup all of them formerly.
Any ideas?
likkufri said:
Dear users,
I read multiple threads throughout internet and couldn't find working solution. My lg with kitkat 4.4.2 had lagged so I removed battery. After this phone is boot-looping with startup animation forever.
I can explore files with adb shell when phone is in recovery mode but don't have access to dalvik-cache. Command "su rm -rf /system/data/dalvik-cache" gives "permission denied nor "adb backup -all" cause "unlock your device and confirm...".
I cannot root phone by copying SuperSu files into /system/app. The command "su cp.. " gives no answer and later when exploring /app there's no SuperSu program.
I was trying to explore through sudo nautilus on Ubuntu during using one of rooting tutorial but the phone just disappears in the list of mounted devices.
I have important data like phone contacts, messages and some pictures inside phone memory. I didn't backup all of them formerly.
Any ideas?
Click to expand...
Click to collapse
Could you elaborate on "disappears?" Usually if something is present and suddenly disappears in lubuntu, that means the connection was broken (either physically or by software, such as when switching drivers by running a command). Anyway, have you tried letting it sit for a day or something? I figure the reason it "lags" might potentially affect booting time.
It's also helpful to know what data you want out of it. Some things need root, some things don't need root. If all you want is file X in user space, I imagine that'd be infinitely easier than trying to get a random bootloader setting.
Ok lets first explain the situation
I've been dabbling with Tasker (Paid for version)- getting some automation depending on certain situations (mainly stuff like 'If I'm @ {location} get volumes set high' or ' If Unread msg then vibrate my Amazefit bip watch' - Nothing too complicated using variables / javascript etc)
One situation I want to attempt though is 'If Gpay app is started - turn on NFC, but when I leave the app - turn NFC off'
Now I already know there are 2 'main' ways I can turn on/off NFC in Tasker.. either use 'AutoInput plugin' or use 'Secure Settings'
- I've tried with Autoinput plugin but the problem is that with the free option, you need to watch an Ad every day to use it but of course I can pay for it (its only a couple of quid)
However you can't Install it & pay for it directly from within the plugin - you need to install yet another App (AutoApps) first - & although this one is free - I just don't like adding more bloat to my phone than necessary. Adding both the plugin & this additional App adds (although only a 'minor' amount) up to 20Mb
The other method is give Tasker 'Secure settings' permission
- So I read the 'What to do to give 'Write Secure Settings Permission' to Tasker' (enable Developer mode > Usb Debugging > Install ADB on PC etc etc) & it looks simple enough,
But (a loooong time ago) I tried other 'hacks' & it ended up disastrously (probably I did something wrong with missing a step or something) & I just want to make sure that it IS as simple as it seems and also ask how safe is it
for example
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Any help/advice would be appreciated
Cannon_Foddr said:
* If I type in the command in ADB - could something go wrong & could it crash/brick the phone ?
* Is this permanent - ie if I turn off/on phone or if I get an OTA update & phone restarts - will it stay, or will I have to repeat the ADB command each time ?
* Will this 'break' official OTA updates (whether security &/or Android firmware) - I once did a firmware update with a step that used ADB (IIRC) & it broke something that prevented any updates from happening
- official OR manual firmware updates
Click to expand...
Click to collapse
ADB is the door to your phone's Android. It's a tool not meant to be used by John Doe. Wrongly used you can brick your phone. Hence it's by default disabled.
1. Yes, using ADB you can render your phone absolutely useless. If you e.g. enter
Code:
adb shell rm -rf /
then phone gets totally wiped ( really all gets destroyed, it gets naked ) - you can throw it into electric waste.
2. ADB commands aren't persistent, but their results may be.
3. ADB itself breaks nothing: it's a driver installed on your computer that let you access Android's files and launch Android executables.
Thanks for the reply
I doubt I'll use THAT command.
I forgot to mention what tasker's command is
adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS
Not 100% sure about your last comment though.
ADB allows access to android files so changing android files could break things, which I'm worried about especially with OTA updates etc. (my last phone stopped getting OTA updates when I rooted it despite using official firmware)
However IF I understand the above command all this does is tell the android operating system ('android') to only give the tasker app (which 'Real' name is 'net.dinglisch.android.taskerm') the rights ('permission') to access the required settings ('WRITE_SECURE_SETTINGS') which the NFC on/off toggle is part of (settings >connected devices > connection preferences> nfc) & 'shouldn' t' affect any other files such as OTA (unless OTA is also part of secure setting?)
@Cannon_Foddr
As I can see you until now haven't understood what ADB is, how it works.
Same probably your understanding of what an OTA is.
Personally never would allow 3rd-party apps ( like Tasker ) to modify sensible system settings: Tasker isn't an open-source app, so you can't control what it does in the last run.
It's simply on you to decide whether Tasker is given that right, or not ...
Can't see why 'open-source' has to do with this
IMHO if Open-source - anyone can release similar apps with added extra hidden code that could spy's on you/steal info etc, but a 'closed sourced' app from a long running developer (tasker been around for 10yrs with over 1mil downloads) must mean people seem to trust him/them & if he was 'dodgy' surely he would've been caught out by now
Anyway the Bottom line seems to be
Safe route: pay for plugin & live with extra bloatware
Or
Risky route: give access to secure system resources, see what happens & keep fingers cross nothing does
Thanks for your replies.. I think I may have to sit down & have a long hard think which route I feel more comfortable with
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
DennisHarrows said:
I have been using Automate for about 4 months now. I granted it WRITE_SECURE_SETTINGS and I have not noticed any modifications in my system. Granted I may have not looked specifically for them but as far as braking the system or disruption of OTAs no issues so far
Click to expand...
Click to collapse
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Cannon_Foddr said:
I assume you had to do something like Taskers command then to grant the secure settings
( "adb shell pm grant net.dinglisch.android.taskerm android.permission.WRITE_SECURE_SETTINGS" )
Click to expand...
Click to collapse
Automate is straight forward, there is a toggle for "modify system settings" needed for some tasks to run and one you run the ADB command, it's done