For an unknown reason, when I kill my app in the recent menu and try to launch it again, the last screen where I was appear again and the device is frozen. What I have to do is a hard reboot and after that, launching the app again work...
Alternatively, if I want to relaunch my app after the kill in recent without a reboot, I have to type this command in mobile Terminal
killall myapp
and after this, if I try to launch my app from homescreen, my app is working correctly...
What I wanted to know is how could I detect when the user exit the app with the home button and thereby launch an NSTask that send killall command ? I know NSTask is not allowed by Apple but this is a jailbreak app that is not intended to be published on Apple Store.
Also this bug really bored me... in viewDidLoad I've several NSTask and method that check if directory exist. Do you think that these things can disallow the app from being relaunched after a kill in recent and freeze the device ? Or this is because the app run as root and there is somethings to do especially from allow the device to relaunch the app in this situation ?
Thanks in advance for your help !
First off, I want to point out that using NSTask isn't always the answer. You can use NSFileManager. to manage files and directories, and you can use exit(0) to terminate your process.
As far as your actual question, is your application running as root? When applications are told to close by iOS, they are sent a SIGSTOP signal by SpringBoard. Since SpringBoard runs as mobile, these signals are sent by the mobile user, meaning that root applications will not receive them. This means that whenever a root application is told to quit, it just ignores the request and keeps executing. To fix this, there is a key in the Info.plist you can change.
Go ahead and set UIApplicationExitsOnSuspend to the boolean true in your Info.plist and see if that fixes your problem.
Ok for the first question I've found how to: I've placed a NSTask method into didEnterBackground (AppDelegate class) that kill the app when the user exit the application
For the second question I really don't know... I've deleted the method placed into viewDidLoad to see if that was the cause of the issue but nothing, as soon as I kill the app in the recent and try to relaunch it, the device froze.. Because there is nothing in viewDidLoad method, I think the issue is caused by the root right... The NStask in DidEnterBackroung solve this issue
Related
There is a crash happen when coming back from background through app icon.
However I cannot see any detail info in console log. There is a signal to terminate, but we cannot find signal number.
<FBApplicationProcess: 0x117bcb930; Maixxxx; pid: 1762> exited abnormally via signal.
Process exited: <FBApplicationProcess: 0x117bcb930; Maixxx; pid: -1> -> <FBApplicationProcessExitContext: 0x17103f820; exitReason: signal; terminationReason: (none)>
The procedures to reproduce my crash is as follow:
Start app through click on app icon.
Use the app as normal user.
Press home to put it in background.
Wait for some minutes.
Click the app icon on springboard screen in order to use it again.
The app crash&exit.
Since the crash only happen when coming back from background, and required to enter background for some minutes, I cannot run in debug mode with lldb attached.
I didn't use any of background features.
Also, I didn't see any crash report in Fabric's Crashlytics. So I think signal handler could not be called neither?
How to investigate this kind of problem?
These things can be tough, I know that from similar experiences. Without knowing more about your app I can only offer hints and no definitive answer, but perhaps this helps you.
The fallback and tedious approach to use direct logging with print and so on notwithstanding there are a two ways to try to "catch" a process.
However, first let me stress that "background" is not always the same and people unfortunately use the term often loosely. Depending on what state transition causes your crash you might run out of luck and have to simply experiment using manual logging. Apps can be in background, i.e. not in the foreground, but still running. This is usually the case when the debugger is attached, otherwise it couldn't do its job. Alternatively they can be suspended (or even terminated) by the OS. The debugger prevents this, which you probably already figured out.
The two things that might help you are:
If you're using background fetch, i.e. "coming back from background mode" as you describe it happens automatically you can activate the "Launch due to a background fetch event" option in your build scheme's "Run" configuration section.
Run your app from the Home screen, put it into background with the Home button and wait a bit (you've probably done so in the past already to get a feeling for when the crash would happen). Your app should eventually go into the suspended state (but you have no way to actually see that anywhere AFAIK). Instead of getting it to the foreground again via the multitasking UI, simply attach the debugger again via the "Debug - Attach to process" menu. This should get your app from the suspended state back into the background state, where the crash probably really happens (if it were to happen when coming from background to foreground you probably would have been able to debug it as usual). Hopefully the debugger has finished attaching to it in time, otherwise I'm out of ideas. :(
I haven't run into this specific problem myself personally, but I know background stuff can be tricky. Maybe this discussion also helps you (I took part of my info from there as well).
Run the app in debug mode on a real device. Press the Home button to send the app to background and continue the debugging. Then you can bring the app to foreground and keep debugging, or put a breakpoint at applicationWillEnterForeground.
You can't debug this on the real device. When the debugger is attached, your apps will never go to background mode in the real device.
You can try to debug this on a simulator.
Anyway please check your class attributes and set attributes to strong to make sure this is not happened by missing attributes.
I have read several StackOverflow questions that have FBApplicationProcess. Usually, this one happened by missing array or something when the app started.
Best regards.
I have gone through all the above answers and all have given proper answers. Though, I would like to share my point of view.
If the app is running on any iOS real device with debug mode and wire plug-in or even on Simulator, App will never go in the background.
If the app is running without wire plug-in or run without Xcode(directly launch the app in iPhone) and then put the app in the background, the app will be running in the background of next 3 mins. After 3 mins, the App will automatically be suspended and removed from the main thread. Now, when we open the app again, It will be considered a fresh launch.
If your app having any Background Capabilities ON, then your app will be alive even in the background, but you can't do any UI changes during that time.
To keep app alive in the background, Background Capabilities must be handled properly. ie. If Location is used in your app with 'While-App is in Foreground' condition, app will not run more than 3 mins in background. So, If you want to run your app continuously in background, you must have to represent proper reason in Info.plist file with Battery drain word, or else, Apple will reject it.
Ping me for more detail on your question.
Thanks.
Crash logs still available on your test device.
To get the crash log try the following steps:
Connect your test device to the Mac through USB.
Launch Xcode. Go to Windows > Devices and Simulators.
Choose your device from the devices section on the left side of the screen.
Select View Device Logs button.
Identify and select the Crash Log to see the contents.
I have my iPhone app running on device, I can see logs in xcode.
Then, I what to see logs about what is happening when app restart.
So, I press home button twice -> swipe up to stop my app, then launch the app again. But I can't see any log in xcode anymore.
How can I see logs of my app continuously before & after my app restart in xcode?
==== UPDATE ===
I mean app log. OK, I can narrow my question to: How can I see logs again after I restarted my app? (device is connected to my mac book , I saw app logs in xcode before restarting, but can't find a way to see app logs after I restarted my app).
You can't see logs of an app that is not running. I can tell you this if you're really curious : there is nothing to log anyway. :)
Now you might want one of those things :
System logs :
Just go in the Device Manager of XCode (short cut is Shift-Apple-2 I think). It's in the Window Tab, under Devices. Select the device you're running on, then you'll have the logs available there.
This logs everything the device logs, so there will be a LOT of text.
App logs :
Those are the ones you already have, but you seem to clearly want the "restart" logs of your app. There is no such thing as a restart log. What you have is the logs at the start of your app, and the ones at the end. For example, what you logged in your AppDelegate's didBecomeActive or willTerminate (or even didEnterBackground).
You will only see the logs of the didBecomeActive when you actually run the app from XCode (otherwise the debugger is offline). He will start the app as if you tapped on the app icon, so no worries there.
If you decide to kill the app by swiping up, it will log the app delegate, and you'll just be able to browse it in the debugger. You can put a breakpoint if you want to make sure it enters the AppDelegate methods.
But if you want to restart the app again, you'll have to re-run it from Xcode, not manually start it on the phone.
File logging :
Another very easy solution is to log everything on a text file in the Documents directory of your app, you'll then be able to start/quit as much as you want, and let it log on the file. You can later read that file like any other file :)
In case you want to just show the device logs you may want to take a look at this answer:
https://stackoverflow.com/a/19148654/691977
In trying to release a new update to one of my enterprise iOS apps, I'm finding that the OTA download is failing. It will give me the "Would you like to install 'xxx'" alert, and tapping 'Install' is about as far as it will go. There's no indication that anything is happening. This occurs on my iPhone 6 and iPad both running the most recent release of iOS 8.
Running the devices on the iPhone Configuration Utility, it shows the list of installed apps, and the one app that is refusing to install has an "Install" button where all the others have "Uninstall." In the screen cap below you'll see the renamed bundle and the original bundle.
When I click the "Install" button, the iPhone Configuration Utility crashes.
I managed to get it to work using a workaround that I found elsewhere on StackOverflow, which requires renaming the app's Bundle Identifier, but it still seems like a pi$$-poor way to do it.
It seems clear that the app is somehow stuck in limbo, showing up on the app list but not showing up on the iPhone screen, and also is refusing to be overwritten. My question is, is there a way to purge the old app from the iPhone's memory, and possibly reload it using the original Bundle Identifier?
Apple still hasn't fixed this correctly in even the latest versions. There are several manifestations: the app does download, but the device doesn't quit the calling app, so you don't know if the app downloads or not. If the app was never on your device before, it usually downloads. If it was there before, and was deleted, it doesn't download. If the downloaded app is already running in the background, or you're doing in-app downloading, it often doesn't download because it doesn't want to replace a running app. I usually start the download, then switch immediately to the springboard to watch it download. If I see the clock dial on the app icon, then I know it's downloading. Changing the bundle is not a good thing, not to mention not giving any user feedback when you tap "Install."
As far as updating the app from the in app prompt.
It's a problem with apple/ios8. They aren't exiting the app after the install. If you quickly tap the home button after you hit install. Occasionally you will get a successful download.
For future use you could find out a way to use exit which will kill the app but apple warns against using exit due to poor user experience. But if apple isn't providing a good user experience in the first place for this process I think this warrants the use imho.
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.
I am working on a VOIP app and need it to auto-start when the iPhone starts up. Everything works 80% of the time. But 20% of the time the app fails to startup. One test scenario is the following:
Open app and type something and save
Reboot phone
Check if app is running by double-tapping the home button but DO NOT open the app.
If app is running, reboot phone again and see if the app comes up again in the background process.
This scenarios works most of the time but not always. Other scenarios also fail at times. Can someone clarify if there is a fool-proof way to start a VOIP iOS app every time the phone boots up?
Thanks.
No, it can't be done. If a user force quits an app, it stays force quit. That's how apple want it, and that's how it's going to be. You can't circumvent the users wishes with multitasking. Also, it's worth knowing that what you see in the fast switcher is not necessarily everything that is running, it's what ios thinks the user should expect to be running ie it may shut something down in the background of its own accord in order to free up resources, but because the user did not initiate it this app will appear to still be open in the switcher, despite that it is not.
Sorry, you can't open an app on startup. You should include a reminder on the app's first start up for the user to keep that app open in the background.