How to create a persistent app which has no user input except via sms

[tcs1752890]

I have created an app which can be started and stopped by the user but otherwise has no user interaction. It monitors accelerometer and gps data, reacting to certain events, and communicates with the user only via sms.
The problem is that after a few days the app dies - I am guessing that Android kills it. How can I prevent this from happening?
I am an experienced software engineer but my Android knowledge is limited to what I have taught myself in the past year.

 

[B. Diddy]

Welcome to Android Central! I moved this from the Android Apps forum to the Software Development forum for more specific traffic.

Which phone are you using to test? Some manufacturers are notorious for baking in more aggressive RAM management into their firmware, which makes it harder to keep apps open in RAM: https://dontkillmyapp.com/

 

[mustang7757]

Allow background activity or don't let it in battery optimization.

 

[tcs1752890]

The phone is a cheap Alcatel model 5003D. All user functionality has been closed down where possible, e.g. all sound off, notifications off etc, and only my app is running. The phone is permanently powered so the battery remains at 100% charge.
From what I have read it seems that the only reliable solution (but not 100%) is to create a foreground service. Can I create a service which doesn't actually do anything and will that still have the effect of keeping the app alive?
As I understand it the system will kill the app in order to recover memory. I hardly use any memory (that I am aware of) but is there any way of cleaning up while the app is still running?

 

[mustang7757]

The phone is a cheap Alcatel model 5003D. All user functionality has been closed down where possible, e.g. all sound off, notifications off etc, and only my app is running. The phone is permanently powered so the battery remains at 100% charge.
From what I have read it seems that the only reliable solution (but not 100%) is to create a foreground service. Can I create a service which doesn't actually do anything and will that still have the effect of keeping the app alive?
As I understand it the system will kill the app in order to recover memory. I hardly use any memory (that I am aware of) but is there any way of cleaning up while the app is still running?

Hi welcome to AC!
We put u in the correct forum if your a app dev , another place to check is xda forums.

 

[tcs1752890]

Hi. No, I'm not a developer. I retired 3 years ago after 45 years of R&D system testing and development in fields as diverse as military aircraft, optical comms and railway signalling. I started tinkering with Android at the start of the pandemic partly to produce something useful and partly out of interest, so I guess you have to say that I definitely fall into the amateur category - at least as far as Android is concerned. So, lots of learning/understanding still to do. I don't need explanations in words of one syllable but it might be better not to assume I understand all the terminology.

 

[mustang7757]

Hi. No, I'm not a developer. I retired 3 years ago after 45 years of R&D system testing and development in fields as diverse as military aircraft, optical comms and railway signalling. I started tinkering with Android at the start of the pandemic partly to produce something useful and partly out of interest, so I guess you have to say that I definitely fall into the amateur category - at least as far as Android is concerned. So, lots of learning/understanding still to do. I don't need explanations in words of one syllable but it might be better not to assume I understand all the terminology.

Interesting career, what's the name of your app?

 

[tcs1752890]

It doesn't have a name - it's for private use only. It's just a bit of a toy really but with a useful function for me.

Yes, it was an interesting career. My first job was working on the Tornado radar systems. The processor was an 18 bit device with 16 functions and a 13 bit address field, and the system had initially 8k of memory (yep! that's right 8000 words). I/O was via 8 hole punched tape. Testing in a windy hangar in Bedfordshire was really interesting - plugging a tape reader into the side of a Buccaneer and trying to control a few thousand feet of punched tape flying through at some silly speed. Those were the days when engineers knew what accumulators and assorted address registers actually did, and could program in machine code (just a bunch of numbers).
I remember system testing the first 8080 based telephone exchange without any window into the software except for an XY 'scope that the engineers had wired into the memory address lines. This produced a pretty pattern on the scope and we could estimate which bit of code was being executed by the position of the dot on the screen. Great fun!
Although we can produce far larger and more complex programs today, and have such extremely useful tools, that in itself can make the programming and testing just as difficult in a different way. From my perspective there's a lot more faith involved - I can no longer ferret around at the bits and bytes level and convince myself that it's working (or not).

 

[mustang7757]

It doesn't have a name - it's for private use only. It's just a bit of a toy really but with a useful function for me.

Yes, it was an interesting career. My first job was working on the Tornado radar systems. The processor was an 18 bit device with 16 functions and a 13 bit address field, and the system had initially 8k of memory (yep! that's right 8000 words). I/O was via 8 hole punched tape. Testing in a windy hangar in Bedfordshire was really interesting - plugging a tape reader into the side of a Buccaneer and trying to control a few thousand feet of punched tape flying through at some silly speed. Those were the days when engineers knew what accumulators and assorted address registers actually did, and could program in machine code (just a bunch of numbers).
I remember system testing the first 8080 based telephone exchange without any window into the software except for an XY 'scope that the engineers had wired into the memory address lines. This produced a pretty pattern on the scope and we could estimate which bit of code was being executed by the position of the dot on the screen. Great fun!
Although we can produce far larger and more complex programs today, and have such extremely useful tools, that in itself can make the programming and testing just as difficult in a different way. From my perspective there's a lot more faith involved - I can no longer ferret around at the bits and bytes level and convince myself that it's working (or not).

Thats awesome, as a automotive technician I can relate somewhat on scopes and waveforms
Watching ign.coil , computer sensor, bus communication between computers on cars and much more . Have a fluke oscilloscope just purchased Pico scope that does lot more with static compression and uses a laptop with bigger screen to analyze waveforms and blow them up for more details , pretty cool stuff.

You can try on xda forums see if you can find your answer there , great minds over there with things like that.

 

[B. Diddy]

It doesn't have a name - it's for private use only. It's just a bit of a toy really but with a useful function for me.

Yes, it was an interesting career. My first job was working on the Tornado radar systems. The processor was an 18 bit device with 16 functions and a 13 bit address field, and the system had initially 8k of memory (yep! that's right 8000 words). I/O was via 8 hole punched tape. Testing in a windy hangar in Bedfordshire was really interesting - plugging a tape reader into the side of a Buccaneer and trying to control a few thousand feet of punched tape flying through at some silly speed. Those were the days when engineers knew what accumulators and assorted address registers actually did, and could program in machine code (just a bunch of numbers).
I remember system testing the first 8080 based telephone exchange without any window into the software except for an XY 'scope that the engineers had wired into the memory address lines. This produced a pretty pattern on the scope and we could estimate which bit of code was being executed by the position of the dot on the screen. Great fun!
Although we can produce far larger and more complex programs today, and have such extremely useful tools, that in itself can make the programming and testing just as difficult in a different way. From my perspective there's a lot more faith involved - I can no longer ferret around at the bits and bytes level and convince myself that it's working (or not).

That's fascinating -- I'll bet @Rukbat, one of our Ambassadors, would love to chat with you!

 

[tcs1752890]

Hi guys,

I'm getting very lost - the more I read and the more people I talk to the worse it gets, especially as I have now been reading how it's a bad idea to use foreground processes to try to keep an app alive and that really the "correct" way to do it is use the AlarmManager with the Service as a sort of cron job.

Perhaps I can explain in a different way:

We have 5 main components:
1) SMS Receiver and associated message decoding for app control. Incoming messages might be weeks apart or just a few seconds.
2) Accelerometer data incoming at a rate of about 0.2 seconds per event. Data being analysed and user notified by SMS of certain events.
3) GPS data being received from FusedLocationProvider at varying intervals between 1 minute and 15 minutes (approx). User notified by SMS of certain events.
4) Geofence active and user notified by SMS of exit event.
5) Battery monitor with user notified by SMS if power lost (not charging).

I want this little lot to run indefinitely.

So I guess an alternative question is "how do I organise this lot given that Android might shutdown my app at any time?" Any suggestions gratefully received.

Regards.

 

[Kizzy Catwoman]

I do recommend joining XDA forums as well. They are really knowledgeable about making apps and I am sure they know more about this issue than we will. I think you will get a lot more detailed help from them and they are friendly.