CID info via API and SCREEN_STATE

[andr3jx]

We know that Google has more accurate information about cell towers in comparison to OpenCellID. I did some research on their non-public api. I downloaded Gmaps.apk and decompiled it to smali. There I found a url "http://www.google.com/glm/mmap", which I googled. Here info how to use this api (redundant):

http://www.open-electronics.org/how-to-find-the-location-with-gsm-cells/ (later I realized that it was already posted here).
https://code.google.com/p/birdnest/source/browse/branches/gae/birdnest/glm.py?spec=svn82&r=82
https://gist.github.com/creotiv/3713832
http://www.codeproject.com/Articles/31965/Learn-How-to-Find-GPS-Location-on-Any-SmartPhone-a
https://code.google.com/p/mwop/source/browse/sandbox/server/mwop-server/src/com/mwop/server/cellID/AbstractCellIDProvider.java?r=18
http://cdacians.blogspot.de/2012/08/convert-celllocation-to-real-location.html

So what we can do is simply use their hidden api to check if they have a particular cell in their database and if they do we can get GPS coordinates of the cell + submit it to OpenCellID. We can also get the coordinates of Neighbour-Cells and calculate a more or less precise location based on signal stregth of the cells. The question is how reliable is Googles mobile network info? If we have a cell which is not in Google's database, it could be an indicator that it is an IMSI Catcher.

It would be better if we could download all mobile network info in an area. I'm interested which data is stored in Google's offline maps and if it is possible to access this data somehow. I tried to intercept offline maps data but couldn't bypass SSL encryption (Certificate pinning and other problems). But I found these tools so I'm sure there is a way to bypass SSL or attach a debugger to GMaps.

There is also the official Google Geolocation API, but you need to pay for an API key.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[andr3jx]

I decided to get a little in android coding. Here my first android code: I took Mobilog and modified it so that it can obtain the GPS-coordinates of mobile networks (including neighbour cells) using Google's API.

But you need to compile it yourself, I haven't learned yet how to sign apks. At first I thought I try to modify our application but it doesn't work on my android 4.4.4 system. It is not able to obtain network information and doesn't display neighbour cells. The map viewer crashes the application although I have GMaps installed - still too many bugs.

I will see if I can add more cool things in Mobilog. (( Screw you all, I will write my own IMSI-Catcher Detector 100% optimized for MTK using openstreetmaps, and let it switch to 3G-only when I want to make calls (which I don't really need because I use always SIP calling) :P )) If I get skilled enough, I will see if I can help with developing our app. (( Do you want to pay me with my donated Dark Coins? xD ))

[SecUpwN]

@andr3jx, thanks for your extensive research and deep digging on Mobilog! Now, before you develop you own IMSI-Catcher, I'd be happy if you stay with us on our Project. 😺 Is there anything I can help you with? Feel free to send me your DarkCoin address through XDA. Once we have enough donations (unfortunately not yet) I'll send you a piece of the pie. Cheers and keep on coding awesome stuff!

[E3V3A]

Yes, Danilo Valerio's Mobilog is a very nicely made app, accompanied by some very informative and well written design notes. Of particular interest is the following passage:

• Log RSSI: If enabled, each logged data point will also contain the measured RSSI (Received Signal Strength Indicator) from the current cell. PLEASE NOTE that the Android operating system provides RSSI through the API, ONLY AND ONLY IF the screen is ON. Therefore, if this option is enabled the application will try to keep the screen ON (but at minimum brightness) by acquiring a wakelock. If you switch off the screen (for example by pressing the power button) the RSSI value will not be updated anymore (at least as of Gingerbread).
• Log neighboring cells: If enabled, each logged data point will also contain the list of neighboring cells including the respective measured RSSI (therefore screen on). In case of a 2G network, neighboring cells will be identified by their cell-ID. In case of a 3G network, neighboring cells will be identified by their PSC (Primary Scrambling Code).

We need to verify if this is still true for API > 17.
Which is also why I was concerned with the SCREEN_STATE IPC.

[andr3jx]

@SecUpwN Of course I will stay on our Project ;). If I can make something work on Mobilog, I can port it later to our app, but now I'm not ready to deal with so many bugs in our app.
@E3V3A
I will see if I can change target API and test if it works, but probably I will have to fix some deprecated methods.
OT alarm I did some googling and found this mozilla site. I don't know if it is news for you:

"Due to wanting a single event source for dealing with events, the rild socket requires exclusive access from a single process. In a normal android installation, this would happen via the com.android.phone process. In order to make our own code talk to the socket, the current strategy is to change the socket name in the RIL.java file to something other than "rild" (since we can't recompile vendor specific rild). "

"The initialization step is required to turn the radio on. - Program connects to rild socket - Radio: UNSOL_RESPONSE_RADIO_STATE_CHANGED with radio status - Program: SCREEN_STATE to TRUE - Program: RADIO_POWER (Turns radio on, if radio status is RADIO_STATE_OFF) "

There is also an app screen standby root, which can switch off the screen without putting the device into sleep mode.

[E3V3A]

@andr3jx Yes, for that App, I think the HW switching check is done here.

    public GenericHardwareObserver (String hardware_switch_name) throws HardwareNotFoundException {
     HARDWARE_UEVENT_MATCH = "DEVPATH=/devices/virtual/switch/" + hardware_switch_name;
     HARDWARE_STATE_PATH = "/sys/class/switch/" + hardware_switch_name + "/state";
     HARDWARE_NAME_PATH = "/sys/class/switch/" + hardware_switch_name + "/name";
     mHardwareSwitch = hardware_switch_name;
        mChangeHandlers = new java.util.ArrayList<UEventStateChangeHandler>();
        init();
    }

[Diapolo]

Let me ask, after the switch over to OSMAnd, is this issue a non-issue?

[E3V3A]

@Diapolo OSM has nothing to do with this.
@andr3jx @He3556 @SecUpwN Do we need to close and open a new issue about this?

[SecUpwN]

@E3V3A, I am all against scattering all the useful Information into thousands of Issues. Please rename this Issue appropriately to fit the current state and development without GMaps API. Thank you.

[E3V3A]

We need to understand the current status of this.

Does our app collect correct signal data after going to (or during) sleep, where screen is off?

[SecUpwN]

Does our app collect correct signal data after going to (or during) sleep, where screen is off?

It hurts admitting this, but even I don't know for sure. @tobykurien, do you know?

[tobykurien]

I haven't tested it, so I can't say for sure, but in theory, yes it should continue collecting data, due to the listener here: https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/blob/master/app/src/main/java/com/SecUpwN/AIMSICD/service/CellTracker.java#L438

[SecUpwN]

@andr3jx since you opened this Issue, what is the current status of this?

[E3V3A]

Can someone please test the status of this? (I'm not sure what to look for here...) Can we close this?

[andr3jx]

The core of this issue is to find out if the app collects correct data while the screen is off.
Following questions need to be answered:

1. Does the app collect all available data (LAC, CID, Neighbor cells etc.) while the screen is off?
2. Does the app record all changes of the values while the screen is off?
3. Are the collected values correct?
4. Is it the case for all the devices we want to support?

These questions can be answered by debugging the app / logging + using a second device to check if the collected values are correct. This needs to be properly checked because the info I found shows that problems occur when you collect cellular data while the screen is off:

"You’ve mentioned that the screen needs to be on. Does the app not collect data when the screen is off?
No, the app does not collect data when the screen is off on Android, except if you have experienced a dropped call. On some Android phones, there are bugs when trying to get signal data when the screen is off, so if we include this data it would skew the data." SOURCE

"NOTE that the Android operating system provides RSSI through the API, ONLY AND ONLY IF the screen is ON. Therefore, if this option is enabled the application will try to keep the screen ON (but at minimum brightness) by acquiring a wakelock. If you switch off the screen (for example by pressing the power button) the RSSI value will not be updated anymore (at least as of Gingerbread)." SOURCE

"Due Android limitations it's necessary to have screen on during monitoring." SOURCE

[He3556]

yes, i would like to have that cleared, too
wouldn't it be ok, to use only one device? I know the CellID's around me anyway.

[andr3jx]

yes, you can also e.g. go from A to B keeping the screen on and then go from B to A with switched off screen. In the end you compare if you collected the same data. Take into account that there can be some differences because handovers can happen on different locations.

[He3556]

sorry we have to close a few issues - if this still needs clarification pls let me know.
Did somebody check:
"The core of this issue is to find out if the app collects correct data while the screen is off.
Following questions need to be answered:

1 Does the app collect all available data (LAC, CID, Neighbor cells etc.) while the screen is off?
2 Does the app record all changes of the values while the screen is off?
3 Are the collected values correct?
4 Is it the case for all the devices we want to support?"

maybe we need to add a table with phones that are checked?

[SecUpwN]

1 Does the app collect all available data (LAC, CID, Neighbor cells etc.) while the screen is off?
2 Does the app record all changes of the values while the screen is off?

I guess that our app does, given the fact that the locked phone launches the short vibration on CID changes. Adding yet another table with phones will do no good. And see this on device support. ;-)

[andr3jx]

Hi Sec,
I loaded the currect code into Android Studio and added additional logs for recording the obtained network information. My tests show that that cellular network information like CIDs, neighboring cells and signal strength are not obtained or not updated while the screen is off. When the screen is turned on the data gets updated immediately.

Conclusion: AIMSICD can't detect threats while the screen is off (and actually never could). I can file a new bug but it's very sad to know that nobody paid attention to this issue.

Of course if anybody can prove me wrong by verifying that this is really not the case I will be very thankful.

[SecUpwN]

Good morning @andr3jx, thanks for running these important tests! If our app does not analyze the network variables while the screen is off, why does the phone vibrate when set to vibrate on any CID change then? Indeed, our app would be pretty useless if nothing gets analyzed while the screen is off. How exactly did you run your tests? Maybe @smarek can verify your findings?

[andr3jx]

Why does the phone vibrate when set to vibrate on any CID change then?

Can you show me the code where it triggers vibration on any CID change? My observation is that the phone only vibrates if there are problems like no neighboring cells for a CID.

How exactly did you run your tests?

First I added additional logs in the code so I see exactly which functions get called.
I added additional logs in these functions:
checkForNeighbourCount, updateNeighbouringCells, onCellLocationChanged, onSignalStrengthsChanged, registerSignalStrength

Then I connected my phone over adb and monitored what gets logged when the screen is on and when the screen is off.
I also recorded some logs today while taking a trip through the city and the logs show that Signalstrength, CID, Neighbor cells are null, -1, or are not changing while the screen is off (CID doesn't change value).

But more interesting is the question if really somebody can confirm that this is definitely the case or not the case for your devices (maybe this problem occurs only on my device).

This behavior is known, multiple sources cited in my post confirm this.

[He3556]

Sorry @andr3jx i don't know why we left this conversation.
Could you just send us your .apk?
i will test it and maybe some others too?

[andr3jx]

You can download apk and source code here:
Download from MEGA hoster

[andr3jx]

I also did now a quick test on my Nexus 7 3G (2012) running Android 5.1.1

Here is a logcat:

======= Switch to Flight mode ===================
11-23 01:23:34.986 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CellLocationChanged - CID: -1
11-23 01:23:34.987 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CheckForNeighbourCount()
11-23 01:23:37.786 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: NCInfo count 0 (size = 0)!
11-23 01:23:37.805 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: ALERT: No neighboring cells detected for CID: **03
11-23 01:23:37.960 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: ToEventLog(): Added new event: id=4 time=20151123012337 cid=**03
======Switch Flight mode off and put screen off immediately (before it connects to BTS) ========
11-23 01:23:49.450 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CellLocationChanged - CID: 0
11-23 01:23:49.450 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CheckForNeighbourCount()
11-23 01:23:56.905 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: NCInfo count: 1
11-23 01:23:56.905 9844-9844/com.SecUpwN.AIMSICD D/CellTracker: NeighbouringCellInfo size: 1
11-23 01:23:57.493 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: SignalStrengthChanged: 99
11-23 01:23:57.493 9844-9844/com.SecUpwN.AIMSICD I/AIMSICD: registerSignalStrength - CID: 0 Signal: 2147483647
11-23 01:23:57.493 9844-9844/com.SecUpwN.AIMSICD I/AIMSICD: SignalStrengthTracker: Ignored signal sample for CID: 0 due to device movement. Waiting for 29999 ms.
11-23 01:23:57.495 9844-9844/com.SecUpwN.AIMSICD I/location: Last known location ***
11-23 01:24:00.029 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_bts was populated.
11-23 01:24:00.047 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_measure inserted bts_id=0
11-23 01:24:17.898 9844-9844/com.SecUpwN.AIMSICD I/location: Last known location ***
11-23 01:24:20.203 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_bts updated: CID=0 LAC=0
11-23 01:24:20.294 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_measure updated bts_id=0
11-23 01:24:20.330 9844-9844/com.SecUpwN.AIMSICD I/location: ***
11-23 01:24:38.246 9844-9844/com.SecUpwN.AIMSICD I/location: ***
11-23 01:24:40.022 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_bts updated: CID=0 LAC=0
11-23 01:24:40.044 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_measure updated bts_id=0
11-23 01:24:40.491 9844-9844/com.SecUpwN.AIMSICD I/location: Last known location ***
====Switch Screen on ====
11-23 01:24:46.371 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: SignalStrengthChanged: 24
11-23 01:24:46.371 9844-9844/com.SecUpwN.AIMSICD I/AIMSICD: registerSignalStrength - CID: 0 Signal: 24
11-23 01:24:46.371 9844-9844/com.SecUpwN.AIMSICD I/AIMSICD: SignalStrengthTracker: Ignored signal sample for CID: 0 due to device movement. Waiting for 24116 ms.
11-23 01:24:46.429 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CellLocationChanged - CID: **03
11-23 01:24:46.429 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: CheckForNeighbourCount()
11-23 01:24:46.461 9844-9844/com.SecUpwN.AIMSICD I/CellTracker: NCInfo count: 7
11-23 01:24:46.461 9844-9844/com.SecUpwN.AIMSICD D/CellTracker: NeighbouringCellInfo size: 7
11-23 01:24:46.463 9844-9844/com.SecUpwN.AIMSICD V/AIMSICDDbAdapter: LAC checked - no change on CID:**03 LAC(API): **0 LAC(DBi): **0
11-23 01:24:58.438 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_bts updated: CID=**03 LAC=**0
11-23 01:24:58.456 9844-9844/com.SecUpwN.AIMSICD I/AIMSICDDbAdapter: DBi_measure updated bts_id=**03

[He3556]

good that i saved the email with a link to this issue :) it's a jungle out there!

when i switch off the display:

11-24 02:09:25.781    1053-1053/? D/AIMSICD﹕ BaseActivity: StatusWatcher stopped watching
11-24 02:09:27.623    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:09:27.633    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx79
11-24 02:09:31.838    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:09:31.868    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx79
11-24 02:09:37.824    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:09:37.844    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx79
11-24 02:09:38.605     839-1171/? I/LocationManagerService﹕ remove com.SecUpwN.AIMSICD 43224ae8
11-24 02:09:38.705      839-965/? D/LocationManagerService﹕ request 430efaa0 gps Request[ACCURACY_FINE gps requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:09:38.705      839-849/? D/LocationManagerService﹕ request 430efaa0 passive Request[POWER_NONE passive fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:09:38.715     839-1171/? D/LocationManagerService﹕ request 430efaa0 network Request[POWER_LOW network requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:09:38.985    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:09:39.005    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx79
11-24 02:09:55.293    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:09:55.353    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx79
11-24 02:09:58.706     839-6572/? I/LocationManagerService﹕ remove com.SecUpwN.AIMSICD 430efaa0

thats all - there is no log until i move the phone. Than the routine gets triggered to prevent signal strength measurement.

11-24 02:18:16.978     839-1177/? D/LocationManagerService﹕ request 430efaa0 gps Request[ACCURACY_FINE gps requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:18:16.988      839-965/? D/LocationManagerService﹕ request xxx538 passive Request[POWER_NONE passive fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:18:16.998     839-1171/? D/LocationManagerService﹕ request 430efaa0 network Request[POWER_LOW network requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-24 02:18:20.692    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx45 LAC=xx71
11-24 02:18:20.702    1053-1053/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx45

Just for me, to remember: Didn't we implement some service task that keeps running in the background, when the App is working in the background?
And the actual problem was, that some custom Android roms doesn't update status information about the mobile network, when the display is switched off?

[andr3jx]

it's a jungle out there!

You can sort the issues by "recently updated" to see if something new got added.

One line remains the same so it is not clear if the API only returns the same CID(until the screen is switched on) or if there was really no CID change. (on my phone the first is the case).

11-24 02:09:37.824 1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx79 LAC=xx71
11-24 02:18:20.692 1053-1053/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx45 LAC=xx71
Have you switched the screen on between these two logs? (you forgot to remove the bts_id at the end.)

there is no log until i move the phone.

Can you keep the phone moving or change the refresh rate from automatic to 10 seconds?

Are neighboring cells not obtained while screen is off? It's also not good if signal strength measurements can't work.

Can you perform my test procedure? Switch Flight mode off and put screen off immediately (before it connects to BTS).

Just for me, to remember: Didn't we implement some service task that keeps running in the background, when the App is working in the background?

Yes, the service works but it doesn't mean that all APIs work while the screen is off.

And the actual problem was, that some custom Android roms doesn't update status information about the mobile network, when the display is switched off?

Not only custom roms but also stock roms.

[He3556]

When i switch off the display and keep moving the phone it's updating the DBi_bts

11-27 12:30:02.712  16253-16253/? D/AIMSICD﹕ BaseActivity: StatusWatcher stopped watching

11-27 12:30:16.726  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx77 LAC=xx71
11-27 12:30:16.736  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx77
11-27 12:30:19.449  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx77 LAC=xx71
11-27 12:30:19.469  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx77

11-27 12:30:35.146  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx76 LAC=xx71
11-27 12:30:35.156  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx76
11-27 12:30:36.778  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx76 LAC=xx71

When i switch off the "Flight Mode" and turn off the lights i get CellID= -1

1-27 12:45:21.542  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx77 LAC=xx71
11-27 12:45:21.552  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx77
11-27 12:45:39.361      835-846/? I/LocationManagerService﹕ remove com.SecUpwN.AIMSICD 42919bc0
11-27 12:45:43.415     835-1339/? D/LocationManagerService﹕ request 4336f820 gps Request[ACCURACY_FINE gps requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-27 12:45:43.415      835-972/? D/LocationManagerService﹕ request 4336f820 passive Request[POWER_NONE passive fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-27 12:45:43.425     835-1336/? D/LocationManagerService﹕ request 4336f820 network Request[POWER_LOW network requested=+10s0ms fastest=+10s0ms] from com.SecUpwN.AIMSICD(10217)
11-27 12:45:44.597  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=xxx77 LAC=xx71
11-27 12:45:44.607  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx77

======Switch Flight mode off and put screen off immediately ========

11-27 12:45:45.177  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=-1 LAC=-1
11-27 12:45:45.187  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=-1
11-27 12:45:51.003  16253-16253/? I/AIMSICD﹕ registerSignalStrength - CID: -1 Signal: 15
11-27 12:45:51.003  16253-16253/? I/AIMSICD﹕ SignalStrengthTracker: Ignored signal sample for CID: -1 due to device movement. Waiting for 22412 ms.
11-27 12:45:51.494  16253-16253/? V/AIMSICDDbAdapter﹕ LAC checked - no change on CID:xxx77 LAC(API): xx71 LAC(DBi): xx71
11-27 12:45:59.713  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_bts updated: CID=***77 LAC=xx71
11-27 12:45:59.723  16253-16253/? I/AIMSICDDbAdapter﹕ DBi_measure updated bts_id=xxx77

I don't get any information about the neighbouring cell list in this log.

When you switch off the display and don't move the phone - does it also stop producing any log?
Maybe we should trigger the logging of signal strength when the phone is not moving. Right now we trigger the movement and discard the measurements of signal strength.

[andr3jx]

When you switch off the display and don't move the phone - does it also stop producing any log?

I checked now, yes it stops logging. If I keep moving then eventually last known GPS location is logged.

Maybe we should trigger the logging of signal strength when the phone is not moving. Right now we trigger the movement and discard the measurements of signal strength.

Yes this might be worth a try.

Good to know that at least on some phones CID and LAC can be obtained. Still it's not good that signal strength and neighboring cells are not logged.
We should also add something for debug purposes which displays what kind of data was obtained while the screen was off when you wake your device.