I am trying to develop an app which will be able to open every x seconds or minutes even when the app is killed(by killed I mean removing it from task-manager or quitting it by pressing the back-button). I know that this is kind of spamming, but this is just a test app, only for learning purposes.
By opening every x seconds, I mean that the MainActivity of the app is poping up every x seconds to the user, always when the user is not inside the app. It has to happen always even when the app is killed.
Do you think that something like this will be allowed by android and if yes, how can I programme it?(I was thinking about a foreground-service)
Well, I believe you are not able to do that. After your app is killed, it's not on the memory anymore. This space is given back to android System. The app itself has a lifecycle. You do not have much control after it's finished.
I believe you won't be able to call your application after X seconds, BUT there's something you can take a look: Broadcast receivers
You can make you app respond to some system events, like: chager connected / low battery / conect to a network... There might be some event you would like to work with
https://developer.android.com/guide/components/broadcasts
Related
I'm trying to make an app that must listen to certain events occurring on the phone (such as SMS sending/receiving, screen locking/unlocking) and execute a task every day (it doesn't have to be a precise hour and can be executed when phone is inactive).
The problem is :
- It must be the most invisible possible for the user (no notification if possible)
- Restart automatically when phone restarts
- And not stop when source application stops (when the user manually stop it)
I searched about Services, which seems to quit when I quit application (and... well it looks like it's deprecated) and I'm now trying to use WorkManager from Android Jetpack API (which still doesn't update anymore when I quit app, but I'm probably doing it wrong).
Anybody has some references I can read ? I'm a bit lost
As reference, this is on Android, and this is the Titanium Forum Post
I'm noticing this issue with several applications I've done with Appcelerator, all of them: no matter if they are simple apps or complex apps, but is more frequent in larger apps.
For example, I'm working on an application that needs to notify its location (GPS location) every 5 minutes. The application works perfectly when working in foreground, however, every time I put the app on the background (if I minimize the app by using the Home button) the application just crashes and all the services are stopped.
For notifying the application, here's the flow I'm using:
When I start the application, I start an Alarm, using the AlarmManager module.
This AlarmManager, adds a new Alarm Service, which will be triggered every 5 minutes.
Every 5 minutes, the AlarmManager starts the service and notifies the server with the current location.
This works great.
If I hit the "Home" button, the application just crashes (on the Application Manager) sometimes, but is more frequent when using other applications on the foreground while leaving this app on the background.
I thought this was because the main Activity was stopped, so I decided to maintain the main activity / task state by using android:alwaysRetainTaskState="true"
If I reopen the application, the application just restarts. This happens more on low-end devices than on high-end devices, which makes me think that this is a memory issue.
I have some questions:
Is this the expected behaviour?
If so, how can I mitigate this (maybe a native module/service?)?
Is my current flow the best flow for doing this or is there a better approach?
Any thoughts are more than appreciated.
For answering my own question: After a lot of tests, we saw that the problem was more frequent on older devices.
By reviewing the components, elements and doing an extense memory research, we discovered that this actually has to do on how Android manages Applications and the memory.
If OS decides your application is consuming too much memory on the background, it's able to remove it by any time. No matter if it's executing an Alarm or not.
With devices with more memory (newer devices), the problem just disappears.
Hello I've a basically simple question to ask, what happens to the android OS when my smartphone's screen goes off ? I've noticed a couple of misleading behaviours into my application like :
When screen is off I cannot anymore get results from bluetooth scan, it's like there are no more active devices around me while actually there are like 3-4.
When screen is off most of the times I cannot send or receive messages from other devices via bluetooth.
As soon as I turn the screen on everything start to work fine again, then I turn off the screen again and after like 5-10 my phone stops working properly. I don't have anything inside the onPause method.
Is there somekind of trigger that get fired every X minutes that leads the devices into sleep/hibernate mode?
EDIT :
I decided to call every X min a full wake lock but for some reason my application started to behave weirdly. Yesterday I noticed that the system killed on purpose my application calling the onDestroy() method. Is this even possible? I mean my application uses like 32 MB of RAM and on my test phones I have like hundreds MB of free memory.
In another case the system closed my app and restarted it, how can this happen?
Sometime after the screen turns off, based on user settings for inactivity.
CPU might sleep and threads might suspend..
so you WAKE_LOCK or AlarmManager ...
AlarmManager has a method to setRepeating Alarm every X seconds
Whenever I leave my app running for awhile (~9 hours last time) whatever activity the phone has up will stop responding and need to be force closed, after which there's just a black screen below the slide down notification area and pressing back or home changes nothing. I cannot turn the phone off normally either, as it just spins endlessly when trying to turn the phone off. I need to remove and reinsert the battery.
My app has a background service which monitors for a bluetooth device and runs accept threads with 30 second timeouts. I believe I'm handling them properly as there's only ever 1 shown in my debug screen. I have seen this phone freezing behavior while having the device connected for the entire duration and not having it connect at all.
I have tried keeping the phone connected to logcat to see what happens when the phone freezes up but it always stops receiving updates from the phone after some time, maybe an hour or two at best? Hard to estimate since I'm usually doing something else while waiting.
Does anyone have any tips for what could be causing this or how I can get some additonal feedback to work with?
if your service runs in the background , the OS might kill it after some time , and you must know how to handle it within the service .
services that do a lot of work will be good candidates of being killed .
if you wish your service to do long work (30 seconds is quite a long time) , you should set your service as a foreground service , with a notification .
if you don't wish your service to be a foreground service , try to recover your state when being killed , and try to optimize your code further .
for more information of how services run on android , read this link .
I want to make an application which when it is on "idle state" it must stop doing something. Application enters in idle when user doesn't interact with the application for a number of seconds (ex. 50). Are there some android classes for this or how to do this in a simpler way?
Application enters in idle when user doesn't interact with the application for a number of seconds (ex. 50)
There is no built-in concept of "idle" in Android, other than the device going into sleep mode. You can watch for ACTION_SCREEN_OFF broadcast Intents, but that will be for the whole system, not just your application.
If you have no "background" task processing, you really have to understand the Android Activity lifecycle. You don't have to care about your application going "idle". You have to always keep in mind that your application can be put to sleep by the system AT ANY TIME.
Really read carefully the developer guide.