Well the app (BLE Scanner for iPhone) hasn't seemed to do much, but have found taking phone out of pants pocket does. I have chicken legs, so its not like there is much biomass blocking it, but seems to work. Perhaps the tolerances for connection vary a lot beacon by beacon?
-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
potential phone key fix (or at least partial solution) for android
- Thread starter crackers8199
- Start date
Well the app (BLE Scanner for iPhone) hasn't seemed to do much, but have found taking phone out of pants pocket does. I have chicken legs, so its not like there is much biomass blocking it, but seems to work. Perhaps the tolerances for connection vary a lot beacon by beacon?
It's more likely the phone is going into a deeper power save mode when it detects it is in your pocket, and pulling it out wakes it to a higher state. Android was doing this a few generations ago, and that could pretty easily explain this.
which is why I said from the beginning to make sure you set the beacon scanner to not optimize battery. along with Tesla and Bluetooth (and a few others) which most of us have already set to not optimize battery...
Thanks fellow OnePlus 5 owner. I have been having about 50/50 success rate with phone as a key, including some strange situations where it will unlock the car, but wants me to use the key card to get into gear. Ever since OnePlus pushed an update about 2 weeks ago (it was mainly for BT related issues), I've gone from about 50% success to 75-80%. For the record, I was having all kinds of BT issues before that update was pushed. I just installed and setup the beacon app, and will see if that gets me to 100%. Thanks OP for the suggestion!
i'm intrigued on this update you speak of that they pushed that was for BT issues...makes me think about giving OOS another shot. i've been running aosp extended for months now because of all the bluetooth issues and bugs in OOS.
to be honest i prefer AOSP anyway, but if the update included an updated firmware it might still help.
I don't think so as it also happens when I've just unplugged in my garage, and needed to use the app to unlock the port, so phone wouldn't have gone that far to sleep
Walk away lock seems to not be working at all now.
Walk up unlock most of the time, with a bit of delay. And put into gear, so long as I keep phone out, don't need to turn bluetooth on/off.
amoney805
Member
I feel like the phone key has gotten a lot better over time. It went from working 50% to over 90% with my OnePlus 6. Id imagine its only going to get better with each update.
it had gotten better, then it went downhill. that's why i started looking for alternatives, like this.
mine was horrific when i first brought the car home in july, then got better to the point where it was at least tolerable for the most part as time went on...then they changed something a month or so ago that took it back to being almost unusable. my success rate went from 70-75% to literally maybe 10-15% (which is about where it was in the beginning).
i'm hopeful they'll eventually get it working 100% of the time, but that doesn't mean i don't want it to also work in the meanwhile.
new data point: the beacon scanner still works for the most part, but there are still situations now where that's failing too. i finally gave in and rooted my phone yesterday to try to at least get some more data on what is happening with this stupid thing. here's what i found...
the tesla app seems to die and/or restart every so often, at least on my phone. i set up a tasker profile for every five minutes while the screen is off to check if the app is running, and if it isn't then run it and set the oom_adj value to -17 (to get android's default memory manager to ignore it if needing to free RAM).
the basic gist of it (without posting the actual tasker profile because i don't have the phone in front of me) is
if app is running and oom_adj == -17 {
do nothing
}
else if app is running and oom_adj != -17 {
set oom_adj = -17
}
else if app is not running {
run app and set oom_adj = -17
}
i'll see a stretch of runs where it does nothing (i.e. the app is already running and the oom adjustment is already set to -17), followed by a point (or multiple points) where it ends up setting the oom adjustment back to -17. i don't think i have seen any situations where it actually had to run the app again, so it does seem that if it is being killed it's still restarting itself (but with a higher oom value).
the main thing i've noticed is that there's an easy way to tell if the phone key is going to fail: if you open the tesla app and it starts on the tesla logo screen rather than right at your car - that means the app wasn't in memory and the phone key is more likely to fail. i'm trying to keep the app running to avoid having that happen. the persistent notification they added seems to be irrelevant as far as this goes...the app can still be "killed" even while the notification is up.
still looking into all of this, but i figured i would post it in case anyone who's more familiar with android programming / memory management wants to chime in.
the tesla app seems to die and/or restart every so often, at least on my phone. i set up a tasker profile for every five minutes while the screen is off to check if the app is running, and if it isn't then run it and set the oom_adj value to -17 (to get android's default memory manager to ignore it if needing to free RAM).
the basic gist of it (without posting the actual tasker profile because i don't have the phone in front of me) is
if app is running and oom_adj == -17 {
do nothing
}
else if app is running and oom_adj != -17 {
set oom_adj = -17
}
else if app is not running {
run app and set oom_adj = -17
}
i'll see a stretch of runs where it does nothing (i.e. the app is already running and the oom adjustment is already set to -17), followed by a point (or multiple points) where it ends up setting the oom adjustment back to -17. i don't think i have seen any situations where it actually had to run the app again, so it does seem that if it is being killed it's still restarting itself (but with a higher oom value).
the main thing i've noticed is that there's an easy way to tell if the phone key is going to fail: if you open the tesla app and it starts on the tesla logo screen rather than right at your car - that means the app wasn't in memory and the phone key is more likely to fail. i'm trying to keep the app running to avoid having that happen. the persistent notification they added seems to be irrelevant as far as this goes...the app can still be "killed" even while the notification is up.
still looking into all of this, but i figured i would post it in case anyone who's more familiar with android programming / memory management wants to chime in.
another note: when the tesla app is launched and then put into the background, it ends up with a crazy high oom value. this means that if the system needs memory, the tesla app is one of the first it will try to close.
i know a limited amount of android programming, but it seems to me when they added the persistent notification to try to keep the app in the foreground (and as such improve the phone key), they did it wrong. the two seem to be completely decoupled and the persistent notification / foreground service do nothing to actually keep the app running like they intended...
i know a limited amount of android programming, but it seems to me when they added the persistent notification to try to keep the app in the foreground (and as such improve the phone key), they did it wrong. the two seem to be completely decoupled and the persistent notification / foreground service do nothing to actually keep the app running like they intended...
HTC One m9 (HTC's 2015 "flagship" phone) running Android 7.0 (stock OS - they released several updates for the phone).
Beacon Scanner being in the background doesn't help at all, even when set to scan continuously. Sometimes I still have to open the Tesla app to get the car to connect and unlock.
Basically no change for me. Sometimes I walk up and the car works as intended, sometimes I walk up and I try to open door and immediately the screen prompts for key card (phone/app probably not communicating), and sometimes I walk up and the car takes 10-15 seconds to wake up and even prompt for RFID (even if phone app is opened before then and shows connected, car doesn't open right away - though in the case the phone is connected to the car, once the car finishes waking up it unlocks immediately when I try the door).
Beacon Scanner being in the background doesn't help at all, even when set to scan continuously. Sometimes I still have to open the Tesla app to get the car to connect and unlock.
Basically no change for me. Sometimes I walk up and the car works as intended, sometimes I walk up and I try to open door and immediately the screen prompts for key card (phone/app probably not communicating), and sometimes I walk up and the car takes 10-15 seconds to wake up and even prompt for RFID (even if phone app is opened before then and shows connected, car doesn't open right away - though in the case the phone is connected to the car, once the car finishes waking up it unlocks immediately when I try the door).
On Android 7 here and there's no persistent notification implemented on my device even though that is supported by 7 (I suspect they only implemented the fancier version(s) from newer Android releases).
The app has averaged 91MB of memory usage in the last 3 hours on my phone, with an average total memory use of 2.1GB in those 3 hours, it seems like a device with 3GB of RAM should have no problem keeping it in memory anyways ... (I had trouble getting into the car less than 2 hours ago, specifically with the phone not the car this time)
So I wonder if it's not just OOM killing that is happening, but some other trigger that causes the app to be killed?
BluestarE3
Active Member
Persistent notification showed up for me after upgrading my Moto G5+ to Oreo. This has improved the reliability of phone-as-key to almost 100% for me. However, keeping Bluetooth on all the time runs down my phone battery more quickly, so I tend to disable it when I don't explicitly need it. So, if I forget to turn it back on when I need to get into the car...
this would make sense actually, because my op5 has 8 gb of ram. i should really never see apps getting killed...although, like i said, it seems the app ends up re-launching itself before my tasker profile gets to bring it back up. so, the question is, why is this happening?
after enabling developer mode on my phone (funny, I thought I did this once upon a time... maybe it resets on updates or reboot? I haven't done anything developer-y in years) I can see that the "BLEService" service which is part of the Tesla app (as well as the app itself) have been running for 173 hours and change. I've definitely had problems where I had to either wake my phone or even open the Tesla app in the last 100+ hours, so it seems like it's not necessarily being auto restarted somehow, but just stops working even without a restart.
Nebuchadn3zzar
Member
Persistent notification showed up for me after upgrading my Moto G5+ to Oreo. This has improved the reliability of phone-as-key to almost 100% for me. However, keeping Bluetooth on all the time runs down my phone battery more quickly, so I tend to disable it when I don't explicitly need it. So, if I forget to turn it back on when I need to get into the car...
I can confirm that the Android Oreo 8.1 update has resolved my phone key unreliability, even after I decreased the importance of the "Phone Key Status" notification category of the Tesla app to Low (no sound or visual interruptions) to eliminate the persistent notification. The green dot remains on the Tesla app icon, but that's more easily ignored.
this is not the issue, my phone is always in my front pocket.
Similar threads
