Obsolete
Status Update
No update yet.
Comments
le...@googlemail.com
this would be nice but given Compose and all other priorities, we are not planning to make any big investments in data binding (support KSP is a very big task).
ct...@gmail.com
Makes sense. And is there any way to trigger data binding without kapt plugin, assuming there are no custom binding adapters in given module?
jo...@gmail.com
unfortunately no. data binding still needs to be able to read your code and annotation processing is the only API that allows us to do it :(
re...@gmail.com
It's a very disappointing decision for many projects who heavily depend on data binding, which will never be able to get rid of all bindings code and especially rewrite all UI to Compose.
It means that bindings are essentially deprecated
[Deleted User] <[Deleted User]>
It does not mean data binding is deprecated unless KAPT is deprecated (if that happens, we would need to support KSP).Unfortunately, moving data binding to KSP is a large order so it makes more sense to keep focusing on KAPT than rewrite data binding.
We might re-consider this in the future based on KSP becoming stable, Compose adoption and KAPT stability but it is very unlikely to happen.
ro...@gmail.com
Unfortunately this is still a NO for 2022 planning due to reasons mentioned in #2.
dg...@gmail.com
kapt seems no longer adding new feature
kapt is in maintenance mode. We are keeping it up-to-date with recent Kotlin and Java releases but have no plans to implement new features. Please use the Kotlin Symbol Processing API (KSP) for annotation processing. See the list of libraries supported by KSP.
So this mean databinding will also deprecated or will be support KSP?
ro...@gmail.com
Databinding is in maintenance mode as well.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
ro...@gmail.com
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
I have been waited this answer in several years.
Because it is an important basis to convince co-workers and for determining the technology stack of an app.
ro...@gmail.com
Databinding is in maintenance mode as well.
We don't plan to support KSP nor recommend data binding usage at this stage since compose is our recommended UI solution.
A bit of a tangent here, but what about ViewBinding? Will that one stay going strong or will it fade along with DataBinding?
ro...@gmail.com
ViewBinding is only a build tool and does not run an annotation processor, hence it is not impacted by KAPT / KSP.
So if you are using Views, ViewBinding will keep working.
It is the same for Data Binding as well though. The main difference is that if KAPT stops working, DataBinding will stop working whereas ViewBinding will keep working. Hopefully, any such situation will be far enough that no-one will care and everyone will be using Compose :)
So if you are using Views, ViewBinding will keep working.
It is the same for Data Binding as well though. The main difference is that if KAPT stops working, DataBinding will stop working whereas ViewBinding will keep working. Hopefully, any such situation will be far enough that no-one will care and everyone will be using Compose :)
gl...@gmail.com
#14 Kapt will be supported on K2, there are no plans to stop supporting it in Kotlin
dg...@gmail.com
gooooogle, gradle and kotlin are a perfect match ☺️
da...@gmail.com
deleted
ma...@googlemail.com
This is really a show stopper for me. I don't think the issue will be fixed soon as it is still marked as new and has been posted a year ago.
le...@googlemail.com
Cheer up Marcus, virtually all tickets are marked New and havn't got an official response after (literally) years, so there's just as much hope for this issue as for all the others.
So you can see that equality of handling is very important over at Google HQ and they should be commended for that.
So you can see that equality of handling is very important over at Google HQ and they should be commended for that.
ma...@googlemail.com
A temporary fix for this problem might be to deactivate and activate the affected location profiles each X minutes. At least it seems to work here. But I'm not sure about the battery life.
al...@gmail.com
I have the same issue on i9000 running 2.3.3
It reduced the value of Tasker app as I can't have commands to be executed in certain locations without screen being on.
It reduced the value of Tasker app as I can't have commands to be executed in certain locations without screen being on.
pe...@gartenzwerg-records.de
Same issue here + also a show stopper for us. In addition to the previous mentioned issues, the getCellLocation() method of the TelephonyManager returns outdated cell locations in sleep mode.
gl...@gmail.com
2.3.4 still has this issue.
I guess we're stuck with 2.1 till this show-stopper gets fixed :/
I guess we're stuck with 2.1 till this show-stopper gets fixed :/
pc...@gmail.com
[Comment deleted]
pc...@gmail.com
[Comment deleted]
ca...@gmail.com
Even if Google fixes this issue, absolute majority of phones out there will still be affected by this issue as they are running 2.2, 2.3 and alike. It will take years until the fix gets into majority of phones on the market.
What upsets me is that there is no clear mention of this in the documentation.
What upsets me is that there is no clear mention of this in the documentation.
yo...@gmail.com
[Comment deleted]
yo...@gmail.com
Having the same issue. I don't understand why Google is blocking Cell updates.
LocationListener can be updated every 10 seconds, even when the phone is off. But for CellListener, it's not working !
It make not sense at all !
Cell event are less intensive of network Location I think. I don't see any good reason to do like that.
(I try with a Handler fetching TelephonyManager.getCellLocation() every 10 seconds to see if it's updated without an event, but there is no way. I can fetch it every 1 milliseconds if I way, using how many battery, cpu time, I want with this timer, but the cell ID is not updated ...)
LocationListener can be updated every 10 seconds, even when the phone is off. But for CellListener, it's not working !
It make not sense at all !
Cell event are less intensive of network Location I think. I don't see any good reason to do like that.
(I try with a Handler fetching TelephonyManager.getCellLocation() every 10 seconds to see if it's updated without an event, but there is no way. I can fetch it every 1 milliseconds if I way, using how many battery, cpu time, I want with this timer, but the cell ID is not updated ...)
gv...@gmail.com
Its very important to have this fix. There are so many times i could not demonstrate my GPS applications to customers owing to lack of GPS signal or when I am inside a premises. Apps will work good if there is some approx. location info even when the GPS is OFF / signal unavailable. I wasted several days testing some sample apps on NETWORK_PROVIDER and I am frustrated with the way some of the developments are happening on Android...
yo...@gmail.com
After some checks, it seems to be very low level.
In com.android.internal.telephony.RIL object
This is the very lower level object I found : this object seems to communicate to the RIL Server via RIL Socket :
s = new LocalSocket();
l = new LocalSocketAddress(SOCKET_NAME_RIL,
LocalSocketAddress.Namespace.RESERVED);
s.connect(l);
And now, I try to switch 3G => 2G, and switch immediatly to screen Off.
I got lots of line like :
D/RILJ ( 247): [0457]< REGISTRATION_STATE {1, null, null, 3, null, null, null, null, null, null, null, null, null, null}
(That mean, no Cell registered (null, null)
I way like 1 minutes, and still no good line.
But, when I switch the screen ON, RILJ receive 2 events. Firstly :
SCREEN_STATE: true
And then :
REGISTRATION_STATE {1, 4E3F, 0003975A, 3,
So, the RIL server seems to block updates.
Full logs :
D/RILJ ( 247): [0469]< REGISTRATION_STATE {1, null, null, 3, null, null, null, null, null, null, null, nul
l, null, null}
D/RILJ ( 247): [0470]< QUERY_NETWORK_SELECTION_MODE {0}
D/GSM ( 247): Poll ServiceState done: oldSS=[0 home BYTEL (N/A) 20820 EDGE CSS not supported -1 -1RoamI
nd: -1DefRoamInd: -1EmergOnly: false] newSS=[0 home BYTEL (N/A) 20820 UMTS CSS not supported -1 -1RoamInd: -1
DefRoamInd: -1EmergOnly: false] oldGprs=0 newGprs=0 oldType=EDGE newType=UMTS
D/GSM ( 247): RAT switched EDGE -> UMTS at cell -1
D/RILJ ( 247): [0471]> SCREEN_STATE: true
D/GSM ( 247): [DataConnection] Stop poll NetStat
D/RILJ ( 247): [UNSL]< UNSOL_RESPONSE_NETWORK_STATE_CHANGED
D/RILJ ( 247): [0471]< SCREEN_STATE error: com.android.internal.telephony.CommandException: GENERIC_FAILUR
E
D/RILJ ( 247): [0472]> OPERATOR
D/RILJ ( 247): [0473]> GPRS_REGISTRATION_STATE
D/RILJ ( 247): [0472]< OPERATOR {BYTEL, (N/A), 20820}
D/RILJ ( 247): [0474]> REGISTRATION_STATE
D/RILJ ( 247): [0473]< GPRS_REGISTRATION_STATE {1, null, null, 3}
D/RILJ ( 247): [0475]> QUERY_NETWORK_SELECTION_MODE
D/RILJ ( 247): [0474]< REGISTRATION_STATE {1, 4E3F, 0003975A, 3, null, null, null, null, null, null, null,
null, null, null}
In com.android.internal.telephony.RIL object
This is the very lower level object I found : this object seems to communicate to the RIL Server via RIL Socket :
s = new LocalSocket();
l = new LocalSocketAddress(SOCKET_NAME_RIL,
LocalSocketAddress.Namespace.RESERVED);
s.connect(l);
And now, I try to switch 3G => 2G, and switch immediatly to screen Off.
I got lots of line like :
D/RILJ ( 247): [0457]< REGISTRATION_STATE {1, null, null, 3, null, null, null, null, null, null, null, null, null, null}
(That mean, no Cell registered (null, null)
I way like 1 minutes, and still no good line.
But, when I switch the screen ON, RILJ receive 2 events. Firstly :
SCREEN_STATE: true
And then :
REGISTRATION_STATE {1, 4E3F, 0003975A, 3,
So, the RIL server seems to block updates.
Full logs :
D/RILJ ( 247): [0469]< REGISTRATION_STATE {1, null, null, 3, null, null, null, null, null, null, null, nul
l, null, null}
D/RILJ ( 247): [0470]< QUERY_NETWORK_SELECTION_MODE {0}
D/GSM ( 247): Poll ServiceState done: oldSS=[0 home BYTEL (N/A) 20820 EDGE CSS not supported -1 -1RoamI
nd: -1DefRoamInd: -1EmergOnly: false] newSS=[0 home BYTEL (N/A) 20820 UMTS CSS not supported -1 -1RoamInd: -1
DefRoamInd: -1EmergOnly: false] oldGprs=0 newGprs=0 oldType=EDGE newType=UMTS
D/GSM ( 247): RAT switched EDGE -> UMTS at cell -1
D/RILJ ( 247): [0471]> SCREEN_STATE: true
D/GSM ( 247): [DataConnection] Stop poll NetStat
D/RILJ ( 247): [UNSL]< UNSOL_RESPONSE_NETWORK_STATE_CHANGED
D/RILJ ( 247): [0471]< SCREEN_STATE error: com.android.internal.telephony.CommandException: GENERIC_FAILUR
E
D/RILJ ( 247): [0472]> OPERATOR
D/RILJ ( 247): [0473]> GPRS_REGISTRATION_STATE
D/RILJ ( 247): [0472]< OPERATOR {BYTEL, (N/A), 20820}
D/RILJ ( 247): [0474]> REGISTRATION_STATE
D/RILJ ( 247): [0473]< GPRS_REGISTRATION_STATE {1, null, null, 3}
D/RILJ ( 247): [0475]> QUERY_NETWORK_SELECTION_MODE
D/RILJ ( 247): [0474]< REGISTRATION_STATE {1, 4E3F, 0003975A, 3, null, null, null, null, null, null, null,
null, null, null}
yo...@gmail.com
Ok ! Get a fix for this issue.
You just need to register a LocationListener with NETWORK_PROVIDER
this.my_listener = new MyLocationListener(); // Extends LocationListener
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, this.my_listener);
This listener will force Android to update the CellID (for location purpose). The update is a bit random (~30-60 sec) but it will be updated.
So your other Listener (PhoneStateListener) will be updated.
onCellLocationChanged(CellLocation cell) will be called.
You just need to register a LocationListener with NETWORK_PROVIDER
this.my_listener = new MyLocationListener(); // Extends LocationListener
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, this.my_listener);
This listener will force Android to update the CellID (for location purpose). The update is a bit random (~30-60 sec) but it will be updated.
So your other Listener (PhoneStateListener) will be updated.
onCellLocationChanged(CellLocation cell) will be called.
sa...@gmail.com
So is this fix something for developers to add to their apps, Google to add in Android, Samsung to add to their flavour of Android - or something a user can add to their handsets, even if not rooted?
da...@gmail.com
Commenter 31... I've found a similar fix (involving addProximityAlert instead of requestLocationUpdates) works fine on my phone HTC Desire Z running Cyanogenmod 7.1, but other phones (e.g. Motorola Defy, Optimus 2x, Samsung Galaxy S2*) still have problems with the cell ID not changing when the screen is off.
Also bear in mind that addProximityAlert explicitly says "In case the screen goes to sleep, checks for proximity alerts happen only once every 4 minutes. This conserves battery life by ensuring that the device isn't perpetually awake.", whereas requestLocationUpdates makes no such guarantees.
* I don't have first-hand experience of these phones, and am relying on user reports.
Also bear in mind that addProximityAlert explicitly says "In case the screen goes to sleep, checks for proximity alerts happen only once every 4 minutes. This conserves battery life by ensuring that the device isn't perpetually awake.", whereas requestLocationUpdates makes no such guarantees.
* I don't have first-hand experience of these phones, and am relying on user reports.
yo...@gmail.com
@32 : Developers must add the LocationListener in their code.
LocationListener is available in the Android API.
It's a permanent fix for all Android version. It's working without any data available, and even if the CellID is not registered in the CellID database.
If the phone couldn't find the cell location (in the remote CellID location database), you will not have the LocationManager.NETWORK_PROVIDER event (with log/lat coordinates), but you will have the onCellLocationChanged anyway (and that interest us).
The only ROM I found, that don't work, is a ROM which don't have Google's things installed, because I think that this rom don't have access to the remote CellID location database, so the locations updates are disabled.
LocationListener is available in the Android API.
It's a permanent fix for all Android version. It's working without any data available, and even if the CellID is not registered in the CellID database.
If the phone couldn't find the cell location (in the remote CellID location database), you will not have the LocationManager.NETWORK_PROVIDER event (with log/lat coordinates), but you will have the onCellLocationChanged anyway (and that interest us).
The only ROM I found, that don't work, is a ROM which don't have Google's things installed, because I think that this rom don't have access to the remote CellID location database, so the locations updates are disabled.
dc...@gmail.com
So all we need is for somebody to write a little app that does this?
this.my_listener = new MyLocationListener(); // Extends LocationListener
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, this.my_listener);
And that fixes the problem? Can anybody on this thread write that app and make it available to people?
this.my_listener = new MyLocationListener(); // Extends LocationListener
LocationManager locationManager = (LocationManager) this.getSystemService(Context.LOCATION_SERVICE);
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, this.my_listener);
And that fixes the problem? Can anybody on this thread write that app and make it available to people?
ca...@gmail.com
I do not think that having a location listener for the network provider solves anything. Here is a little experiment I have done: created a service, registered a network location listener and logged the received locations. Took the phone with me in my car and drove around. All the time the phone had its screen off the received location did not change. To make things even worse, the location time was changing properly, only the location received did not change. It seemed like the location is cached and not updated if the screen is off. As soon as I turned the screen on the received location was updated properly. I also repeated the experiment using gps and found it working not matter the screen status.
I tried this on my nexus one running android 2.3.6. I can provide the source code for the test case if anyone is interested.
I tried this on my nexus one running android 2.3.6. I can provide the source code for the test case if anyone is interested.
yo...@gmail.com
ca...@gmail.com
As an additional comment to my experiment above, I also tried a partial wake lock. It did not make any difference. The only way I found network updates to work properly was with the screen on.
ca...@gmail.com
Attached is the test case.
yo...@gmail.com
I don't see your CellLocationListener in the code.
Can you add it ?
Because you receive CellLocation update before the NetworkLocation (Because the LocationManager need the CellID to locate the cellphone). And sometimes, I receive a CellLocation update without NetworkLocation update (when Android don't succed to locate the Cell).
By the way, I don't check the validity of NetworkLocation coordinates. Only see that CellLocation was updated.
Can you add it ?
Because you receive CellLocation update before the NetworkLocation (Because the LocationManager need the CellID to locate the cellphone). And sometimes, I receive a CellLocation update without NetworkLocation update (when Android don't succed to locate the Cell).
By the way, I don't check the validity of NetworkLocation coordinates. Only see that CellLocation was updated.
ya...@gmail.com
I just tried the requestLocationUpdates workaround and it actually worked for me.
The weird thing is that once I activated Airplane Mode it stopped receiving valid cells (which of course makes sense...) but when I deactivated the Airplane Mode, the requestLocationUpdates no longer worked and I didn't receive any cell updates when the device was asleep.
Could it be that deactivating Airplane Mode does not fully wake the device radio ?? Is it just a ROM-specific issue ? (I'm running CM 7.1) Is there any other way to *realy* deactivate Airplane Mode ?
The weird thing is that once I activated Airplane Mode it stopped receiving valid cells (which of course makes sense...) but when I deactivated the Airplane Mode, the requestLocationUpdates no longer worked and I didn't receive any cell updates when the device was asleep.
Could it be that deactivating Airplane Mode does not fully wake the device radio ?? Is it just a ROM-specific issue ? (I'm running CM 7.1) Is there any other way to *realy* deactivate Airplane Mode ?
yo...@gmail.com
As I understand :
- You launch your application
- Even if the screen if off, the cellid is updated
- You activate, then desactivate AirPlane mode
- The cellid is never updated even if the screen is on ?
CellId received when AirPlane mode is -1 , -1 . Do you receive this ?
When you reactivate AirPlane mode, you should receive immediatly the last know cell (depends on ROM I think, because seems like a bug).
- You launch your application
- Even if the screen if off, the cellid is updated
- You activate, then desactivate AirPlane mode
- The cellid is never updated even if the screen is on ?
CellId received when AirPlane mode is -1 , -1 . Do you receive this ?
When you reactivate AirPlane mode, you should receive immediatly the last know cell (depends on ROM I think, because seems like a bug).
ya...@gmail.com
First 3 steps are correct.
As for the last step - when the screen is on, I receive the location updates as expected (or if I use the SCREEN_DIM_WAKELOCK), but when the screen is off I only receive the last known cell.
And yes, during Airplane Mode I do receive the -1, -1...
As for the last step - when the screen is on, I receive the location updates as expected (or if I use the SCREEN_DIM_WAKELOCK), but when the screen is off I only receive the last known cell.
And yes, during Airplane Mode I do receive the -1, -1...
yo...@gmail.com
You activate / desactivate airplane mode automaticaly with your application when the screen is off ? Or you do it with hand (so screen on) ?
ya...@gmail.com
I turn it on/off manually
yo...@gmail.com
I just test this today, and I don't have this issue.
I turned on Air plane mode some times, and I never loose CellLocation updates.
I turned on Air plane mode some times, and I never loose CellLocation updates.
pi...@gmail.com
Just a quick question for my understanding:
is the Tasker %CELLID variable then just the cached cell id and also doesn't get updated while the display is off?
is the Tasker %CELLID variable then just the cached cell id and also doesn't get updated while the display is off?
pe...@gmail.com
Yes. it is the same variable.
Is it possible to solve this issue for Tasker users or is it only possible for real app inventors who can add special services?
Is it possible to solve this issue for Tasker users or is it only possible for real app inventors who can add special services?
ot...@gmail.com
I really like you pcmalarm. but it can not download on HTC Desire HD at android market!!
It show the device incompatible.
I have two phones, it's work on HTC Sensation XL.
Could you provide the apk file to direct install in on the Desire HD device ??
It show the device incompatible.
I have two phones, it's work on HTC Sensation XL.
Could you provide the apk file to direct install in on the Desire HD device ??
pc...@gmail.com
This is the google thread for an android issue. Mail to pcmalarm@gmail.com for pcmAlarm, thank you!
sa...@gmail.com
I think the problem describes here could be the root cause for the problem described in http://code.google.com/p/android/issues/detail?id=15539 ) which I found first after having difficulties with the update of the signal strength and network registration if an android mobile phone is connected to a car kit.
Here's my comment for
http://code.google.com/p/android/issues/detail?id=15539#c4
No updates are transmitted to the car kit if the screen is off and only the old values are transmitted if the status is requested by the car kit itself.
So it's always a surprise if you start a call using the Hands-Free unit of your car and get the status updates (not available or not) as soon as the screen is switched on by the initiated call (probably in your pocket).
I'm involved in the development of head units at a german automobile manufacturer and this problem is very "android special". I don't know any other up-to-date mobile platform which behaves like this.
With the current behaviour it's not really useful to display the signal strength and network registration in your car if they are so outdated nearly all the time.
Here's my comment for
No updates are transmitted to the car kit if the screen is off and only the old values are transmitted if the status is requested by the car kit itself.
So it's always a surprise if you start a call using the Hands-Free unit of your car and get the status updates (not available or not) as soon as the screen is switched on by the initiated call (probably in your pocket).
I'm involved in the development of head units at a german automobile manufacturer and this problem is very "android special". I don't know any other up-to-date mobile platform which behaves like this.
With the current behaviour it's not really useful to display the signal strength and network registration in your car if they are so outdated nearly all the time.
ms...@gmail.com
Why does Llama not seem to have this problem. It works flawlessly - it plays a sound whenever my train approaches designated cell towers a mile or two before my station (of course while screen is off).
What is Llama doing that Tasker is unable to?
What is Llama doing that Tasker is unable to?
ke...@gmail.com
Llama uses a god-awful hack to trick the phone into sending cell updates. Every 5 minutes (or whatever your 'cell polling' settings are set to), Llama will start a proximity alert for one second. This is the only location API that suggests it can work with the screen off:
http://developer.android.com/reference/android/location/LocationManager.html#addProximityAlert(double , double, float, long, android.app.PendingIntent)
"In case the screen goes to sleep, checks for proximity alerts happen only once every 4 minutes. This conserves battery life by ensuring that the device isn't perpetually awake."
However, this is not without issue. Some phones refuse to send location updates with the screen off, despite that API saying that they are supposed to.
Additionally, if the proximity alert was left active forever, some phones will stay awake forever (draining battery) because of a wake-lock. That API also uses GPS, so if GPS is enabled then GPS would be in use forever (more battery drain).
"In case the screen goes to sleep, checks for proximity alerts happen only once every 4 minutes. This conserves battery life by ensuring that the device isn't perpetually awake."
However, this is not without issue. Some phones refuse to send location updates with the screen off, despite that API saying that they are supposed to.
Additionally, if the proximity alert was left active forever, some phones will stay awake forever (draining battery) because of a wake-lock. That API also uses GPS, so if GPS is enabled then GPS would be in use forever (more battery drain).
ms...@gmail.com
I used Llama extensively. Although it's method is good-awful, it was very effective and perfect in terms of reliablility. But the flexibility and capabilities of Tasker certainly make it very valuable.
Tomi - thanks for the workaround.
Tomi - thanks for the workaround.
ab...@gmail.com
Just wondering. Does this problem only affect Android 2.x, but not 3.x (honeycomb) or 4.x (icecream sandwich)?
pi...@gmail.com
I've got a Samsung Galaxy Nexus with ICS 4.0.4 and got the strong impression that cell updates work now while the screen is switched off (I write a log file while leaving/entering a cell and also have a timed event to write %CellInfo as well). Didn't work on different phones with Android 2.x.
iv...@gmail.com
[Comment deleted]
iv...@gmail.com
I've found a similar issue in ICS. The cellID frequently gets stuck to one cell despite driving for over 10 minutes beside multiple towers.
Closing the app and re-opening it is the only way to "fix" it. It seems to trigger some sort of background refresh about 1-3 seconds after the app is re-opened. App is closed via system.exit, unsure about just backgrounding it. Tests were done over multiple days with screen forced on/full wake lock.
All the above was tested with a Galaxy Nexus and a phone that had 2.3 and was upgraded to 4.0.4. So it is an ICS issue from what I can tell.
Closing the app and re-opening it is the only way to "fix" it. It seems to trigger some sort of background refresh about 1-3 seconds after the app is re-opened. App is closed via system.exit, unsure about just backgrounding it. Tests were done over multiple days with screen forced on/full wake lock.
All the above was tested with a Galaxy Nexus and a phone that had 2.3 and was upgraded to 4.0.4. So it is an ICS issue from what I can tell.
pi...@gmail.com
+1 please fix so apps like can be more effective.
lu...@gmail.com
I tried on CM10 Jelly Bean and the exact same problem (
android ver. 4.1.2
android ver. 4.1.2
ma...@gmail.com
After a couple of days experimenting I concluded the followings in v2.3.6:
- LocationListener does send updates even when screen off (proximity or requestupdate)
- without access to google servers, LocationListener does not generate update events unless internal cache.wifi or cache.cell files contain caching info about the current area
In cache or from google: D/CellLocator( 290): Found cell location: Position [redacted]
Internet disabled: D/CellLocator( 290): Primary cell miss in cache. Need server request.
Upon location success: D/androidNlpServiceThread( 290): reporting Location[mProvider=network,mTime=1361813171057,mLatitude=XXX.XXX,mLongitude=XXX.XXX,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=959.0,mExtras=Bundle[{networkLocationSource=cached, networkLocationType=cell}]]
- listen_cell_location only works when screen is on
I believe google deliberately disables cell_location listener for "long running" apps, so to force developers to use google api for location updates which besides requesting data also generates massive real-time global positioning info. Upon every location request to google the device posts its cell-id and wifi ssids around. This is the reason why the cache expiration of such records are around 24h for cellid and 48h for ssid.
- LocationListener does send updates even when screen off (proximity or requestupdate)
- without access to google servers, LocationListener does not generate update events unless internal cache.wifi or cache.cell files contain caching info about the current area
In cache or from google: D/CellLocator( 290): Found cell location: Position [redacted]
Internet disabled: D/CellLocator( 290): Primary cell miss in cache. Need server request.
Upon location success: D/androidNlpServiceThread( 290): reporting Location[mProvider=network,mTime=1361813171057,mLatitude=XXX.XXX,mLongitude=XXX.XXX,mHasAltitude=false,mAltitude=0.0,mHasSpeed=false,mSpeed=0.0,mHasBearing=false,mBearing=0.0,mHasAccuracy=true,mAccuracy=959.0,mExtras=Bundle[{networkLocationSource=cached, networkLocationType=cell}]]
- listen_cell_location only works when screen is on
I believe google deliberately disables cell_location listener for "long running" apps, so to force developers to use google api for location updates which besides requesting data also generates massive real-time global positioning info. Upon every location request to google the device posts its cell-id and wifi ssids around. This is the reason why the cache expiration of such records are around 24h for cellid and 48h for ssid.
ec...@gmail.com
I also got same problem with 2.2 and 2.3.x
But when i try running using the 4.x devices, my apps works well. Seems like version issue can be a cause.
But when i try running using the 4.x devices, my apps works well. Seems like version issue can be a cause.
fa...@gmail.com
[Comment deleted]
de...@email.com
It seems to work fine on my LG Optimus One with Android 2.3.3.
I get updates on LISTEN_CELL_LOCATION even if the screen is off. Then, I use Location Manager to get the current position on Network Provider.
The cellID is also updated when LISTEN_CELL_LOCATION is triggered.
I get updates on LISTEN_CELL_LOCATION even if the screen is off. Then, I use Location Manager to get the current position on Network Provider.
The cellID is also updated when LISTEN_CELL_LOCATION is triggered.
jo...@gmail.com
I believe I am having the same problem but cannot be certain. My app runs a service with a partial wakelock and periodically it attempts to get the location. My service is even running in the foreground. If the screen goes off, it does seem to get the location but only for a while. If I leave the screen off for a long period (probably 30 minutes), it then fails to get the location. It seems as though the device goes into some really deep sleep and prevents the location from getting updated. But at the moment I turn the screen on, then it is able to get the location. This is running on Android 2.3.6.
jb...@android.com
[Comment deleted]
Description
LISTEN_CELL_LOCATION.
If the wakelock is PARTIAL, the listener will not receive any cell location
updates. If the wakelock is SCREEN_DIM, the listener WILL receive
updates.
It's not relevant whether the device has power or not.
- What you think the correct behavior should be.
The screen should not need to be on to receive cell location updates.
Tested on Nexus One, 2.2.