Develop Reference

Does need Broadcast receiver to WakeLock

I have two questions.
I want fire a Broadcast receiver using AlarmManager and show a notification in onReceive method. Should I use from WakeLoke for this?
What is different between setAlarmClock() and setExactAndAllowWhileIdle() ?

I use (as you wrote) the onReceive method to start a newWakeLock and it works fine for me.
The difference lies in the behavior in doze mode (Doze Mode: https://developer.android.com/training/monitoring-device-state/doze-standby).
I do not know your exact problem, but I worked very hard to develop an app which contains few timers and every timer should make a notification at the exact time even the screen is locked and the device is in the doze mode. My solution is to fire an Broadcast over an AlarmManager with the setExact(...) method.

Answer your question in reverse order
.2. setExactWhileIdle guarantees that if the system is not sleeping and not in doze, the alarm will go off within 1 minute of the given time. if the system is in doze mode, the alarm will go off within 15 minutes of the given time. In practice, if the system is not in doze mode or low on battery, the alarm will go off on time. On the other hand, setAlarmClock is the closest one can get to a guarentee that the system will deliver the alarm at a specific time; this does come at a relatively large drain on battery. So, if your goal is to implement highly time sensitive notifications such as an alarm clock, then use setAlarmClock. Otherwise try to avoid it.
.1. according to the documentation, upon an alarm being dispatched from setExactAndAllowWhildIdle or setAlarmClock:
the app will also be added to the system's temporary power exemption list for approximately 10 seconds to allow that application to acquire further wake locks in which to complete its work.
My suggestion is that if all you are doing is posting a notification, then a wake lock is not necessary. Otherwise, if you are doing longer running work, use a wake lock
Obligatory Disclaimer: battery drain is a real thing. please don't make an app that drains the battery. do everything in your power to design your app not to disturb the systems power optimization. All exact alarms and especially setAlarmClock disrupt the systems attempts to optimize battery. If its necessary, then its necessary. Otherwise, do not do it.

Android AlarmManager without turning screen on

My application have a realtime module that should ping the server every 60 seconds. Without this, the connection will be dropped and the device will need to reconnect again.
The first attempt was to use a Thread.Sleep to make the pinging thread runs at the desired frequency. The second attempt was to use the ScheduleExecutorService. Both worked very well, but only when the device was charging or with the screen turned on.
After reading a bit, I realized that this behavior happens because the device's processor sleeps and this interferes on the timers. So, the recommendation is to use the AlarmManager...
After start using it, I noticed the my device's screen started to be turned on frequently and I think that this is caused by the alarmmanager that 'wakes the device up'. I searched o bit to see how to use AlarmManager to execute some background actions even if the device is sleeping, without turning the screen on, but nothing was found.
So, there is anyway to use AlarmManager or other approach to accomplish this? Execute a background task even if the device is sleeping, without turning the screen on?
PS1: I know the battery consumption implications due this approach and the request about not turning the screen on is to minimize it's impact.
PS2: The AlarmManager's intent is being consumed by a background service.

Alarm Manager does not turn the screen on. From the docs,
When an alarm goes off, the Intent that had been registered for it is broadcast by the system, automatically starting the target application if it is not already running.
I am using it in my code and it does not turn the screen on unless I explicitly set a wake lock policy that turns it on. Take a look at WakeLock
The last 3 are deprecated as of API level 17.
I recommend you to use a PARTIAL_WAKE_LOCK for your task. or you can take a look at WakefulBroadcastReceiver

If you are using onReceive() method, that may be acquiring your wakelock. Remove the WakeLock parameter in onReceive().

Is wake lock commutative?

Let's say an Android application acquires a wake-lock, and then launches another application by sending it an explicit intent. Does the effect of acquisition of wake-lock last while the other application is in the foreground ?

As described in Keeping the Device Awake it's perfectly natural for a background application to grab and hold a CPU wakelock:
One legitimate case for using a wake lock might be a background service that needs to grab a wake lock to keep the CPU running to do work while the screen is off. Again, though, this practice should be minimized because of its impact on battery life.
This action is pretty common. For example, imagine a music playing application. Even though the screen is off, or some other activity is in the foreground, it's fine for a background application to hold a wake lock to keep playing music.
Although that last line should really take a warning. As described in Wakelocks and Battery Drain those things tend to burn through battery pretty fast; and worse yet, is that it's a pretty common problem to not release them properly, and end up putting the device into a sleepless mode, where it never goes to sleep.

Code inside AsyncTask doesn't run smoothly when screen is off

Inside my AsyncTask I vibrate the phone in a certain pattern and repeat this until the user turns it off. This works fine as long as the screen is on. If the screen is off, the code still runs but with periodic breaks in between. It seems like Android tries to consume battery with the screen off and only runs code within threads (like my AsyncTask) only periodically. Is that true? Or is this some other behavior? Is there a way I can get my code to run smoothly even with the screen off? Turning on the screen could drain the battery. The vibration is used to notify the user even when the screen is off.

You can use a WakeLock. By using a PARTIAL_WAKE_LOCK you can ensure that even though your screen is off, cpu is running and your code will execute properly.
However, I would like to add that I've never run into such problems with AsyncTask, But if you are running into such problems a wake lock would probably be the solution.

AsyncTask is not designed to handle long running tasks. If you want your phone to vibrate in a specific pattern for a long time, I'd suggest to use set repeating alarm using the AlarmManager.

Android 2.2: Turning of screen under certain times of the day by code

I would like to know if there is any way to turn off the screen on an android device on for example 19.00-22.00 every day. I have some tablets running in kiosk mode, and i want the screens to turn off when no one is using them and the store is closed.
Thanks

Screens will turn off automatically, if you have that set up properly in the device settings.
You can use AlarmManager and a WakeLock to arrange to keep the device screen awake during business hours. Have the AlarmManager start up a service that acquires the WakeLock and waits until closing time. You will need to use startForeground() in the service to prevent Android from killing off your service.
In the real world, this implementation would suck, as it forces you to keep a service running all the time -- if you let the service shut down, you lose the WakeLock and can never release() it, so the screen will never shut off. So, outside of this sort of kiosk thing, I do not recommend this technique.