Dude thanks! What an awesome idea.
I just installed it. My wife is going to be doing so as well. We have pretty solid wifi at home and I do at work – but we are rural and do often commute through roaming areas.
IMO, RW needs to put more emphasis into building this app into a native app – as well as getting the auto-wifi features more solid.
But, fortunately, they aren’t really busting our balls over our usage yet either.
Anyways, thanks so much.
farlicimo wrote:
Is there no one you can contact at Google with some sort of recovery process?
Google only knows the SHA fingerprint of the certificate previously used; they don’t have the security cert itself (if they did it wouldn’t be very secure - only the actual source of authority should have this cert and that would have been me if i hadn’t wrongly assumed Tasker’s backup function included the certs used for apps).
There is no recovery option for the cert itself, and i doubt i’d be able to talk them into allowing me to deploy an update with a new cert (user experience would be poor: everyone would have to uninstall the old version manually prior to installing the new version - device-side security mechanisms prevent installation of potentially tainted updates and having the wrong cert is an absolute roadblock there).
i’ll work something out.
dave_kc wrote:
As someone waiting patiently for Google Fiber, and with the challenges with my work trying to get there, I can assure that Google is not the easiest company to get to a contact.
different parts of google have different levels of support. play store is a big deal over there so they actually have pretty good support. still, i think there simply is not a proper solution to this. i haven’t contacted google yet, but will tomorrow.
I am also waiting on the addition of hangouts to the Wander app. I have discontinued use until then.
I would be happy to beta test whatever you have so far bit.
coreyk wrote:
I am also waiting on the addition of hangouts to the Wander app. I have discontinued use until then.
I would be happy to beta test whatever you have so far bit.
looks like there isn’t a clean way to flush the old cert from google’s servers - i’ve got a support ticket in with them now but don’t expect anything useful
for now, here’s a beta version of the updated app:
https://app.box.com/wander-beta
note: the install will FAIL unless you remove the old version first.
Change log:
-bit
First, I want to give a big “thank you” to @bitflung for creating this app and providing it for free.
I have had the app installed for some time now. I’ve had a question in my head for a long time, but for whatever reason I have procrastinated in asking it.
My question is this: Why does the Wander app need to have permissions for location?
@bitflung would give the definitive answer (since he wrote it), but my guess is so that it knows when roaming and when it’s not roaming. But I’ll let him give his final answer.
First, I want to give a big “thank you” to @bitflung for creating this app and providing it for free.
you’re welcome - thanks for the positive feedback!
I have had the app installed for some time now. I’ve had a question in my head for a long time, but for whatever reason I have procrastinated in asking it.
My question is this: Why does the Wander app need to have permissions for location?
darn good question. to tell you the truth, i’m not sure…
i create the app using Tasker App Factory - this is kind of like Visual Basic for Android app development as opposed to a ‘proper’ development suite (that is, as an analogy, it is a child’s bike with training wheels as opposed to Harley Davidson).
when i export the tasker scripts as an app i’m presented with the following permissions (click to enlarge):
None of these have anything to do with location (the extra permissions category is a place where i could add permissions manually - that section is empty.
@dave_kc may be right and this has something to do with reading the roaming status. it might also have something to do with monitoring for Google Maps to be running? neither of those are very obvious to me though. i’ll look into this a bit more though and try to find out why google play thinks i’m requesting location services while the Tasker App Factory shows no such permissions are used.
thanks for asking - very curious indeed!
-bit
I might have some input. In my similar Tasker integration, in order to identify roaming, the task queries the identity of the cell tower. That query is also used in assisted GPS location finding (your location is identified according to which cell tower you are connected to). I haven’t seen the inner workings of the app but I’m pretty sure that is why it needs “Location”.
That makes perfect sense, thanks for the insight!
Wander pills the tower ID too and even displays it in the notification while you are roaming; so between reading the ROAM variable and the CELLID, it makes sense that the app arguably consumes enough data to potentially locate a user.
I still find it odd that tasker’s own permissions list doesn’t show the location permission though. May be a bug in tasker?
Hey @bitflung’
Day before yesterday I took a 65 mile trip mostly through areas with Sprint coverage. I was streaming (Bluetooth) music from my phone to my car audio system. Every now and then the stream was interrupted momentarily, perhaps 3 times per song. These interruptions are irritating. Wander was enabled.
Yesterday I made the return trip but with Wander disabled. My music stream wasn’t interrupted.
I can’t prove Wander is causing this and I don’t spend that much time on the road but I’m wondering if Wander is doing a roaming check every 30 seconds or so that would interrupt the stream.
Anyone else experience these interrupts in their music stream? I’m using Wander on an X2. My phone wasn’t rebooted between trips.
Bill
p.s. The return trip was on a different path along a route parallel to, but 10 miles away from, Sprint coverage. I was in an area with solid roaming coverage according to the Sprint map. That path (the parallel portion) was roughly 30 miles long. The phone dropped in and out of roaming, was essentially useless, but did consume 1.6 Mb data. Sigh.
The highlighted road on this snippet of the Sprint map is entirely in the twilight zone:
Day before yesterday I took a 65 mile trip mostly through areas with Sprint coverage. I was streaming (Bluetooth) music from my phone to my car audio system. Every now and then the stream was interrupted momentarily, perhaps 3 times per song. These interruptions are irritating. Wander was enabled.
that’s odd.
Yesterday I made the return trip but with Wander disabled. My music stream wasn’t interrupted.
next time, try enabling Wander again on the return trip, see if the symptoms return.
I can’t prove Wander is causing this and I don’t spend that much time on the road but I’m wondering if Wander is doing a roaming check every 30 seconds or so that would interrupt the stream.
it shouldn’t.
i actually check for roaming status every time the CELLID changes (app is triggered by changes to cell id) - i figure, if you don’t move to a new cell tower then your roaming status can’t possibly change. i suppose if you are in a really nasty area your cell id might change faster than once every 30 seconds (perhaps several times in a given second, but that would be really extreme).
regardless, when the cell id changes i just read a single global variable and either enable or disable mobile data.
nothing in Wander should ever be process intensive.
Anyone else experience these interrupts in their music stream? I’m using Wander on an X2. My phone wasn’t rebooted between trips.
i’d be interested to know if anyone else can reproduce this too, though i strongly doubt Wander is the culprit. i’m not even sure there is much i could do to improve the performance of the app. perhaps if i enable a persistent notification that would prevent Android from suspending the app and therefore speed up some operations while Android is under heavy load… doesn’t entirely likely to fix this though since your music player should run at a high priority and the bluetooth stack should run in kernel space and therefore not be affected by any of this.
p.s. The return trip was on a different path along a route parallel to, but 10 miles away from, Sprint coverage. I was in an area with solid roaming coverage according to the Sprint map. That path (the parallel portion) was roughly 30 miles long. ** The phone dropped in and out of roaming, was essentially useless, but did consume 1.6 Mb data. Sigh.**
1.6MB of roaming or native data? if roaming, perhaps your phone was under such heavy load that Wander couldn’t disable mobile data fast enough to prevent data consumption? this would suggest that being under heavy load was the problem rather than Wander itself causing some issue with bluetooth or music playback.
which music app do you use? was your phone in the exact same location in the car? (many Android 4.4.4 users have complained that bluetooth audio cuts out now and then on 4.4.4 while it worked fine for them on 4.4.2 - some have correlated this to a decrease in functional bluetooth range but i think it’s possible those folks are jumping to conclusions prematurely. still it would BEHAVE much like a reduced bluetooth range with respect to the old 1st gen moto X pre-4.4.4)
The highlighted road on this snippet of the Sprint map is entirely in the twilight zone:
perhaps it is the twilight zone itself that is the problem? you’ve mentioned before that the twilight zone causes all sorts of radio related problems for you (the phone trying to remain connected to sprint towers that it can’t actually use, etc). radio and modem functions would execute in kernel space and are fully capable of causing user code (like your music app) to starve for cpu cycles.
let me know if you can ever reproduce this. otherwise, watch for Wander’s battery usage in general - it should consume so little that it might not even show up in the list, but if it ever DOES consume a lot more battery then (and only then) it would make sense that Wander has a related bug that I could hopefully find and fix. not using power means not burning cpu cycles; since i don’t perform flash writes or network operations there really isnt’ any other way for me to slow down the system aside from burning too many cpu cycles.
bitflung wrote:
1.6MB of roaming or native data? if roaming, perhaps your phone was under such heavy load that Wander couldn’t disable mobile data fast enough to prevent data consumption? this would suggest that being under heavy load was the problem rather than Wander itself causing some issue with bluetooth or music playback.
Wander was disabled on the return trip. Yes, that was roaming data consumed during the brief roaming intervals.
which music app do you use?
Doubletwist.
was your phone in the exact same location in the car?
More or less, yes, it was on the passenger seat.
(many Android 4.4.4 users have complained that bluetooth audio cuts out now and then on 4.4.4 while it worked fine for them on 4.4.2 - some have correlated this to a decrease in functional bluetooth range but i think it’s possible those folks are jumping to conclusions prematurely. still it would BEHAVE much like a reduced bluetooth range with respect to the old 1st gen moto X pre-4.4.4)
They might be onto something. I never experienced this with my X1 with Wander enabled.
The highlighted road on this snippet of the Sprint map is entirely in the twilight zone:
perhaps it is the twilight zone itself that is the problem? you’ve mentioned before that the twilight zone causes all sorts of radio related problems for you (the phone trying to remain connected to sprint towers that it can’t actually use, etc). radio and modem functions would execute in kernel space and are fully capable of causing user code (like your music app) to starve for cpu cycles.
Nope. There were no interrupts in the twilight zone when Wander was disabled. There were even a couple of No Service notifications along that route. I made a left turn at the end of that route that took me out of the twilight zone and after that I had a solid roaming connection.
let me know if you can ever reproduce this. otherwise,
This happened on a couple of other trips but the return trip was the only trip with Wander disabled. I’m turned it off in an effort to isolate the problem. There have been periods during other trips when Wander was enabled and there were no interruptions.
watch for Wander’s battery usage in general - it should consume so little that it might not even show up in the list, but if it ever DOES consume a lot more battery then (and only then) it would make sense that Wander has a related bug that I could hopefully find and fix. not using power means not burning cpu cycles; since i don’t perform flash writes or network operations there really isnt’ any other way for me to slow down the system aside from burning too many cpu cycles.
I haven’t check the Wander usage however yesterday, on the return trip, my phone went from a full charge to a 60% charge in 9 hours, about 2 hours of which were on cell. I don’t find that unusual.
perhaps it is the twilight zone itself that is the problem? you’ve mentioned before that the twilight zone causes all sorts of radio related problems for you (the phone trying to remain connected to sprint towers that it can’t actually use, etc). radio and modem functions would execute in kernel space and are fully capable of causing user code (like your music app) to starve for cpu cycles.
Nope. There were no interrupts in the twilight zone when Wander was disabled. There were even a couple of No Service notifications along that route. I made a left turn at the end of that route that took me out of the twilight zone and after that I had a solid roaming connection.
you misunderstand. i was suggesting that the twilightzone might be causing the radios to do something odd which in turn could trigger Wander to behave (correctly) in an odd manner.
let me know if you can ever reproduce this. otherwise,
This happened on a couple of other trips but the return trip was the only trip with Wander disabled. I’m turned it off in an effort to isolate the problem. There have been periods during other trips when Wander was enabled and there were no interruptions.
so you’ve had multiple cases with problems and without problems, and the only test without Wander was one of the times without problems. sounds like there is a good amount of testing still needed. i’d focus on the twilight zone aspect of this - if/when you see the symptoms again try turning off wander for a bit then re-enable. see if the problems correlate well with Wander being enabled.
unfortunately if the towers are doing something miraculously stupid (and that’s what your twilightzone sounds like to me) there is very little hope for me to find some way to alter Wander to compensate for it. best i can think of right now is to write a small app to record the timestamps and cell ids for every cell id switch Wander would see. if we see dozens of switches per second it might explain why your phone is resource constrained - at that point i could add something to wander to ignore cell id switches for ~30 seconds between each switch, but the underlying problem would remain and would likely continue to cause symptoms.
watch for Wander’s battery usage in general - it should consume so little that it might not even show up in the list, but if it ever DOES consume a lot more battery then (and only then) it would make sense that Wander has a related bug that I could hopefully find and fix. not using power means not burning cpu cycles; since i don’t perform flash writes or network operations there really isnt’ any other way for me to slow down the system aside from burning too many cpu cycles.
I haven’t check the Wander usage however yesterday, on the return trip, my phone went from a full charge to a 60% charge in 9 hours, about 2 hours of which were on cell. I don’t find that unusual.
that sounds like a perfectly reasonable battery performance (especially while listening to music via bluetooth the whole time). the big question here is whether Wander consumed significantly more power than it normally does. under normal circumstances it should consume so little that it doesn’t show up on the list, so 10x (or more?) more might still not affect over all runtime of the device on a charge but might actually earn Wander a spot in the battery usage stats. THAT’s what i’m wondering here, does Wander even show up in the stats? if not then Wander is almost certainly not part of the problem. if it does then we need to consider WHY it shows up (the answer is either that Wander consumed more power than usual or that other apps used so little power that Wander ended up on the list by default even after using nearly no power). The stats aren’t perfect, sadly, so it is possible for an app to be at fault here (e.g. Wander) and still not show up on the list. it’s also possible for an app to falsely be listed as consuming lots of power when in fact it didn’t (this is exacerbated as the device spends more time in kernel land playing with devices and their drivers; specifically it is the power consumed by the hardware itself that most commonly gets misrepresented in the stats).
bitflung wrote:
so you’ve had multiple cases with problems and without problems, and the only test without Wander was one of the times without problems. sounds like there is a good amount of testing still needed. i’d focus on the twilight zone aspect of this - if/when you see the symptoms again try turning off wander for a bit then re-enable. see if the problems correlate well with Wander being enabled.
This has nothing to do with the twilight zone. I just mentioned that as an aside. On the route I took to my destination I had good Sprint coverage and I was experiencing the problem. The route I took on my return trip was through the twilight zone where, aside from my phone being rendered useless for placing or receiving calls, there were no interruptions to the audio stream. If the twilight zone is cause by wonky towers then there must be hundreds of them.
@bitflung I did a lot of troubleshooting today and eliminated both Wander and Doubletwist as the cause of the bluetooth stream disruptions. I won’t post anymore of this to your thread beyond saying after eliminating those two apps I rebooted the phone is Safe Mode and the problem was gone. Then I rebooted in normal mode and the problem stayed gone so I still don’t know what causes this.
billg wrote:
@bitflung I did a lot of troubleshooting today and eliminated both Wander and Doubletwist as the cause of the bluetooth stream disruptions. I won’t post anymore of this to your thread beyond saying after eliminating those two apps I rebooted the phone is Safe Mode and the problem was gone. Then I rebooted in normal mode and the problem stayed gone so I still don’t know what causes this.
thanks for letting me know - i’m still curious about this, so if you do find the culprit let em know via a DM or another thread? very odd issue overall. i use bluetooth just for music (and then almost 100% while on wifi and sitting at my desk) so i don’t have much chance to organically hit this issue myself. still would be nice to hear that you’ve fixed it
this is probably a dimb question, but what the heck. You wrote, “Wander disables your mobile data (entirely) whenever you start roaming, then enables it again when you enter native Sprint coverage.” Does this mean downloading data when I’m in Sprint coverage does not count the same way as roaming data? What are the differences? It sounds like you’re saying one is cheaper than the other? Can you please explain this distinction? Thank you.
According to Republic Non Sprint data (ie Roaming Data) cost 30 times what it does for Sprint Data, on the Current $25 and $40 plans you have access to 5GB of Sprint data before being throttled (soft Cap) but roaming data is always throttled and after 25MB it is cut off all together (hard Cap)
you are using Roaming data whenever you have a small triangle above the cell strength bar (next to the 3G/4G icon)
I hope this answers your question
this is probably a dimb question, but what the heck. You wrote, “Wander disables your mobile data (entirely) whenever you start roaming, then enables it again when you enter native Sprint coverage.”
the only dumb questions are those left unanswered.
Does this mean downloading data when I’m in Sprint coverage does not count the same way as roaming data? What are the differences? It sounds like you’re saying one is cheaper than the other? Can you please explain this distinction? Thank you.
correct, they are NOT considered the same “value” by RW, Sprint, or Sprint’s roaming partners (e.g. Verizon). The typical process is something like this:
Consuming NATIVE data:
your phone is connected to a Sprint tower
data is routed to/from the internet via all Sprint-owned or Sprint-controlled infrastructure
Sprint charges RW for every byte of data you consume; RW in turn pays for that data out of the revenues from all of our service plans
Costs for Sprint “native” data are controlled by Sprint at the top level
Consuming ROAMING data:
your phone is connected to a non-Sprint tower
data is routed to/from the internet via infrastructure Sprint does not control
the roaming partner who does control this infrastructure charges Sprint for every byte of data you consume
Sprint then charges RW for these roaming data fees originating from the roaming partner
RW must pay Sprint for this data from the same pool of money used to pay for native data
Costs non-Sprint “roaming” data are not controlled by Sprint at the top level; they are KNOWN to be inflated by ~30x over the costs for native Sprint data
Therefore RW must treat the data as “different” than native data (most carriers do this by charging an inflated price for service all the time then kicking out users who use too much roaming data to be profitable)
NOTE: roaming data costs RW a lot of money, but RW does not charge us directly for it. your bill is not affected at all by the costs outlined above.
Once upon a time RW was still in “beta” testing. Back then they decided to make ALL data (both native and roaming) 100% unlimited. As they came out of beta they observed that roaming data costs were skyrocketing. As such they began trying to mitigate these costs. An early attempt at mitigation included throttling roaming data speeds after 100MB of usage in a billing period. This didn’t solve the problem. Eventually they settled on a HARD CAP for roaming data: you would only be able to consume 25MB of roaming data per month. period. After that 25MB is used up you just won’t have any roaming data available to use.
Enter Wander: the app is NOT meant to affect your personal expenses (RW is a flat cost for service each month; it is not based on amount of usage). Instead, Wander is meant to help you budget your roaming data usage: 25MB is not a lot and if you find that you truly NEED it at the end of the month you’d likely be upset that it was wasted earlier in the month on services you don’t consider critical.
Wander enables you to STOP roaming data usage right up until the moment you really WANT/NEED it. At that time you should (ideally) have 100% of your monthly allotment available to use.
In practice SOME amount of roaming data will likely be used without your consent even with Wander running - this is because I can’t block specific apps from using roaming data, but rather I can block ALL mobile data or allow ALL mobile data based on whether you are roaming and which apps are running. So if you open the “phone” app Wander will ALWAYS turn mobile data back on; if your email app decides to check for new mail right then, it will get access to data even if you are roaming.
Most folks find that the amount of data “leakage” is very small and so Wander is still very effective for them. Using Wander you have a very good chance of retaining your ability to use roaming data even as you near the end of your bill cycle. This means you can use data freely as you travel without constantly worrying about whether you might be using up that precious 25MB roaming allotment and still feel confident that a large portion of that 25MB will be available at the end of the month if you need it.