On Mon, Mar 28, 2011 at 8:06 PM, Mark Carter <[email protected]> wrote:
> Thanks Irfan. Doesn't the CPU need to be awake the whole time anyway? If it > isn't, then won't the download stop/pause as soon as the CPU sleeps? If > that's true, then isn't the WakeLock essential? If you have initiated a download and the packets are being received by the device, the CPU will end up being awake the whole time. If for some reason the connection is flaky (say the device disconnected and reconnected) which causes the packets to come in infrequently, the CPU might sleep, but should be woken up on packet reception. In either case, you might be fine without a wakelock. > Also, what happens if the Wifi lock is acquired when the device is not > using Wifi (I mean Wifi is enabled but it is not connected to any access > point) - does that then make the Wifi lock redundant? > No. Holding a wifilock will mean that the device will connect to an access point if it sees one come up. Without a wifilock, the device shuts down Wifi 15 minutes after screen off (by default) - so it wont even attempt to connect to an access point without a wifilock. > I must confess I don't fully understand the reasoning behind a WifiManager. > > As a developer, I want a lock that says: > > "Keep awake the current internet connection until the download has > finished" > > and that lock would also prevent the device from sleeping. > > I don't care if it's over Wifi, mobile internet or wired or whatever. I > might want to check if it's mobile internet so I can warn the user about > potential high data volume costs, but that's different. > Normally, you should not need to hold a Wifilock in an app if you do not care what the connection is. As for an active download connection - I do not think you need to do anything special here - with an incoming packet, the device should be woken up and get handled. The device can switch from wifi to 3g without a WifiLock (this can anyway happen when wifi disconnects for some reason). You can listen to ConnectivityManager broadcasts to detect when the device switches to a different network (say if you want to stop a large download when the user is on 3g). The WifiLock is meant for apps that specifically do care about being on Wifi even after device goes to sleep. Irfan > > > On 29 March 2011 09:41, Irfan Sheriff <[email protected]> wrote: > >> WifiLock keeps the device on Wifi and prevents the device policy of >> shutting down wifi and switching to 3g after 15 minutes of screen off. >> >> Holding a wifilock should normally be sufficient to complete a download >> since even in the power optimized state (screen off), the device should >> still wake up on packet reception and they should get handled by the device >> - though the packet loss in screen off state tends to be higher and the >> download will be slower. >> >> If you want to ensure the cpu is awake the whole time, you can hold a >> wakelock as well. >> >> Thanks >> >> >> On Mon, Mar 28, 2011 at 10:31 AM, Mark Carter <[email protected]>wrote: >> >>> From what I gather, WifiLock and WakeLock work completely independently >>> and if you are downloading a large file over Wifi then you will need to >>> acquire both locks?? >>> >>> Ideally, you would want something like this: >>> >>> 1. Acquire partial WakeLock >>> 2. Preparing to download large file, check whether on Wifi or not. >>> 3. If on Wifi, then acquire WifiLock. If not, then prevent device >>> switching to Wifi (is this possible?) >>> 4. Start download >>> 5. When download has finished, release all locks. >>> >>> Is this correct? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Android Developers" group. >>> To post to this group, send email to [email protected] >>> To unsubscribe from this group, send email to >>> [email protected] >>> For more options, visit this group at >>> http://groups.google.com/group/android-developers?hl=en >> >> >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
