Jump to content

mikejeep

Honored Premier Sponsor
  • Content Count

    2,496
  • Joined

  • Last visited

  • Days Won

    34

Everything posted by mikejeep

  1. After looking at a handful of diagnostic and crash reports that I have received from Android Q Preview users, I can see that the connection data being reported by the OS is either missing or invalid on all devices so far. It's either broken or Android is taking a completely different approach and has not publicly shared that yet. Hopefully it's just broken, and they will resolve it in the next release. Q users, please use whatever reporting channels are in place to report Preview bugs to inform them of this. You can mention that onSignalStrengthsChanged() is including header text with every value instead of just the raw data, and CellInfoLte.getCellIdentity() and related routines appear to be reporting no data. -Mike
  2. After looking at a handful of diagnostic and crash reports that I have received from Android Q Preview users, I can see that the connection data being reported by the OS is either missing or invalid on all devices so far. It's either broken or Android is taking a completely different approach and has not publicly shared that yet. Hopefully it's just broken, and they will resolve it in the next release. Q users, please use whatever reporting channels are in place to report Preview bugs to inform them of this. You can mention that onSignalStrengthsChanged() is including header text with every value instead of just the raw data, and CellInfoLte.getCellIdentity() and related routines appear to be reporting no data. -Mike
  3. I have spent a TON of time on it because I'm overhauling Alerts for Android 8+ users. They were broken and I don't want to push another update out without a fix. It's a lot of work but it's getting there. Send me a diagnostic report from the Q Preview so I can get a peek at what's broken. Most early Preview builds have caused issues that were eventually resolved before the stable launch. And thanks for the bday wishes!! -Mike
  4. I learned a few years ago not to stress over Preview builds not working properly, because a lot of the stuff SCP uses gets overlooked in early builds. But please send me a diagnostic report when you have a chance so I can take a look at it. -Mike
  5. Do I spy something interesting in the status bar..... -Mike
  6. If you are rooted and have SignalCheck Pro, trigger the mobile connection reset feature within the app. That will set your airplane mode to only impact the mobile connection no matter what app is triggering it. It *might* need a reboot after but I don't think so. -Mike
  7. I reached out to Robert a few days ago regarding error messages and timeouts when trying to load certain threads over the last week, and slow loading times on others. He said there was a software update available that he was going to try. Perhaps that did the trick, as everything seems to be working great today. -Mike
  8. Interesting indeed.. I haven't seen anything like that in the Boston market, at least not yet. Not sure how I am going to be able to tackle that wrinkle in the app.. hmm. -Mike
  9. I've been researching this, and I am fairly confident that TAC 0 is unlikely to be seen in the wild, if it's even valid at all. Looking into it further, I was actually inconsistent within SignalCheck; the logger would save TAC 0, but most of the rest of the app recognized it as invalid. But, correcting that just means the TAC field in that log entry would be blank, it's not a mandatory value. So I am still going to add a "don't log without a valid TAC" option that should suit your needs. -Mike
  10. About a month ago, I started noticing my Pixel 3 (non-XL) wouldn't reconnect to LTE after it had dropped to 3G but only in certain areas. I haven't noticed a pattern other than it definitely doesn't happen in some areas. For example, near my home, I have poor signal and it drops to 3G often, but it always goes back to LTE as soon as it should. -Mike
  11. That is odd. I'll have to do some digging and testing to see where that is coming from. Regarding TAC 0, I have it flagged to log if TAC is between 0 and 65535. I can have it ignore TAC 0 if that's truly invalid, but I assumed that about PCI when I wrote the app, which turned out to be wrong (PCI 0 is valid and in use). If TAC 0 is legitimate I could look into making it a user option. That's the long-standing issue where the PLMN doesn't update in sync with the other data. It's very annoying. I *may* have overcome that in the current beta, albeit accidentally.. it's taking awhile to iron out some other bugs that have popped up but I'm still plugging away at it. -Mike
  12. No, that's odd! In most instances, the app overrides the provider name that is being broadcast (because many SCP users want to know the true identity of the network they are on, i.e. Project Fi). SCP uses "US".. perhaps the network uses periods in the name and for some reason it's falling back to that. Where in the app are you seeing "U.S."? -Mike
  13. It's indicating you are connected to a second carrier on either a small cell or a Mini Macro. Both have similar GCI patterns; the app can't distinguish between them, that's why it displays both. -Mike
  14. New beta has been uploaded, should become available within the hour.. added LTE timing advance and hopefully squashed some big juicy bugs.. let me know! Please try enabling some notifications and changing the sounds too.. -Mike
  15. I am loving the Wi-Fi Calling as well. Works great for me, where I have poor signal at home and sometimes have trouble connecting to my Airave 3 because it's hanging onto 1X800. I should have clarified that the problem I mentioned is not exclusive to Wi-Fi Calling -- it's happening to people on every call, on many different mobile providers worldwide. Shocked that Google's only response so far is to provide warranty replacements (which aren't fixing the issue). Sources: Android Police, Reddit, Google Forums -Mike
  16. I've noticed the HD icon on the dialer screen as well. Doesn't appear to matter if you're on Wi-Fi Calling or not, just when HD Voice is active. On another note.. anyone here having the issue with callers hearing you severely muffled and they hear their own echo? Looks like a widespread issue online. I noticed it only occurs on non-HD calls so it's likely a software issue. It's a serious problem though. -Mike
  17. I loaded an old version myself after I posted, the issue appears to be related to the change in October that I suspected.. thanks! I think I've already got a fix working. -Mike
  18. I managed to get my old HTC EVO LTE test device to duplicate the multiple instances bug. I can't figure out why it's not impacting my Pixel 3, but I guess that doesn't matter. I think I see what is causing the issue.. can anyone confirm that this behavior started with version 4.49 (released October 2018)? Or did it not appear until the most recent release from last month, 4.51? -Mike
  19. Hey it doesn't bother me, you're the one wasting battery for no reason.. 😉 -Mike
  20. Hmm.. just dug out your report too, I don't see anything specific that might cause multiple instances. Any recollection which version this started with? Regarding your Wi-Fi Calling icon, at the time of your report your device was reporting the voice side was connected to the 1X macro site, not Wi-Fi Calling. I have discovered that many phones do not reliably report Wi-Fi Calling status to the OS in the only manner I can access it. As you have seen, in certain instances it shows properly, but sometimes it does not. I'm still trying to find better ways to access this info. Also, I do see you have the root EARFCN method enabled, perhaps unnecessarily? It's logging lot of errors, are you seeing any error messages on your end? You can turn that off under Preferences > General > Enable Modem Commands if you're not using it; it would save some system resources. -Mike
  21. I was trying it without using the back button.. I tried exactly what you suggested, as well as many variations of that, using the recent tasks, home button, back button, notification icon, widget, etc.. I could not duplicate it. Please try it with Xposed and/or GravityBox disabled. I just checked out your diagnostic reports; the only errors I see are these, neither of which are being generated by SignalCheck; the third one referencing Xposed repeats numerous times over several minutes: 01-09 10:41:48.200 E/SpellCheckerSession(28997): ignoring processOrEnqueueTask due to unexpected mState=TASK_CLOSE scp.mWhat=TASK_CLOSE 01-09 10:41:48.200 E/SpellCheckerSession(28997): ignoring processOrEnqueueTask due to unexpected mState=TASK_CLOSE scp.mWhat=TASK_CLOSE 01-09 10:41:53.642 W/zygote64(29404): ClassLoaderContext size mismatch. expected=1, actual=2 (PCL[] | PCL[];PCL[/data/dalvik-cache/xposed_XResourcesSuperClass.dex*2802528989:/data/dalvik-cache/xposed_XTypedArraySuperClass.dex*708326108]) Let me know how it goes! Send diagnostics if you have issues, before and after are great -- you never know where an obscure error is going to get flagged and point me in the right direction. Thanks, -Mike
  22. Huh.. very strange -- I'm not able to reproduce this on my Pixel 3. One other person reported it to me a few months ago (I don't think it was you) but I was not able to reproduce that on my original Pixel. Do you have a custom launcher, memory management app, or anything else installed that you can think of that might play a role? -Mike
  23. Significant changes were introduced with Android 6.0 that limited what cell and Wi-Fi info would be accessible without Location access. I believe the theory behind it was that you could use that information to deduce your location. I held off implementing those APIs in SignalCheck as long as possible because I knew it would create headaches, but they have been in place since version 4.43 of the app, which was released in June 2017. Perhaps Samsung didn't fully implement those changes in it's flavor of the OS until the new update you just applied. -Mike
  24. It looks like you didn't grant SignalCheck the Location permission it would have requested. If you permanently declined it, go to your device's Settings menu and selecting Apps > SignalCheck Pro > Permissions and granting it there. All 3 of the requested permissions (Phone, Location, Storage) needed to be granted for full app functionality. -Mike
  25. Thanks David! The icon is automatic, it should just show up on the main app screen. If you're not seeing it, perhaps your U11 just doesn't report it to the OS. Shoot me a diagnostic report when you know WiFi Calling is active so I can see if there's anything I can do about it. -Mike
×
×
  • Create New...