Developing a daemon for jailbroken iDevices.
It's supposed to run when the iPhone is locked. However, the process seems to be put on hold after a little under a minute when the iPhone is locked (as seen by considering the "Total Process Running Time" given by CocoaTop). How can I prevent this, and make the daemon run all the time?
I'm sure this is possible, since when the phone is charging (plugged in) the daemon is not paused, and I see it working.
Wrapped the main method of the daemon in what's described here under Listing 2
Related
It seems like older versions of iOS allowed your app to run for 10 minutes in the background. Now it seems like iOS only allows your app to run for a maximum of 3 minutes. I haven't found any documentation mentioning when, or in which versions, this changed, or any estimates provided by Apple for how long your app can run in the background.
I need to be able to run in the background, because my app is connected to an external device via TCP. I already know about the hacks you can do with VOIP and playing silent audio (both will get your app rejected).
Is there anything I can do to get my app to keep running in the background longer than 3 minutes?
We haven’t had the old 10 minute window for years so that is simply no longer applicable. That was reduced to 3 minutes in OS 7, and further reduced to 30 seconds in iOS 13. (There is a new concept of background tasks, for running tasks longer than 30 seconds, but the the OS will run these at its own discretion, e.g. at night, when the user is charging their device, so that’s not really applicable here).
The short answer to your question is that you cannot submit apps to the store that run in the background indefinitely unless it’s one of a very limited list of permitted background modes.
If you can go to the “Signing & Capabilities” tab of your target and add “Background Modes” and you can see the list of alternatives:
So, with the caveat that you cannot do precisely what you asked, here are a few observations:
The “External accessory communication” background mode (see ExternalAccessory) seems promising, but that’s for bluetooth or wired connections only. So unless you can refactor/reengineer how your devices communicates, that is likely not a viable solution.
There’s an interesting question of whether just keeping the app running in the foreground might be helpful (e.g. judicious use of idleTimerDisabled). I know this solves a different problem (and should be used only where essential), but perhaps it’s option for you.
If your external device is Internet-enabled and you want it to inform the app of some event, perhaps you can have it communicate its intent to some web service that then triggers an APNS push notification that your device can receive.
Bottom line, you can’t do what you ask, but if you edit your question with more details about the nature of the device and what your iOS app wants to do with that device, we might be able to provide better counsel. But in answer to the general question “can I just keep app running perpetually in the background”, the answer is “no.”
I am testing the behavior of my app concerning the enforced timeout of iOS which stops any app at latest 3 minutes after it has been killed by the user. It is very tedious to wait for this timeout whenever I want to check my functionality. Does anybody know if it is possible to reduce this timeout for testing purposes?
[Edit]
To sum up the comments below: I am trying to make my app run forever in background as described here and also be able to be reanimated after the user or iOS has killed it. In order to check this, I actually have to kill the app, let it be reanimated, and then see if it survives the 3-minute time limit of iOS.
My current "test cycle" is:
1) Deploying the app
2) Killing it manually with double-click and swiping it away
3) Activating flight mode
4) Deactivating flight mode (to force a significant location change which restarts the app)
5) Waiting for three minutes to see if the app survives.
How would I shorten the 3-minute timeout of step 5?
I'm trying to start a device using Genymotion GMTool from Jenkins by executing a batch command: "gmtool admin start $devicename" and the device does start
The problem is that as soon as the build ends, the device disappears from the screen copletely though is still visible in ADB.
Also, if i execute the same gmtool command from the windows cli the device stays on the screen.
Anyone knows what may cause this issue?
It's maybe because Jenkins process will kill all its childs and also the Genymotion device window running after the slave's job finished. But the problem here is that your Genymotion device is composed by a window (called "player") displaying the device and a headless virtual box process running the Android OS (including the ADB deamon).
If the device player is hardly killed, the vbox process will not be powered off at the same time. That's the reason why you still see the device connected to adb.
You can check this idea is true by checking on your running processes if you have a vbox headless process remaining after the window disappeared.
The solution could be:
to use another way to launch your devices (with a cron task for example).
to check if it is possible to set something on Jenkins to avoid this problem
to start a new device for each test run
I have a jailbreak application that needs to run as root, so at the beginning of the main function, I call setuid(0); The problem arises when I want to terminate the application through the task switcher. I remove it from the multitask bar, but it continues to run in he background. Does anybody know how to fix this? I know "iFile" had this problem for a while.
The problem you have is actually pretty simple.
SpringBoard and therefore the Multitasking Bar runs as the user mobile while your app runs as root. The mobile user can't kill a process that runs as root.
My first idea to resolve this is to hook (MobileSubstrate) into the multitasking bar and since MS tweaks can run as root, detect when the user kills your app and kill it yourself as the root user because SpringBoard simply can't do it.
Or if this doesn't solve it, ask the guy who made iFile, he is really helpful, I'm sure he will give you some guidance with this problem.
I would recommend investigating exactly how you've achieved root privilege escalation, and is it built as a normal UIApplication, and installed in /Applications/?
I don't think this should be preventing you from killing the app. Take a look at the Cydia app itself, which also runs as root.
I can kill Cydia with no problems via the task switcher (verified afterwards with the ps command).
If you log into a jailbroken phone, take a look at:
/Applications/Cydia.app/Cydia
/Applications/Cydia.app/MobileCydia
I believe the technique is well described here. Otherwise, you may need to post more information about how you've coded your app.
When testing a VOIP or a background fetch application, testing against background termination and launch is vital to see if the desired outcome is achieved. Right now, launching 28 applications including five games doesn't show any applications being killed due to memory hogs. The five games are NBA GM, CEASAR SLOTS, STELLA WARS, CRASH DRIVE 2, WATER 2.
What needs to be checked is, if any applications get killed on low memory conditions. Any ideas on triggering that kind of condition?
(VOIP apps won't be killed if the socket is active, but why aren't any applications getting killed?)
If your goal is to test how the app recovers from sudden termination (as opposed to how it handles the termination) then the easiest way to kill the app is to stop the debugging session with xcode.
Just Build And Run while the app is running, and you get an instant recovery test.