Develop Reference

android component that never gets destroyed by the system

I am developing android application right now, which sends requests to the server every 4 seconds. I need to make sure that app will keep sending them even if it goes to background (by pressing home button, opening another app or receiving phone call). As far as I know, the best solution for this is to use services. The question is, does service guarantee that it will never get destroyed by the operating system? And if it does get destroyed how can I handle this situation (restart the service)?
Or may be there is a better solution than android service?
App can have any permission over device or operating system, but it must not be rooted. So we can easily update it through google play store.
Thank you very much in advance!
PS. Please don't hesitate to ask me questions if something is unclear.

A Service is indeed what you're looking for, however bear in mind the following things:
1) Services can and will eat up battery life if left unchecked. In your case specifically every one of those 4 second calls will cost you a little more battery life.
I feel like this will absolutely demolish battery life and data usage for most individuals. – CollinD
2) Services will NOT be destroyed by the android OS unless they fail/error out (which you can set conditions for in the service), or they are paused/destroyed by the application.
3) The last chance a user has to change/modify a service before their application closes is in the OnPause() or on Destroy() method. After these are called the application is closed and the service cant be modified without reopening the app so make sure you call anything you need to to make sure the service persists in one of those methods.
I'm not sure if this completely answered your question so let me know if theres anything else I can clarify but it seems like you are using the proper android component for what you're trying to accomplish.

Does Crashlytics miscounts active users on Application Class?

If the call Crashlytics.start(this) is on Application's onCreate() method, will it count an active user if something wakes up my application process?
For e.g. if I have a broadcast receiver or alarm, will it count as an active user if those wake up the app?
Thanks

I'd say that it does not count, but my answer is purely based on logic and common sense.
Crashlytics' recommended approach is to initialize the SDK in your Application class, so that crash logs (and every other type of info) can be collected as soon as possible in your app's lifecycle. When they introduced the Answers panel, my guess is that they figured out their way of determining what an active user is, based on a series of parameters and actions that indicates that the user is actually operating the app (which is, by the way, differs in every Analytics SDK provider, e.g. Google Analytics).
In short, I don't think that the Crashlytics.start() method immediately counts for an active user, because that would be just nonsense. But there's a quick way of determining that:
Create a testbed application that is fired up when you send a specific broadcast message
Initialize the SDK in the Application's onCreate() method
Using adb, send the broadcast message and meanwhile keep an eye on the Answers page of Crashlytics
Wait for some time (it may take some time to register the hit): is the user being tracked as active?
You can try to reach Crashlytics support for this, but I'm not sure they are going to give away this information.
EDIT
Adding some evidence I've found here:
A session begins when the app enters the foreground and ends once the app is backgrounded for 30 seconds or longer.
This leads to believe (as I wrote above) that their way of detecting an active user does not rely purely on the SDK initialization.

I guess that it should, unless it has a more complicated logic of some "actual activity" instead of just opening the app. Application.onCreate() is being called on the beginning of any Activity, Service or Broadcast of your app.
This is what is written in android documentation:
Called when the application is starting, before any activity, service,
or receiver objects (excluding content providers) have been created.
Implementations should be as quick as possible (for example using lazy
initialization of state) since the time spent in this function
directly impacts the performance of starting the first activity,
service, or receiver in a process. If you override this method, be
sure to call super.onCreate().
But keep in mind that if the app is already running the Application.onCreate will not re-run as it is already created.

Android KitKat: Implement a background service to do something when an application is unloaded (or loses foreground)

I want to implement a service (or similar) on Android KitKat (4.4.2) in order to detect which is the foreground app and make something depending on which app it is "foregrounded".
I have read a lot of threads about determining which is the app is the foregound ON THAT MOMENT (https://stackoverflow.com/a/14044662/1683141). But I'm not able to see any thread about keeping this service continuosly monitoring in order to detect any changes on foreground. Kind of loop? Event registering?
For example, I want to be notified when LINE (messaging app) has or loses foreground. So I suppose the service has to be registered to some kind of event (I think Broadcast here is useless) in order to be notified and then take some action.
I don't know if that is possible. I hope it is.
Thank you for your help.

You are unable to keep your service alive if system decide to kill it. You are also unable to keep your service alive if your app is "unloaded" (whatever you mean), because your service is part of your app (and APK) and will be unloaded too.

Is Broadcast Receiver what I need?

I’m trying to execute custom code that is invoked from a listprefeence radio box elsewhere in the setting UI. Its code that will allow the user to select different styles of battery icons on their phone on the fly without a reboot. I have everything done and the code executes fine with one exception. It takes 10-12 seconds for the change to take place. Kind of like it’s not executing until the system does its own check on battery status. How to I get it to execute immediately upon checking the box? Is this done through the use of a broadcast receiver? I am trying to learn android development and have become pretty good with smali but not so much with actual Java yet. I know it’s backwards but I’m trying….
Any help would be appreciated!
Thanks,
Jimmie

Not exactly broadcast receiver, what you want is to find out the system service which checks on battery status. As soon as the user request is received on the UI, you can call the system service to check on battery status and subsequently change the icon.
Also the system service you are looking for may not necessarily be the battery status checker service, it might be UI updater or some other updater service which runs after some time-out and reflects your change.
So you need to figure out which system service is reflecting your change, and then manually call that system service after user has changed his preferences.

Why dont Android applications provide an "Exit" option?

Is there something in the Android developer guidelines that disuades developers from providing the option to "exit" (stop running) an application from within the application itself?
I love multitasking and all but it's not clear to me why:
the vast majority of apps don't have their own Exit functions and hence just keep running forever
don't give you a choice about running when you turn on the phone - they just do by default
Both of these things lead to memory usage constantly increasing and your device running with this performance burden all of the time despite the fact that you may only want certain apps to run some of the time.
Am I missing something?

Is there something in the Android
developer guidelines that disuadea
developers from providing the option
to "exit" (stop running) an
application from within the
application itself?
Yes. It is generally not needed, just as it is generally not needed to restart a Web server because some user with a browser decided (s)he is done with a Web app.
the vast majority of apps don't have
their own Exit functions and hence
just keep running forever
They don't keep running forever. Android will close things up as needed.
don't give you a choice about running
when you turn on the phone - they just
do by default
Those developers aren't paying attention to me.
Both of these things lead to memory
usage constantly increasing
Generally, it doesn't. If you find specific apps that do this, uninstall them.
and your device running with this
performance burden all of the time
Generally, it doesn't. If you find specific apps that do this, uninstall them.
Also, this question is a duplicate of this one.

"Both of these things lead to memory usage constantly increasing"
Which doesn't matter since Android apps are limited to a fixed amount of RAM. Freeing RAM won't give more RAM to other apps.

Essentially, there's no need for a quit button as long as the developer does a good job of designing their app. Android activities are stopped when they aren't visible and resources are needed elsewhere, so the are no longer consuming resources. You can read about the lifecycle here:
Here's a related question:

From Google's Android Application Fundamentals page:
Shutting down components
A content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components.
Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:
An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().
A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().
Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail.
So it seems like Content Providers and Broadcast receivers should never be explicitly shut down, as they are inert while not handling their specific events.
As for Activities, I would argue in favor of having an end to it, but in certain cases. If your app has a finite state in which the user is done using it, why keep it alive until GC gets it? The activity manager still needs to keep track of that Activity while the user has finished their task. My best example for this is the Calculator. You open it, you have it solve a problem for you, and then you close it. If the onCreate function is so expensive that it's more effective to do onCreate once and then onRestart whenever the user moseys back to your application then you're probably doing something wrong. Maybe I'm misinterpreting how Android handles Activities, and if so I'm always interested in learning more :)

It all comes back to the answer that users want total control of their running and auto-start list and what they do and don't want installed, example: google maps, etc etc. there are no two ways about this.