I'm currently trying to remake our company app that has been outsourced. We do not have access to the source code so its not possible to look at the code. Our outsourced app has a service running in the foreground with a notification. When the outsourced app is closed by the user in the open app list (I'm unsure what it's called) it doesnt really close. Its behavior is almost like it's being minimized. When opening the outsourced app after closing it opens immediately right where it was last left off like it was never closed. Not even a splash screen. It's behavior is like its being resumed.
I've been able to run a foreground service with binding and unbinding following the sample ForegroundLocationTracking embarcadero has given. The app stays open despite the user going to the home screen or locking the phone. The problem comes when the app gets terminated by the user from the open apps list. The app is now terminated and the service briefly gets terminated but gets started by the system again.
My thoughts are that the outsourced app is running a remote service however I'm unsure.
How can I make the app have the same behavior as the outsourced app? The service will keep running in the foreground. No briefly terminating and starting again. The main app must also just resume like the outsourced one does or have the same behaviour.
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.
is there any way to remove app from background using Appium in Windows.
What i want is
- Start server with -No reset
-Run the program
-Program ends
-driver quits using driver.quit() method
Now when i start my test execution again , the app on which i was earlier working is there in the memory.So i have to press "Home" key and remove it from memory and then start working on it. (e.g. if i am working on messaging app of device , after test execution i press "Home" hardkey and manually remove the app as follows)
Please help me how to do this
You have to use driver.closeApp() before driver.quit().
Please see this link with the different appium methods provide app control.
How can one test the scenario of Application Launch in background for handling Background NSURLSession's event?
Flow:
Application starts a upload/download task using Background URL
session.
User hits home button. App is in suspended or in background
state.
OS decides to Exit the application. I know, one can exit the app by double-tapping home button and swipe-up the particular app. But in that case OS will never re-launch the app in background for event handling.
Upload/download task needs some event handling. OS re-lauches App in background.
So the question is how do I make OS exit the app like it may normally do after some-time. The purpose is to test the code for this scenario. I tried using UIApplicationExitsOnSuspend but it does not work since then App can not be launched in Background.
It's not a perfect solution, but I was able to manually test the launch of an app due to a Background URLSession on a physical device as follows:
Connect device for debugging via USB
Disable Internet connectivity on device (i.e. disable WiFi/Cellular)
Start the app via Xcode
Issue a request using background URLSession. The request shouldn't fail, it will just be waiting around for an Internet connection until it times out, so use a reasonably long timeout to make testing easier.
Kill the app via Xcode (press stop button)
View the device logs via Windows > Devices and Simulators
Enable Internet connectivity on the device again without starting the app
The requests from the background URLSession should then complete and in the device logs (from step 6.) you should see any NSLog statements issued as a result of the app being launched via the application(_:handleEventsForBackgroundURLSession:completionHandler:) app delegate method.
They key point is that killing the app via Xcode, as opposed to killing it using device itself, does not prevent the app from being relaunched for background event handling.
A possible alternative to killing the app manually via Xcode might be to intentionally crash the app in code - this might be more suitable for automated testing.
You could write an app that has a button that allocates and intentionally leaks chunks of memory. If you get this thing to allocate enough RAM, the OS will start killing other apps to get their RAM back.
Hopefully this would exhibit the behavior you need.
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.