Develop Reference

Can you indicate to Android the time to wait or tell it that the app is still "active" before displaying "App isn't responding? If so, how?

I'd like to know the code or configuration needed to set that.
In my app, there are some places where I'm willingly make the app to sleep for several seconds, as it's needed for some reasons, with a Thread.sleep(long millis) function.
Problem is that on some Android APIS, at least on 25 and 26, usually that system message pops up in few seconds, confusing the user and maybe even causing the application not to fulfill the needed operations that need to happen while that sleep is happening if the user ends the app, which might cause even malfunctioning of the application.
I'd like to find a way of either forcing Android to wait for a good time like, for example, 1 minute, or to make Android aware that it's not that app isn't responding, that is willingly on a Thread.sleep function.
Is there any way to do that?

I'd like to find a way of either forcing Android to wait for a good time like, for example, 1 minute, or to make Android aware that it's not that app isn't responding, that is willingly on a Thread.sleep function.
TL;DR there is none.
Android apps should at all times be able to yield their position in the foreground to other apps. It's up to the users if they want to wait while some lengthy download is taking place or if they prefer to do something else and come back later.
You can't execute Thread.sleep() on the UI thread for long because this would "freeze the UI".
An example: Users should be able to leave your app by pressing the BACK Button at any time they wish to. If your method is blocking the UI thread, Activity#onBackPressed() can't be executed so the users can't quit.
What can you do? Move the heavy work to another thread (using e.g. AsyncTask or IntentService or some plain worker thread) and show some type of progress indicator to the users if necessary. You can/ should also toggle visibility or enabled state of Buttons etc. if required to avoid clicks which can't be processed at that point in time.

I think you have an implementation problem. The system message, known as ANR (Application Not Responding) occurs when the application cannot respond to user inputs, this may be caused by Ui thread blocking and that may be your case.
To avoid blocking the UI Thread just run your long time operations asynchronously. There are many ways to do that. You could use AsyncTask, AsyncTaskLoader, Thread, RxJava... Here you have some links to help you with that:
https://developer.android.com/training/articles/perf-anr
https://google-developer-training.gitbooks.io/android-developer-fundamentals-course-concepts/content/en/Unit%203/71c_asynctask_and_asynctaskloader_md.html
http://www.vogella.com/tutorials/RxJava/article.html

Is there a way to limit the resources allocated by a Service?

I have an app that has a Service that offloads photos that people are taking to the server.
Specifically, users are sent to the device's native camera to take a photo and then the photo is returned via intent to the app from which they "approve" it.
This act of approval saves it out to the file system and the Service comes along every x seconds, notices files awaiting offload and offloads them.
This all works fine.
However... in situations where there is bad connectivity but enough for the HTTP handshake, the app finds itself in a state where even though the offload is happening in a Service, at the point where the user is coming *back to my app from the photo taking (and Android is delivering the 4-8mb photo back to my approval Activity, my app hangs - sometimes long enough to provoke the "do you want to kill or wait" prompt. Eventually (if you wait) it does succeed in making its way back to the app.
I've verified that this is Network related because when the connectivity is strong (or when the app is in airplane mode - so the upload just fails instantly) everything works perfectly smoothly. The *only time this happens is when the offloader in the Service is hampered by a hinky connection.
So, my question is - what can I do about this? Is there some way I can isolate the Service to not have a larger effect on the app? Is my solution to write a partner app that sits on the device and just looks to offload the files (would that even solve the problem?).
HERE is the report I'm getting when the WAIT/KILL prompt is offered to the user. I'm not sure what to make of it.

The answer turned out to be that Services are actually running on the main Display thread (I was mislead by the fact that when you make an HTTP call in a Service you don't have to run it in a separate thread manually).
http://gmariotti.blogspot.com/2013/03/antipattern-freezing-ui-with-service.html

Traceview profile: Handler.dispatchMessage using significant CPU time

I've just started to profile my app at its prototype stage using Traceview.
I've found that the main user of cpu time (90%) is Handler.dispatchMessage. The main user of real time resource (50% combined) is MessageQueue.next and MessageQueue.nativePollOnce. Calls made by my own methods account for, on average, 2% of real time resource each.
Currently, whilst I am still developing the app I have toasts that appear when there is interaction with my service. I am assuming (about to test the theory tonight) that these calls are down to my frequent use of Toast. Is this correct?
Since Toasts appear on top of the activity whilst you are still using it, having its usage appear in Traceview is a bit deceiving. Is there a way to filter out certain method calls in Traceview, or will I just have to comment the Toast calls in my code, re-build, and re-test? I suppose using a SharedPreference to set whether to use Toasts or not might be useful.
Thanks for the help.

A background sensor data collector in Android

I am now programming a program that collects sensor data, e.g. acclerometer values for a whole day.
Current I just use an Activity and run the activity for a whole day (I turn off screen auto-black), and don't make any shortmessages or phone calls during the day.
I've heard I can make this kind of long running data collector in background using Service. But after I've checked the pedometer at http://code.google.com/p/pedometer/. I found that, when the screen blacks out, the pedometer does not work. (But An application like predometer should work in any case as long as the power is on.)
Although I don't care about the power problem of always sensing acclerometers, I do want to black out the screen to save the power in screen to record more acclerometer data points.
I am thinking about two ways:
1.Using an Service, however, as the pedometer application showed. When the screen blacks out, the service seems stoped working too! Maybe the code has bugs.
2.My application is still an Activity. But I change the scrren light into 0 or totally black to save power.
My question is that: for 1) does a Service have the abality to be always running even when the screen blacks out for a long time; For 2, how to change the screen light?
Thanks!

concerning 1 - what you need is a remote service. this is a service nearly similar to a 'local' service (that is used in the pedometer example) but can run even if no activity is bound to it, in the background. you can turn off the screen and even the activity can crash (in a bad case ;) ) but the service keeps running if you started it with startService(...) instead of bindService(...).
try getting through this and see if that helps.
concerning 2 - you should really use (1) ;)

You do not need a remote service - this can be done with a local Service.
Use the command pattern instead of the binding pattern for the service i.e. use startService() / stopService() rather than bind() / unbind().
In your service onStartCommand() method, return Service.START_REDELIVER_INTENT or something similar, so that the service lives longer than the Activity.
Now the trick: to keep the service processing properly when the phone goes to sleep, you need to work with a PowerManager.WakeLock. These are quite difficult to get right, and I don't think a full explanation is needed in this answer.
Here is some more info:
How to get an Android WakeLock to work?
Also try Lars Vogel's blog: Using Android Wakelock – Staying up all night long
Apologies for the summary answer, but your question is quite broad in terms that it touches on some advanced topics.

Background service can be implemented with IntentService for the most of the scenarios.
Make sure that the background service works in latest and earlier Android version like 2.3 or 2.2.
Designing background operations is different starting from Android 4.0.
Best Practices for Background Jobs
Performing Network Operations

android design considerations: AsyncTask vs Service (IntentService?)

I'm designing an android app which will need to do the following steps:
user pushes a button or otherwise indicates to "sync data".
sync process will use REST web services to move data to and from the server.
the data will be stored locally in a sqlite database.
the sync process should provide status updates/messages to the UI
the user should not be allowed to wander off to other parts of the application and do more work during the sync process.
The first time the sync process runs, it may take 10-20 minutes.
After the initial sync, less data will be transferred and stored and
I expect the process to take 1-2 minutes or less.
I've been doing a lot of reading about android's AsyncTask and various examples of using a Service ... But I don't fully understand the design considerations and trade-offs of choosing one design over the other. I currently have my demo project stubbed out using an AsyncTask. After watching (most of) Developing Android REST client applications: http://code.google.com/events/io/2010/sessions/developing-RESTful-android-apps.html# I'm left confused the design patterns described here feel overly
complex, perhaps because I just "don't get it" yet.
I come from a java, spring, web and desktop application background. Thinking and designing in terms of a handheld device is quite new to me. (What happens when the screen layout is changed? What happens when the phone rings while I'm running a sync?) Taking 2 steps back, if the initial sync IS going to be such a long running process, is there a better way for me to think about the problem->solution, the user experience, the user expectations of an application running on a phone?
Would love to hear from some more experienced android developers out there who have already wrestled with these questions.

In my opinion this is the most tricky/hard part of a mainstream/average Android development. For instance on BlackBerry this is IN TIMES easier.
Definitely you need to use a Service.
AsyncTask does not suit, because it is tightly "bound" to your Activity via a Context handle (otherwise you would not be able to update UI of the Activity from your AsyncTask). However an Activity can be killed by OS once the Activity went in background. An example reason of going to background can be an incoming call - user switches to Phone application so your Activity becomes invisible. In this case (depending on the current RAM state) OS may decide to kill one of the background (invisible to the user) activities.
Some devs workaround this by arranging a static stuff for having a long-running actions inside of. Some recommend to use Application instance. This is because static stuff and Application exist while the whole app process exists. However those are incorrect workarounds. Processes in Android are also may be killed when OS decides it is time to. Android OS have its own considerations about what it can kill and in what order. All processes are devided to 5 levels of "killability". Here is the doc where those levels are specified. It is interesting to read there:
Because a process running a service is
ranked higher than one with background
activities, an activity that initiates
a long-running operation might do well
to start a service for that operation,
rather than simply spawn a thread —
particularly if the operation will
likely outlast the activity. Examples
of this are playing music in the
background and uploading a picture
taken by the camera to a web site.
Using a service guarantees that the
operation will have at least "service
process" priority, regardless of what
happens to the activity.
Your Activity where users initiate a long-running action should show a ProgressDialog to make sure user does not do anything else while the action is running. The guide is here.
Also, you'd most likely want to use the NotificationManager for notifying the user about your long-running action completion (or failure) if your Activity is currently invisible. Here is the NotificationManager info to start from.

There are multiple considerations that you must weigh in order to best decide how to approach your situation. It sounds like you need a good comparison between the two approaches... So here is a list of similarities, and differences and additional considerations that must be taken into account when working on a handheld device.
A Service is a part of your Application that has no UI. It may be called by a UI(Activity) to be started, or may be started by any other component of your Application. When developing, you have the freedom to place it on a different thread, or even run it in a different Task or Process. This allows you to ultimately separate it from your UI. Additionally, you may start the Service to run independently (startService) or bind your activity to it (bindService) depending upon your needs. By using custom Handlers, you can set callbacks to update the UI with your progress. A Service does not necessarily end if a User changes Activities, but may be ended at ANY time by the OS.
A AsyncTask is always instantiated from the UI thread. It only allows specific callbacks, but simplifies the process of multi-threading for the purposes of relatively short transactions (as compared to dedicated separate threaded services) that are inherently tied to actions performed by an Activity. Whenever a User changes Activities, the AsyncTask is put on "pause" and may even die because there is no UI thread for your Activity any longer.
The thing that I would be most concerned about is if the app is going to take 10-20 minutes the first time, I would ASSUME that the User will either change tasks temporarily or set the phone down until it completes (which can cause all of the same complications if the phone sleeps). Given this consideration, a threaded service bound to your activity may be your best choice. To protect your UI, I would make a Progress Dialog for your Activity that receives your progress callbacks. This limits user input in YOUR app and allows your service to continue the way that it needs to. Then override the Activity onResume to check the status of your Service and if it is running. Then you can reset the Dialog immediately.
Given that this is my preferred method, I would also take into account that the OS may kill the App at any time anyway. So make sure to have some way to detect an incomplete or partial sync. Then you may resume automatically when your Activity or Service restarts.

With AsyncTask if the user goes to another Activity you can't transfer that object to the other Activity so it dies. There are tricks you can play when say the user rotates the screen or something like that, but that doesn't extend to general purpose destruction. AsyncTask can randomly die.
Google Sync is run as a Service in the background because syncing can take a while to complete. You might need to follow their path and create your own sync service that you can communicate with. Here is some thoughts how to accomplish that:
http://mylifewithandroid.blogspot.com/2008/01/about-binders.html
You can definitely communicate between Service and Activity, but it's tricky to do it right.

The choice is mainly dependent on the app design. Since both AsyncTask and IntentService stands their ground, what you may want from the app(user experience) is more important and then choose either or both. Some scenarios are mentioned below (mostly what I experienced while developing apps)
Assume apps that have feeds pages - where more than one api calls are made to make the page presentable ( /getFriends, /getDates, /getPictures etc.) you can warp all such api calls to a single AsyncTask with executor which is multithreaded and the sequence of execution doesn't matter. In contrast to IntentService which runs all calls in sequence in a single worker thread. For a high end device with multi-core the call from AsyncTask is more effective. And if you start the AsyncTask on UI thread then updating IU is a piece of cakes(read less boiler plate code). And even if an user leaves the page, with intelligent use of not holding on to the context the app doesn't crash.
Assuming you are trying to write an app which doesn't need the user to be on view/activity/fragment and the total execution time to show something is not mission critical (assume sync service or user notification/alarm) then IntentService is a better choice. (no hassle to start Asynctask on UI thread so that you don't need to write a Handler to force changes on UI etc. etc. and less boiler plate code)
From my experience - write small app for both and compare the pros and cons to get a better idea. (p.s I'd suggest take a look at the iosched app from google to get a better idea - they use both Asynctask and IntentService)

I tend to prefer the IntentService + BroadcastReceiver combo because they give you a really strong degree of control
You definitely have to make sure the UI is running if you are updating something on the screen. ASyncTask crashes were at once reported to be one of the top causes of Android crashes. This can be avoided by keeping some sort of "activityIsAlive" variable and skipping or delaying a UI update if the activity is dead.
The IntentService + BroadcastReceiver combo is a little more resistant to the crash because most tutorials tell you to shut off the BroadcastReceiver onPause or onStop. If you do not do this, again you'll have to turn off the UI update. There's a runOnUiThread command somewhere that will help you do UI updates.
The IntentService + BroadcastReceiver combo is also more extensible. You can create functions and extend BroadcastReceiver to make a more elegant REST processing solution. However, it does require more plumbing vs an ASyncTask
If you do delay the UI update, you may be able to rig it on OnWindowFocusChangedListener. When that function receives true, it means that the UI is alive.
tldr; Make sure the Activity and/or Fragment is alive before updating the UI if you are running something in the background
2015 Edit: check out Loaders as well. A little harder to grasp because there's a lot going on behind the scenes