Smashing Bugs for WIP-Release v0.1.25-alpha #65
Comments
|
@SecUpwN Thanks for taking the time to re-fresh this list. I've been too busy lately looking into these details again. Indeed many of these have not yet been resolved, I checked-off a few, but I have not checked all of them, since these checks require a clean/first install without any data. Please feel free to test yourself. |
|
@E3V3A and @SecUpwN: Hey guys sorry I have been MIA recently but I have my final two assignments due this week which are the last for this semester followed by exams in June, I will be able to spend more time on this after Wednesday this week. Unfortunately I am not enjoying the beginning of summer but the beginning of Winter and although it has not started yet it is already getting pretty damn cold! I will go through this and the other issues to bring them up to date and will try and address the majority of these outstanding bugs with the next release, one thing I was working on and I believe I am close to getting implemented is the AT command injection but it does use the Samsung MultiRil methods which I have extended to use the Strings method. As you know this is Samsung specific so for full compatibility we really need some other method such as terminal execution etc but this might give us the first step in the AT command direction. |
|
@xLaMbChOpSx Excellent! Good to hear and good luck for all your exams. I'll try to not bother you again until we hear from you next time. |
|
Thank you for your short update @xLaMbChOpSx - this relieves the feeling that you got tired of developing or are mad ad someone here. You know, people from the XDA community tend to think people are dead if they don't update a thread for several weeks.. 😄 @E3V3A, yes, indeed I will! As you can see, all is good and everybody here is just having a life. Man, I can't wait to see the full scope of your draft proposal being implemented - we're gonna punch the bad guys so hard! ^^ |
|
Ok here we go with the bug smashing, I have ticked some items but will fully explain everything below:
Reported bugs from WIP-Release 0.1.10-alpha, Issue #49
Reported bugs from WIP-Release 0.1.11-alpha, Issue #53
Reported bugs from WIP-Release 0.1.13-alpha, Issue #58
Reported bugs from WIP-Release 0.1.14-alpha, Issue #62
|
|
@xLaMbChOpSx Hello! Excellent, but a few comments/corrections. In 0.1.13-alpha, Issue #58: This explanation was poorly written by me. (Please have another look the comment therein.) The issue is that collecting cell data without an accompanying accurate GPS location, is useless without further radio variables, and even then still not sure. So the idea behind the issue is that enabling cell tracking, must be accompanied with the requirement of also enabling GPS location tracking, and when I say tracking here, I mean to actually save the GPS data in our DB tables (as is done). However, disabling cell tracking, should not automatically disable GPS functionality/location determination on the device, since the user may run other programs using this feature. That's why I said that the extra "location" icon may be redundant, since if GPS is turned on, it is already present on top/menu bar. Thus the reverse logic of what you wrote above, is correct behavior. For 0.1.8-alpha, Issue #44: You wrote: "Database helper has been significantly updated to ensure only unique entries are inserted, entries that already exist will be updated with the new information such as changed signal strength etc." This doesn't seem correct at first thought. Can you clarify what you mean with unique? "...If only time-stamp has changed since last entry, an nothing else, then try to keep only the 1st and the last [consecutive] entries. This gives us a time-span to work with, without filling DB." This is in fact unusual, and probably only possible for a phone laying on a table, so there need to be some kind of timer of let's say 1-10 minutes that checks and adds a "last seen" DB record, in case nothing else has changed. I hope this helps clarifying. But I'd be happy to discuss more if necessary. |
|
Ok I will redo the things you mentioned tomorrow I need to get some sleep. |
|
@xLaMbChOpSx, awesome work squashing mentioned bugs! I'm sure all these will have vanished with version 0.1.20-alpha. Hold your head up high, I'm proud of you! 👑 @E3V3A, thanks for clarifying. |
|
@E3V3A Ok I now understand correctly what you mean regarding the Cell/Location tracking basically if cell tracking is enabled then location services must all be enabled so when tracking Cell ID information an accompanying longitude and latitude is recorded. I will make this update tonight but will also remove the location tracking database and my reasoning behind this is that from the original Raw Phone setup which we began with we had a table for Cell information and a table for location information which captured the same detail yet were enabled through the two different functions. So basically if location was off and cell tracking was enabled the cell table would contain cell id information with 0.0 for the location details, then when location tracking was enabled the location table would contain cell id details and the appropriate location details. With this change we will have a single table that holds all the current information we capture but it will ensure any entry contains ALL fields (Cell ID, Longitude, Latitude etc). I will post another comment once this part is finished to discuss the second issue and what I propose for that, I will try and fully implement the timer functions so this can be tied into this section and also what we agree as the minimum value to be used for considering what is a change in location e.g. 10 metres etc so we don't have thousands of entries with insignificant GPS movements etc. |
|
@xLaMbChOpSx Exellent. Yes, this can be very confusing. The main reason for confusion is probably the difference between the "real" CellTower location, the "perceived" cell tower location and your phone "exact" GPS location. This could also be the reason behind the separate tables in the RawPhone app. So at the end of the day, we should end up with at least 2 (and maybe 3) lat/lon location values, in our DB tables, each set representing:
PS. It is also very important to distinguish GPS location and lat/lon location. I admit I have been sloppy and mixing these two terms in other/older posts. GPS is a measured value that can easily get thrown off by geomagnetic storms and government interference etc., while lot/lon is a fixed map coordinate, that doesn't change unless there's tectonic plate movements... |
|
@xLaMbChOpSx I've got an FC due to out of date Google Play servies. (see OP) Are you still using SlimKat? |
|
@xLaMbChOpSx Are you sure you uploaded the right version? It seem to have the same problems as the previous version...including the version number! |
|
@E3V3A, I noticed that, too. Hope @xLaMbChOpSx can somehow update his submitted release.. |
|
@E3V3A @SecUpwN About the OpenCellID issue added I can provide the following information, basically without some form of location data it is impossible to request anything from the OpenCellID database as the API requests require geo coordinates in our case a bounding coordinate for a specific point. Current AIMSICD attempts to find any form of cached location before showing the message that location services are required, it attempts to find the cached location through the Location Manager method of getLastKnownLocation which initially tries the GPS_PROVIDER and falls back to the NETWORK_PROVIDER if nothing has been found. If at this point no cached location data has been found then I have no other option then to request the user enables location services so a location can be found. The Google Play services library which is currently used for the Map Viewer provides an updated fused location service which will provide locations from any of the providers but it faces the same issue if getLastKnownLocation is null then the only option that is available to get a location is through enabling location services. The telephony manager class provides a method for retrieving a location (lat/lng) from CDMA devices through the CDMACellLocation object BUT from looking at this function in the AOSP source the location component of this is removed if the user has disabled location services which again leads us back to the need at some point for location services to be enabled. If there is another way to gain a location that I have missed I would be more then happy to implement that solution into the app but at the moment I know no other way then what I have detailed above. |
|
@xLaMbChOpSx ... Aha, I see. So it looks as we're back to Google/Mozilla and LAC/CID positioning again... Oh, no wait, we can also try IP address location. That should work sufficiently, at least when we are not using VPN. Also, I updated OP with problem of app not closing (at all) on my I9100 4.4.2. |
|
Not sure if this is possible, but maybe we can improve positioning to be battery friendly? When running around with GPS turned on, my phone is dead within a few hours, whereas it normaly lasts all day long... |
|
@xLaMbChOpSx @SecUpwN : I don't know what is going on, but some more things are broken in this version. xLaMbChOpSx, Bugs from WIP-Release 0.1.18-alpha, (not reported) EDIT by @SecUpwN: Bugs merged into OP for final review. Summary: This version is harder to test on this device. Possibly because of the Enforcing mode, which prevent access to many file locations and other operations. More tests needed with SELinux settings in Enforcing versus Permissive modes, including setting full access to (via EFS files) to the ServiceMenu items. EDIT: 2014-06-15 EDIT by @SecUpwN: Bugs merged into OP for final review. Summary: Most things that was causing crashes for the I9195 above, is working on this device, apart what is mentioned above. Neighboring cells look better and more clear. More testing needed. (I have a very bad battery and no gps-lock near outlet.) |
|
@E3V3A No I never test anything I contribute I just write random shit until the app successfully compiles, you have a very strange way of dealing with people who are contributing to your project especially now that I have had the chance to read the xda thread. Sorry you feel I have been withholding the AT command access from you but as ALL of my commit messages, release comments and issues comments have stated it currently DOES NOT FUNCTION hence the reason it is disabled, I have attempted to extend the MultiRil implementation to incorporate the OEM_STRINGS method and also investigated how to convert the AT command string into an acceptable OEM_RAW request but have not been successful. Good luck with your project. |
|
@xLaMbChOpSx i feel with you. But "I just write random shit until the app successfully compiles" sorry, i had to [edited] - smile a little bit - . Good to see you still have sense of humor. |
|
@He3556, even though it sounds funny, this is very serious. We're about to lose our best man here. Dear @xLaMbChOpSx, on behalf of @E3V3A and all other team members, I would like you to accept my SINCERE APOLOGIES for the lack of communcation that obviously has happened between the two of you. I deeply feel sorry for all this bullshit in between, I really DO NOT want to lose you as developer, as contributor and collaborator. You've been driving this project forward, constantly, always with superb commit messages, polished code (although you never really coded on such a large projects before) and even with that little spare time you had. I am extremely thankful for all the things you've been accomplishing so far, otherwise we'd probably still be discussing theories of this App on XDA. I'm sure @E3V3A will make also make his point clear here, but let me say this: I have been receiving multiple PMs by him via XDA where he expressed his ongoing worries and emotions on not getting any sign of life through his messages to you. I know that he felt like being left alone, but maybe you just didn't lurk around on XDA too often. Which other (better) way of communicating should we have chosen? People are emotional beings, hence why he slowly thought you might not be with us any more. Clearly a lack of communication, added by emotions and thoughts circulating around the question what's going on. So please, DO NOT LEAVE US. We've got a bright future ahead of us and I really want to experience it together with you. Please forgive the strong voice @E3V3A has at times, he says from himself to be very emotional at times. We all have to work on something, right? If there's anything we can do to make communication among members and collaboration on coding better in the future, let me know ASAP! I would like to keep my promise and send you the first donation NOW. What's your DarkCoin address? |
|
I installed it today on a HTC Wildfire (custom rom) and everything looks great (ok the neighboring cells just shows the number of found cells) i guess the problems depend on the devices people are using. i just found a place for us where we can communicate (private) |
|
Well I'm very sorry to hear that you feel that way. But I also have to insist that I have tried to contact you on several occasions in the last 2 months. Both via XDA PM and the Email you proivided to me, where you also wrote: "Happy to use email for any discussions." After that I sent you 5 more emails, the first one on May 2 and the last one just yesterday, none of which you responded to. I have also sent you PMs which you also did not fully responded to. The only PM I've received from you, was on 17 April, AFAICT, where you said you were going to answer other questions the next day. A similar concern has also been made by @SecUpwN . So regardless of how you like me to verbally respond or express myself, what you say just doesn't add up, when there is no communication at all. And if you're busy or tired, all you'd need to say is, "Guys, I need a break." But say something. Surely clear and effective communication is the the foundation of any team project, and the lack thereof is the main cause of failures in most projects. And Github is not a good place to have developer discussions. We have both surely written one too many repeated questions and answers there, because of the lack of simple overview, and the inherent poor organization of open/closed comments here. It is clear that my verbal diplomatic skills are below average, which is also why @SecUpwN is our designated PR person for this project. But that being said, does not mean I do not greatly appreciate what you or other people are doing or have already done, on the contrary. But I show my love in different ways. In this kind of remote project, that means, by providing as much technical support and assistance as I possibly can. But it also means I do not kiss up to people who volunteer to participate, regardless of what they do or where they come from. Everyone is free to come and go as they please. And the reason is very simple: I'm simply the initiator of the project. You are not serving me or anyone in particular, but you are serving the greater good for a great many people. So you just have to do what you feel is right. But more importantly, it also means that I take a purely technical point of view under my own ethical standards. That is, I'll try to leave emotional opinions and moral issues completely out of the project. As SecUpwN already mentioned, this is perhaps not ideal, as people in general and developers in particular, are very emotional beings. But it is the only way, as I see it, to filter out non-sense discussions and moving forward. It also ensures that I will never use you or step over other people to get my own way. I will give you full credit for all you have done. Finally, I'm all for working out and solving whatever inter-personal issues or relational problems we may encounter, rather than running away. It's the only way to learn about and improve ourselves. |
|
please let me moderate something. There is no way to leave out emotions when you communicate with people. In situations like this, I always try to get the people to read about the "Four-sides_model" + to understand how hard it is, when you are communication with text messages only! |
|
@SecUpwN No problems I will work on these as much as possible and try and address as many as I can over the next day or two. The pre-release version I attached should address a couple of the issues which I can detail when I get home, in particular OpenCellID download and upload should now function correctly, the CID/LAC issues of displaying the Integer MAX value should also be corrected along with the neighbouring cell details. I will go through the entire list and try and get them all sorted so we can close this massive issue once and for all! |
|
I want to say BIG THANK'S to @xLaMbChOpSx ,too!! Really cool that you have time to spend on this project. Please let me know what you think about the implementation of #91 when the time is right for you. |
|
@xLaMbChOpSx Wow wow! Great to hear, and unless SecUpwN has already spilled his guts, we have more good news for you... |
|
I think I already sent @xLaMbChOpSx an E-Mail about my latest accomplishments. |
|
@xLaMbChOpSx |
|
On: HTC One M7 (rooted AOS 4.4.2)
Do you need a logcat? |
|
This Issue keeps growing and growing. We need to stop this, now! @xLaMbChOpSx, since you've promised to erase all these within the upcoming week, let me know if you need anything! |
|
Another test version is available at my Dev-Host which should hopefully address the CID/LAC + other invalid display issues. Uploading & Download methods for OpenCellID have been rewritten and tested ALTHOUGH our API key is not white-listed so is not allowing downloads, I did request a new key as suggested after the previous one was disclosed but it has not been white-listed as yet. I also reverted two changes to the AT Command Injector to try and return its operation back to the state that was experienced with the v0.1.21 release, if there are still issues I can revert all AT Command changes right back to that version to hopefully restore the previous level of stability. |
|
Ok, so the problem with not being able to download the OCID data is because we don't have a key. Bad. I don't have time to contact "them" right now. Would it be possible to obtain a personal key that can be used in app? Perhaps a way for each user to get his/her own? By entering somewhere in App? Yeah, the AT is behaving weird, or not at all. I have no idea what is going on there. Also there are 2 /dev/smd0 devs listed on mine... Also for eveyone's info, I think you'll have to reboot phone if you've used it previously, since the smd0 device access is "blocked" by whatever PID it was using. AT least that's what happens on command line. The way to see it is using: PS. Please also make sure you change the version in the app, just so that we can make sure we're running the right one. Easy to make mistakes... |
|
@E3V3A, if I read that right, @xLaMbChOpSx has already requested a new key with c2dc93b and I'm sure it will be included within the next release. Regarding the AT Command Injector: My ROM seems to lack the binary
|
|
@SecUpwN I really have no idea what you're talking about there. You have a binary called "radio" in your /system/bin/ ?? Also, I suggest that for minimal and incremental updates that are produced, that their names are appended with something like: etc. |
|
@xLaMbChOpSx You posted several minor test version updates, can you also write one line what issue you tried to address on those (or what change we should expect), so we know what to look for?
You can edit this post. |
|
@E3V3A, my idea was simply to add the version number to the main screen beneath the word "AIMSICD" as well to make it more easy finding it. By adding some sort of "master string", both the version number of the main screen as well as in the About-Tab should be changeable: Means, only change the "master string" to change the version number across the whole App. Regarding my issue with Regarding the versioning of minor incremental updates: I think it is a good idea to explain what the minimal changes are, but since they are minor updates and no real releases, don't you think that this just places another hurdle in development onto the shoulders of developers? Not sure about this. If you really like the nameing of |
|
Well, alphas imho, is all about minor updates, but without an ongoing discussion with developer about what is being fixed and not, it is impossible to test in any sensible manner. We need more feedback here. |
|
The current internal test release solved one more bug on my device. I am happy to notice that the list is melting! @xLaMbChOpSx and @andr3jx could you please be so nice to digg into the remaining list to fix these? |
|
Proposed some more changes in #112 including rewritten AT Command Injection, notification icon display corrections and correct handling of location services (GPS) settings with Cell Tracking enabled. AT Command Injection does not work on either of my devices so requires testing but I am hoping these changes at least restore the earlier level of functionality. A compiled version for testing can be found here |
|
@xLaMbChOpSx Found bugs, AT need fixin', please see #23. |
|
Bugs for WIP-Release 0.1.24-alpha_b6 On: GT-I9195: (See device details here.)
On: GT-I9100:
|
|
@tobykurien, if you have a "free minute" (yeah, I know..), can you see if you can tackle some of the remaining Issues here? I am sure those are interconnected to other separate Issues we've already filed on our GitHub - once solved, we'll have cleared up another huge bunch of junk. Thank you so much! @E3V3A and @andr3jx, please use the current build of our App to check against all remaining Issues here. I want this to be SOLVED, please don't add any new Issues here, rather open new ones. Thanks! |
|
@SecUpwN |
|
See I knew this would happen. We create monster Issues like this, I try to track and reverify everything for every version and and then you just close it because it is too much work and outdated. Have you even tried to check all these bugs again, @E3V3A? Because the way I see it, we will end up double-listing them again. 😠 |
|
Yes, I did check them, did you? |
For the majority, yes. But the most Issues you filed here are difficult to check because I cannot see what you did on certain occasions. Should we really let this be closed and check from the ground up? |
|
I did try to check them from ground up, only to discover what I said above. In some cases the issues were not well worded and defined which means that parts of it has been fixed and others not. |
Dear @xLaMbChOpSx, I know you have a rough time here. Another new Issue? Sigh - I'm sure you're not too happy about that. Furthermore, it appears that currently multiple Issues from previous WIP-Releases are cramped into one Issue, upgrading these to "Monster Issues" - that's NOT the fault of @E3V3A, but of the partially very fast development with new WIP-Releases in the middle. And that is a GOOD thing! But since you're currently pretty much alone on this journey (working to resolve that soon), I bet you're a little lost on what to work on.
Fret no more, here comes a cool new feature I'd like to take advantage of: Nested task lists!
So this is what I'll do with this new "Issue": I will review and ELIMINATE all "Monster Issues" (aka "v0.1.xx-alpha Bug Reports: Add your bugs here!") to comfortably list those Issues dragged from previous WIP-Releases up until now to be RESOLVED for WIP-Release 0.1.25 - this should allow for some time. And please, @xLaMbChOpSx, TAKE YOUR TIME! Really, I mean it. If you're upset about how things are being processed here, please talk to me on XDA. I'm a firm believer of the theory that god gave everyone a mouth to use it and to also voice constructive criticism. Please don't hesitate to tell me what you'd like to see changed.
@xLaMbChOpSx and @E3V3A, please help me on this to clear things up:
Please TICK the things that are SOLVED! Thank you, folks. 🌻
Remember: When all these things are done, we're automatically at WIP-Release 0.1.25. Take it easy. We should also not forget to release the versions in the middle up until 0.1.25 fixing the other Issues.
Reported bugs from WIP-Release 0.1.8-alpha, Issue #44
Reported bugs from WIP-Release 0.1.10-alpha, Issue #49
Reported bugs from WIP-Release 0.1.11-alpha, Issue #53
Reported bugs from WIP-Release 0.1.13-alpha, Issue #58
Reported bugs from WIP-Release 0.1.14-alpha, Issue #62
Bugs from WIP-Release 0.1.15-alpha, (not reported)
Bugs from WIP-Release 0.1.16-alpha, (not reported)
Bugs from WIP-Release 0.1.17-alpha, (not reported)
Bugs from WIP-Release 0.1.18-alpha, (not reported)
On: S4-mini GT-I9195 stock 4.2.2 SELinux Enforcing
(Those crashes seem random. Sometimes yes, sometimes no.)
LocSvc_afw, LocSvc_eng and LocSvc_adapter
Summary: This version is harder to test on this device. Possibly because of the Enforcing mode, which prevent access to many file locations and other operations. More tests needed with SELinux settings in Enforcing versus Permissive modes, including setting full access to (via EFS files) to the ServiceMenu items.
On: GT-I9100, SlimKat 4.4.2b4
Summary: Most things that was causing crashes for the I9195 above, is working on this device, apart what is mentioned above. Neighboring cells look better and more clear. More testing needed. (I have a very bad battery and no gps-lock near outlet.)
Bugs from WIP-Release 0.1.19-alpha, (not reported)
On: S4-mini GT-I9195 stock 4.2.2 SELinux Enforcing
On: GT-I9100, SlimKat 4.4.2b4
Summary: Most things that was causing crashes for the I9195 before have been fixed, apart what is mentioned above.
Bugs from WIP-Release 0.1.20-alpha, (not reported)
General UI/UX improvements (all devices):
On: GT-I9100, SlimKat 4.4.2b4
On: S4-mini GT-I9195 stock 4.2.2 SELinux Enforcing
cat /dev/smd0 &was issued... Need more test.Bugs from WIP-Release 0.1.21-alpha, (not reported)
GT-I9195:
❗ BUG ADD FREEZE - LET'S FOCUS ON FIXING ALL OF THESE. THANKS.
This list is subject to changes and / or deletions as we test them on our latest WIP-Release.The text was updated successfully, but these errors were encountered: