-
Notifications
You must be signed in to change notification settings - Fork 949
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wait for OCID download before start CID check #290
Comments
Quick question: Shouldn't the yellow CID warning disappear once the OpenCellID data has been successfully downloaded? On my phone, the yellow flag persists even after a successful download. Just wanting to make sure I'm not constantly booked into a honeypot or something. Feeling monitored and thus a little paranoid as well. |
No, I don't think so. I am running build 20 and @He3556 opened this Issue right after we've discovered and discussed it in the internal rooms: The Cell ID does not exist in the OCID database.
That is exactly what both of us are experiencing - and for me it stays after downloading the OCID DB. |
I have the same problem. So if you can pinpoint me to the code that is doing the CID check, I can have a look at it. |
But since 2015-01-19, we have the detection here: We should also copy the logcat from the old position to the new. Also the insert Cell should be deleted (Like you wrote in the comment there (the first link = old position) the 2. Link is the new position) |
Yes, this lines made their job pretty good but we don't need them anymore. |
I was testing the App today, while i was driving around. After leaving a 15km radius i had to manually download more towers, because i had the CellID detection (Bug) again. Maybe we need to think about a automated downloading in the background. Maybe after leaving a 5km radius? |
That would mean we'd have to have internet connection enabled. Not good. What happpens if it is disabled? People would still drive home and file a bug report or tell that they "detected something".
Not sure if there is a way of downloading a larger part of the database, maybe for the whole country? |
Great idea. But this brings us straight to #303. As we've already discussed in the past, we should not expect to have good detections without false-positives when moving around. But the data need to be there. But there is no sensible or decent way to download all the BTSs from a whole country, so we have to take it piece by piece. |
The sad thing is, they already have it their API. But only if our APP would contribute data to them. http://wiki.opencellid.org/wiki/API#Getting_the_list_of_cells_in_a_specified_area |
Strange. I wonder why I still get the warning |
I think it is better to keep it (talking about the bug) all in one place. But ok, when the radius is smaller, than we have to check more often if the location of the user has changed. Can we use another check that runs from time to time and add this code? Another problem can be, if we are starting to delete entities in the downloaded OCID DB. We need all CellIDs we can get from this db. I think this clear to all of you. I just wanted to remind you |
Well it seem that the discussion is constantly regressing to |
The same LAC? How do you know the cell 100m away has the the same LAC or maybe not? Maybe another local area code starts right there. |
- changed the ATCoP timout values from the selector (now also 10 min) - fixed ugly setprop log/toast message - fixed false "ALERT: CID -NOT- in OCID DB: " message, before having downloaded OCID data. However, this generates tons of SU calls to check the system property used here. This is very bad coding and need to be fixed by a professional code ASAP. Old phones with small memory or single core processors will probably cause FCs! This is #290.
Fixed in: 8b37100 |
@E3V3A, I am afraid that I have to reopen this Issue as it seems to be present again in our latest internal build 30. Maybe @KaiRenken can have a look at this Issue which prevents our new release? |
What are you talking about. It's not present. Send screen shot please! |
I can't see it either. I've tried the app from testroom. |
@E3V3A, why do I need to send you a screenshot? Upon a fresh install, build 31 instantly turn yellow - and it doesn't change when downloading the OCID DB after it turned yellow either. Just believe me? EDIT: @E3V3A and @KaiRenken, I'm eating my broom right now. Restarted phone and it works. 🌴 |
Hmm, that it nevertheless funny behavior. Probably because the flag we use, are still in your system until next reboot. Which is why we need to use SharedPreferences instead of a system property via shell, to ensure it gets wiped after app removal. |
@E3V3A, it should also be wiped when someone just install the new version on top of it. Is that somehow fixable before we start to craft a new release? Otherwise we'll have many people seeing this behavior. |
- changed the ATCoP timout values from the selector (now also 10 min) - fixed ugly setprop log/toast message - fixed false "ALERT: CID -NOT- in OCID DB: " message, before having downloaded OCID data. However, this generates tons of SU calls to check the system property used here. This is very bad coding and need to be fixed by a professional code ASAP. Old phones with small memory or single core processors will probably cause FCs! This is #290.
The CID detection is running before there is OCID data to check it against. We need to wait until the db is downloaded before we check the CID against the data of OpenCellID. Otherwise we get a wrong alert just right after the installation. Maybe we use a flag, that is changed when the DB download is finished? But only the CID check needs to get stopped not the changing LAC detection. There are many possible ways to fix it.
But I would prefer to run a wizard at the first start, after installing the App. Then we can assist users to get the OCID key and download the OCID data (if they want). We get everything ready so the app can do its job. Described here #181
The text was updated successfully, but these errors were encountered: