Bike Radar

Releases

• Oct 30, 2026 1.10.0
  ### Features - **The walk-away alarm sounds if you walk off with the radar still on.** It learns from 3 ordinary switch-offs first. Not on radars that report distance only. Tried so far on one phone and one radar. - It stays quiet if the radar drops while you ride or within 30 s of stopping, and waits, for up to 2 minutes, while the phone keeps finding the radar. - On after installing this version, unless you had turned the dashcam's walk-away alarm off. The switch is in Settings -> Alerts. - **Setup can pick a radar the app doesn't recognise by name.** ### Fixes

  More…

  - **After a car passes you, the app now beeps for the next car behind.** Before, that car could pass you without a sound. A few still can. - The app also beeps for a car that overtakes the one you heard about, while both are behind you. - It beeps for how far back that car is, so two beeps after three means it is at mid distance. - **The number of beeps no longer goes down until the app sees the car you heard about pass you.** Before, two beeps after three could be about a car further back, which sounded like the close car dropping back. - A radar that reports distance only sees fewer passes. On one with no data from an eBike, the number can go down a few seconds after the radar loses the cars that got the higher number. - **Declining Notifications no longer turns off the beeps and the overlay.** On Android 13 and later, the radar needs only Nearby devices now. - Without Notifications, you can't silence the walk-away alarm. - **Allowing Nearby devices in Android's settings starts the radar when you come back to the app.** Before, it stayed off until you restarted the app or the phone. - **Stop scanning now keeps the radar off.** If the app had closed unexpectedly, the radar could reconnect by itself while the app was open, or when you swiped away an old walk-away alert. - **The dashcam's walk-away alarm no longer needs the overlay's camera-off warning.** With that warning off, the alarm never sounded and its settings were hidden. - If that warning was off, installing this version turns the dashcam's alarm off once. Turn it on in Settings -> Dashcam. - **The dashcam's walk-away alarm no longer keeps sounding after the radar comes back.** It could ring at full volume for up to a minute. - It could also start just as the app stopped, with nothing left to stop it. - Tapping Dismiss or Remind in 2 min could start it again. - **Light auto-mode uses your area, not London, even if you don't open the app before you ride.** Before, those rides used London's sunset. - The app keeps one rough area on the phone, outside your backup. - **Choosing a different radar works straight away.** Before, the old radar stayed connected until you restarted the app. - **A radar paired while the app is running now connects.** Before, it waited until the radar left range and came back. - **Unpairing the radar no longer leaves the app trying to connect to it**, on Android 13 and later. - **A headset with "rtl" in its name is no longer taken for a radar.** It could stop your real radar from connecting. - **An eBike paired while the app is running now sends data.** Before, it showed Not paired until you restarted the app or Bluetooth. - **Setup's Home Assistant test checks MQTT too.** It said connected even when MQTT was missing. - **A ride no longer shows twice in ride history**, or makes it crash. - **Ride history and the ride summary no longer say "0 close passes" when close passes weren't being counted.** - **A failed alert sound now suggests restarting the phone.** Before, it said to check the media volume, which was never the cause. - **The home screen links to ride history whenever you have one.** Before, it needed close-pass counting on. ### Security - **The report you copy for a bug report hides serial numbers in device names.** ### Improvements - **If Nearby devices or Notifications isn't allowed, the home screen says which and opens Permissions.** Before, it said "Radar not paired" or "Waiting for radar". - **The home screen says when it is still connecting to the radar.** - **Pair lets you pick your radar when it is paired under another name.** - **Bigger buttons, and clearer for screen readers.** - **Alert sounds and the example ride now say what two and three beeps mean: a vehicle at mid distance, and one close to you.** - **The eBike screens say what the app reads from the bike.** - **A rule meant to keep beeps on during slow climbs is gone.** On the developer's rides it never changed a beep. ### Battery - **When the radar disconnects and may have been left on, the phone stays awake for up to 35 s.** This stops the phone's sleep from delaying the walk-away alarm. - Within 2 minutes of the drop, it can stay awake for up to 35 s again each time the phone reaches the radar but loses it before it sends data. ### Bug reports - The logs you can send with a bug report now include your alert settings and how each radar connection ended. They also say why each beep sounded. - Bug reports can be written in Spanish. ### Upgrading - Still works on Android 12 and later. - On the developer's rides there were a few more beeps in traffic, so alerts per km and per hour rise a little, in the ride summary and in Home Assistant. - Nothing else changes in Home Assistant, in which radars work, or for other apps that use your radar. - On a new phone, and after a system update or a change of radar, the radar's walk-away alarm learns your switch-offs again. ### For developers - The privacy check runs on every push. Kotlin Compose plugin 2.4.21, Gradle 9.8.1, actions/upload-artifact 7.0.2. ## What's Changed * ci: bump actions/upload-artifact from 7.0.1 to 7.0.2 by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/49 * build: bump the gradle group with 2 updates by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/48 **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.9.0...v1.10.0
• Oct 9, 2026 1.9.0
  ### Fix - **A radar that connects but never sends data now counts as off.** A radar that connected and then failed its startup exchange on every attempt was treated as on each time. The drop alert restarted its wait and never sounded, the warning for riding without the radar read it as on, and the walk-away alarm was held off. So you could ride with no rear cover and nothing to tell you. The radar now counts as on from the first data it sends, and its status reads "Connecting…" until then. - **Switching eBike data on or off takes effect at once.** Switching it off, in Settings, by going back in setup, or by answering "I don't have one" there, left the app still reading the bike, so the warning for riding without the radar could still sound. Switching it on in Settings did nothing until the app restarted, although Settings said the data was on. Switching it off now also forgets the bike's last reading, which the forgot-to-lock reminder and the drop banner's "but bike unlocked" used with no age limit. - **Close passes are measured where the vehicle draws level with you.** The clearance was the tightest reading within 3 m behind you, often a car still in line just before it pulled out to pass. It is now the middle reading of those within 2 m. A close pass's closing speed is now the fastest approach reading within 40 m behind you, where it was the reading as the vehicle drew level, which is often near zero. - **A vehicle that closes fast off to the side and moves in towards you as it slows is now counted.** A pass used to count only if, at one moment, the vehicle was both closing fast and within 1.5 m to the side (2.0 m with you above 30 km/h). The clearance is now judged only where it passes, against your Lateral clearance threshold. - **One vehicle's close pass can no longer be credited to the next.** The radar can reuse one vehicle's ID for the next one straight away, and the new one could then be logged on the first one's approach. - **Readings closing faster than 126 km/h no longer count in close passes or the ride's peak closing speed.** Such a reading no longer sets the ride's peak closing speed, and no longer starts a close pass or sets its closing speed, whatever "Warn up to" is set to. The radar's phantom readings fall there, but so can a real vehicle, so this changes only the statistics and logged passes: beeps and the urgent warning still follow "Warn up to". - **The ride's tightest clearance counts only vehicles overtaking you.** It took any vehicle within 3 m behind you, so a car queued behind you, or one creeping past while you were stopped, usually set it. It now counts a vehicle only once it has closed in at your Minimum closing speed, and only while you ride at about 7 km/h or more. It takes each vehicle's clearance where it drew level, once the radar stops following it. A vehicle the radar lost in a dropout is left out. A logged close pass now also sets it when it is tighter.

  More…

  - **The overlay redraws when the radar switches between its two data streams.** The same vehicles reported on the other stream could keep their previous colours until something moved. ### Breaking - **Home Assistant close-pass events change meaning, under the same names.** `min_range_x_m` is now the clearance where the vehicle drew level, and `range_y_at_min_m`, `ts`, `side`, `rider_speed_kmh` and `vehicle_size` come from that same moment. `closing_speed_kmh` is the fastest approach reading within 40 m, so it reads higher. `threshold_m` is now your Lateral clearance threshold, where it was an internal limit of 1.5 or 2.0 m. Which passes are logged changes too, for the reasons under Fix: on the developer's recorded rides, at the default close-pass settings, they fell from 16 to 14. If an automation triggers on a threshold, check it still fires where you want. - **The ride summary's counts, clearance and closing speeds read differently.** `close_pass_count`, `grazing_count`, `hgv_close_pass_count` and `close_pass_conversion_rate` move with the passes logged, and grazing is judged on the new clearance. `min_lateral_clearance_m` ("Tightest clearance") reads wider and is Unknown on more rides. `peak_closing_kmh` ("Peak closing speed") no longer goes above 126 km/h. `closing_speed_p90_kmh` reads higher. The `tightest_pass` attribute's clearance, distance behind and time come from where the vehicle drew level, and its closing speed reads higher. The ride history on your phone moves the same way, with or without Home Assistant, and rides recorded before this version keep their old figures. Check ride-summary automations the same way. ### Features - **Experimental: hold the urgent warning for a vehicle already off to one side.** "Hold the urgent warning for vehicles to the side" is the first row in Settings -> Experimental, off by default. When a vehicle closing fast is already off to one side and too little of its approach has been seen to tell where it will pass, the urgent warning holds off briefly, and stays quiet if the vehicle then looks set to pass wider than your urgent warning clearance. The cost is that the warning for a close vehicle can come later, or not at all, and the switch's description says so. On the developer's recorded rides, at a 30 m alert distance, it removed eight urgent warnings, none of them for a vehicle that passed within 2 m of the radar, and delayed the first warning for eight vehicles that did by about a third of a second typically and 0.7 s at most. ### UX - **The close-pass settings say what they count.** Lateral clearance threshold: "Counts overtakes that pass closer than this to the middle of your bike." Minimum rider speed: "Counts a pass only if you were at least this fast as the vehicle closed in." - **"Warn when riding without the radar" says it needs eBike data on and Bosch Flow running.** It said only "With a Bosch eBike", so an owner with eBike data off could read it as covering them. The range-only radar's card in Settings, the README and the compatibility notes now say the drop alert needs the same. - **The Home Assistant device is now named "Bike Radar <device>".** The entity names Home Assistant shows start with it, unless you renamed the device there. Home Assistant keeps the entity ids you have, and on current Home Assistant a new install's ids start with `bike_radar`. ### Diagnostics - **The connection log notes a radar's first data and an eBike data switch-off.** Its line for the warning for riding without the radar now rounds the ride time up, like the wait it is compared with, so a warning on time no longer reads as a second early. - **The capture log's urgent warning lines say whether the experimental wait was on.** ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. The fix for a radar that never sends data can make the drop alert, the warning for riding without the radar and the walk-away alarm sound where they stayed silent, and switching eBike data off now stops that warning. The experimental wait changes nothing unless you turn it on. The Home Assistant device is renamed, as under UX. No change to the Home Assistant topics or which values are sent, beyond the meanings under Breaking, to which radars work, or to the cross-app contract. Ride history entries written from this version are marked version 2 in the stored file. ### Internal - The Privacy screen check now reads the Privacy screen's own text, in both languages. Tests pin the warning for riding without the radar through the service, a radar failing its startup exchange, the legacy stream's first frame, and how close passes are measured. An unused eBike service action is removed. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.8.1...v1.9.0
• Oct 2, 2026 1.7.1
  ### UX - **The Privacy screen and the README now list what the ride summary sends to your Home Assistant**, and say it is updated every minute during the ride: start time, distance, overtake and close-pass counts, the close-pass rate, closing speeds, clearances, time with traffic behind you, alerts per km and per hour, and the tightest pass with its time, side, vehicle size, clearance, closing speed and distance behind. - **The example ride, the volume step and the Alert sounds page now say why the volume buttons can change your wake-up alarm.** On those screens the phone's volume buttons change how loud the alerts are, and alerts use the phone's alarm volume so they reach you, which is the volume your wake-up alarm uses too. Only the volume step mentioned it before, without saying why alerts use the alarm volume. - **In Spanish, the all-clear is now «Carretera despejada»**, in place of «Vía despejada» and «Vía libre». The README's Spanish section calls a close pass an "adelantamiento cercano". - **In English, the riding-aid notice and the screen-reader summary of the overlay now say "All-clear"**, the name every other screen uses, instead of "Road clear". ### Compatibility

  More…

  - minSdk unchanged at 31; targetSdk unchanged at 36. No change to when any alert sounds, to what is sent to Home Assistant or its topics and entity names, to which radars work, or to the cross-app contract. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.7.0...v1.7.1
• Oct 1, 2026 1.7.0
  ### Features - **Hear the traffic alerts before your first ride.** Right after the "Before you ride" screen, setup now plays a 20-second example ride with the app's own traffic alert sounds, each captioned with what it means: one, two and three beeps as a car closes in, the all-clear once the radar sees nothing left within your alert distance, and the urgent warning for a car closing fast while you are stopped or slow. It plays only when you tap Play, and only while the radar is off. - **Set the alert volume during setup**, straight after the example ride. Play a test sound and set how loud the alerts are. The slider is the same Alert volume as in Settings, and the phone's volume buttons work on that screen too. They can change your phone's alarm volume, which your wake-up alarm also uses. - **A new Alert sounds page under Settings -> Alerts** lists the ride's alert sounds with what each means, including the pulses for the radar dropping and coming back, and plays each one when you tap it while the radar is off. It also opens the example ride and the volume step, so riders already set up can use both without going through setup again. ### Fix - **After a ride, the home screen stops asking "Finished your ride?" once your eBike is off.** Switching the bike off already told the app the ride was over, and the drop alert and its banner already went quiet for it, but the home screen never checked, so the question came up after every ride. It now shows "Waiting for radar", as it does after you tap "I've parked".

  More…

  - **A bike lock from an earlier ride no longer silences the drop alert.** The app kept the eBike's last lock reading for as long as it ran. On a later ride where Bosch Flow never connected to the bike, that old lock kept the drop alert quiet and hid its banner if the radar failed. A lock the bike has stopped sending is now dropped when a ride starts. On such a ride the drop banner behaves as it does for a rider with no eBike: it leaves out "but bike unlocked" and hides 40 seconds after the drop, unless "Keep the drop warning on screen" is on. - **The home screen is up to date as soon as you come back to it.** For up to 5 seconds after the phone left standby it could still show the radar as live when it was not, and for up to 5 seconds after you turned Bluetooth on from its banner it kept showing that banner. - **Settings now shows when Bike Radar blocked an app you allowed.** If an app you had allowed asked to use your radar and could not confirm it was the app you allowed, Bike Radar refused it, yet Settings kept listing it as able to use your radar. Its entry now says it was blocked last time, its Stop sharing dialog says how to let it back in, and the Settings summary of apps using your radar leaves it out. An app blocked before this update is marked only once it is blocked again. ### UX - **The Alert volume setting now says it sets how loud every ride alert sound is.** Its description said "approach alerts", although the urgent warning, the all-clear and the radar pulses follow it too, and it said the overlay flashes at 0, which it does not. - **The eBike screens no longer say your eBike's battery goes to Home Assistant.** It never did; only ride information is sent there. - **On the access question, Stop sharing is now red**, as it is in Settings, so it no longer looks like the Cancel button below it. - **The "not set up yet" line on the access question now starts with a warning icon**, so it reads as a warning about Bike Radar rather than about the app asking. Its Spanish wording no longer repeats a verb. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. The drop alert can now sound on a ride where an old bike lock used to keep it quiet (see Fix); no other change to when an alert sounds during a ride. No change to the Home Assistant topics, entity names or the values they report, to which radars work, or to the cross-app contract. ### Internal - The ride and the example ride play their sounds through one shared mapping, and the example ride's script runs through the same decider a ride uses rather than choosing its own sounds. Android Gradle plugin 9.4.1, Roborazzi 1.75.0 and setup-android 4.0.4. ## What's Changed * build: bump the gradle group with 5 updates by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/42 * ci: bump android-actions/setup-android from 4.0.1 to 4.0.4 by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/43 **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.6...v1.7.0
• Sep 27, 2026 1.6.6
  ### Fix - **Settings keeps showing when an app last used your radar after you save its access again.** Since 1.5.0, saving on the screen an app opens to ask for access reset that to "Not used yet" until the app next used your radar. - **If an app signed with a different key replaces an earlier one, its access question now starts blank.** It used to open with the earlier app's choices filled in, as though it already had access, although that access never carried over to it. ### UX - **The access question tells you when Bike Radar is not set up yet**, and to open it afterwards to finish setup. - **When an app you already allowed asks again, the screen says it already has access, and the top button reads Save.** It used to ask "Share your radar?" and offer Allow, which read like a new request.

  More…

  - **For an app you already allowed, the line above the buttons now says what Stop sharing does once both switches are off.** It reads "Stop sharing" removes that app's access, where it used to go blank. That line is also now marked for screen readers to announce when it changes. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to any alert, to the Home Assistant topics, entity names or the values they report, to which radars work, or to the cross-app contract. ### Internal - A test now pins that opening the app before setup is finished does not start its background service, even with its Bluetooth and notification permissions granted. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.5...v1.6.6
• Sep 27, 2026 1.6.5
  ### Fix - **An app asking to use your radar before you have accepted the "Before you ride" screen now shows you that screen, then its question.** Since 1.6.0 such a request was refused without a word, and the asking app could not tell that from you saying no. Now you tap through that screen once and answer the question in the same visit. A request made during a ride, or by an app that cannot be identified, is still refused with nothing on screen. ### UX - **When an app you already allowed asks again, the screen says how to stop sharing.** A line above the buttons says to turn both switches off, which turns the top button into Stop sharing. The second button now reads Cancel rather than Don't allow, because it leaves your choice as it was. - **The buttons on that screen stay in place as you flip a switch, at any text size.** The line above them keeps its height when its text changes or goes away. Before, at a large font size, it could shrink and move the buttons under your finger.

  More…

  ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to any alert, to the Home Assistant topics, entity names or the values they report, or to which radars work. The cross-app contract version is unchanged. An app that asks before the notice has been accepted now gets the notice and the question instead of an immediate `RESULT_CANCELED`; asked during a ride or by an app that cannot be identified, it gets `RESULT_RIDE_IN_PROGRESS` or `RESULT_CALLER_UNKNOWN`, where 1.6.0 to 1.6.4 returned `RESULT_CANCELED`. The contract now documents `RESULT_CANCELED` as meaning nothing changed, with any earlier grant still standing, and says to treat a result code you do not recognise as no grant. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.4...v1.6.5
• Sep 24, 2026 1.6.4
  ### Fix - **The ride notification no longer says the overlay is hidden during a call.** Since 1.6.3 the overlay shows during a phone or internet call even when another app you allowed has hidden it, but the notification kept saying "Overlay hidden" throughout. It now leaves that line off for the call and puts it back when the call ends. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to any alert, to the Home Assistant topics, entity names or the values they report, to which radars work, or to the cross-app contract. ### Internal

  More…

  - Tests now pin the check that keeps the approach beep quiet for a vehicle reported more than 10 m to the side: its limit on either side of the bike, that cars in the neighbouring lanes still beep, and that a rejection is logged. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.3...v1.6.4
• Sep 24, 2026 1.6.3
  ### Fix - **With an eBike, the app stops trusting its data once Bosch Flow stops sending it.** The app takes your speed and whether you are climbing from Flow. When Flow went quiet mid-ride, the app kept using the last values it had for as long as the silence lasted: a bike that had been stopped still counted as stopped, which kept the approach beeps quiet, a bike that had been moving still counted as moving, which kept the urgent cue shut, and a climb stayed a climb. Those values now lapse 3 s after Flow's last update, and the app goes back to the speed the radar reports, as it does for a rider with no eBike. If your radar does not report your speed, that leaves no speed at all while Flow is quiet, so the urgent cue cannot sound until Flow resumes. Flow normally updates several times a second; in 5 of the developer's 80 ride logs with eBike data it went quiet for more than 3 s, once for over 42 s. Replaying 211 recorded ride logs gave each one the same count of every alert as before. - **A second radar drop during a pause gets its own alert.** If the radar dropped and you were alerted, then it came back and dropped again while alerts were paused, the second drop inherited the first one's alert count and timing, and could stay silent or sound late once the pause ended. It now gets its own alerts. The same applies when the radar comes back too briefly for the app to notice. - **A hidden overlay comes back during a call.** The app's alert sounds are off during a phone or internet call, so if another app you allowed had hidden the overlay, nothing from this app showed you the traffic behind you. The overlay now shows during a call whatever that app asked for, and hides again when the call ends. The consent screen and the Privacy screen now say so. - **The alert volume applies as soon as you let go of the slider.** It used to reach the beeps only when the app started or the radar connected, so a change mid-ride waited for the next reconnect. A beep or volume change arriving just as the app stops can no longer crash it. - **An alert or overlay setting changed just as the app was starting could be ignored.** The older value could stay in force until you changed a setting again or restarted the app. The newer value now applies. ### Diagnostics

  More…

  - **The capture log records a call while another app has the overlay hidden.** The overlay coming back for the call and going away after it both leave a line, and the Privacy screen says so. - **An overlay that cannot be shown is logged once, not on every frame.** The capture log gets one line each time the reason changes, so a missing permission no longer fills it. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to the Home Assistant topics, entity names or the values they report, or to which radars work. The cross-app contract version is unchanged. During a call, an app's request to hide the overlay is set aside and the app is not told; it applies again when the call ends. The contract's documentation now says so. ### Internal - Tests now pin what a pause does: no alert sounds while paused, not even the urgent cue; resuming announces a car still behind you; a drop still under way when the pause ends is announced then; and a radar that comes back during a pause, after its drop was announced, gets its "back" pulse when the pause ends. `AUDIO_DESIGN.md` now describes the pause. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.2...v1.6.3
• Sep 23, 2026 1.6.1
  ### Fix - **The app no longer thinks you are still cornering long after the corner.** It reads turns from the phone's motion sensor, and a phone on the handlebar feels every steering correction. The app counted a turn as lasting until the handlebar went still, which on the road it rarely does, so after a real corner it could stay convinced you were turning for half a minute, and once for almost three minutes. While it thinks you are turning it holds back the "road clear" chime, because a corner swings the radar off the car behind you, and it is stricter about a vehicle first seen close behind, because a turn can make a nearby vehicle look as if it is closing. Both stayed on along straight road. It now judges a turn by how far you have actually rotated one way over the last few seconds, which steering wobble cancels out, so the turn usually ends soon after the corner does. Comparing what the old version logged on twelve of the developer's commutes with the new one replayed over the same rides, the share of riding time spent "turning" fell from 26% to 11% and the longest "turn" from 173 s to 17 s, while 190 of 209 corners confirmed by GPS were still recognised, against 193 before. - **A vehicle closing in behind you on the straight after a corner is no longer kept silent by the corner you just left.** On one of those rides a car was behind the rider on the straight after the first corner with no beep, because the app still thought they were turning, and it overtook in the next corner with no beep at all. In the replay it now beeps on that straight. The "road clear" chime is also no longer held back for minutes after a corner: on another ride it sounded two and a half minutes after the last vehicle had gone. - **What the change costs.** A slow, sweeping bend can stop counting as a turn while you are still in it, so "road clear" can sound before that bend ends. And on those rides one vehicle that crept up to about 5 m at walking pace during a corner, then dropped back, was announced before and is not now. In the replay, a "road clear" followed within 3 s by a beep (a false all-clear) happened as often as before, but two of those are new, on straight road, where the old version was still holding the chime back. ### UX - **The corner setting under Alerts has a clearer name.** It now reads "Hold the all-clear in corners" (was "No false all-clear in corners"), and its description says it holds the chime back while you turn.

  More…

  - **One more Spanish string no longer tells you that you roll.** The warning before you share a capture log still said "rodar" (to roll) for riding; it now says "montar en bici". ### Diagnostics - **Capture-log turn lines carry different angles.** A `# turn state=TURNING` line now records `win_deg=`, the rotation that started the turn, and a `HOLD` line `turn_deg=`, the turn's total. They replace `cum_deg=` and `total_deg=`, which added up every steering correction since the handlebar rotation last went quiet, so a 1.6.1 capture reads differently from earlier ones at those lines. The `# turn yaw` lines are unchanged. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to the Home Assistant topics, entity names or the values they report, and no change to which radars work. ### Internal - Source comments on the filter for vehicles first seen close behind now say what a turn can make look like closing speed, and that the bar for admitting one mid-turn is a margin over it rather than a bound. **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.6.0...v1.6.1
• Sep 22, 2026 1.6.0
• Sep 19, 2026 1.5.1
  ### Fix - **Close passes are measured where the vehicle is actually beside you.** The clearance used to be taken from any moment after the radar started following a vehicle, and a car sitting directly behind you reads as dead centre, so a pass was often logged at a few centimetres that never happened. It is now taken only while the vehicle is within 3 m of you along the road. A pass is still recognised from far back, but one the radar stops following before the vehicle gets that close is no longer logged at all. - **A sideways reading of exactly zero is no longer taken as a clearance.** It means either that the radar gave no answer or that the vehicle was dead behind the bike, and neither is a pass at 0.00 m. Together, on the developer's own rides, the two changes cut logged close passes from 106 to 18 and those under 0.10 m from 70 to 2, and the typical clearance rose from 0.06 m to 0.54 m. - **The minimum clearance sent to Home Assistant follows the same two rules.** `min_lateral_clearance_m` took the narrowest sideways reading at any distance, so it kept reporting centimetres on rides whose close passes no longer did, and the two figures disagreed. - **Turning the dashcam switch off keeps the camera you picked.** One tap on the switch used to cost you the pick. Off now means the app stops using the camera, and on brings the same one back. ### Security

  More…

  - **The app only connects to read the battery of a radar or the dashcam you are using.** It used to connect to any paired accessory whose name it recognised, picked or not, read its battery, and publish it to Home Assistant if you use that. A camera you had switched off, replaced or never chosen was included. It now leaves those alone. ### Breaking - **Home Assistant automations keyed on close passes will fire less often.** `close_pass_count`, `grazing_count` and `hgv_close_pass_count` read lower and `min_lateral_clearance_m` reads looser, for the reasons under Fix. The close-pass counter and the tightest pass in the ride history on your phone move the same way, with or without Home Assistant. The drop comes from this change, not from your setup. If an automation triggers on a threshold, check it still fires where you want. - **`min_lateral_clearance_m` now reads Unknown on more rides.** It has no value on a ride with no usable sideways reading while a vehicle was within 3 m, and Home Assistant then shows the sensor as Unknown for that ride. The ride history on your phone shows no tightest pass for such a ride either, and rides recorded before this version keep the old, tighter figure with nothing to mark the difference. - **A Home Assistant battery sensor for an accessory that is neither a radar nor the dashcam in use stops updating.** It keeps its last value instead of going unavailable, so it can look live when it is not. Delete that entity in Home Assistant, or pick the device as your dashcam to start the updates again. ### UX - **With the dashcam switch off, Settings shows which camera is still saved and lets you clear it.** Clearing only makes the app stop remembering it. It stays paired in Android's Bluetooth settings. - **A settings switch is one thing to a screen reader.** TalkBack announced the text and then a nameless switch beside it, and only the small pill took the tap. The whole row is now the switch, announced with its title and description. ### Compatibility - minSdk unchanged at 31; targetSdk unchanged at 36. No change to the Home Assistant topics or entity names. What has changed is the numbers some of them report, and how often one has no value. The Breaking notes above say which. ### Internal - **Every push to main now boots the stripped release build.** The automated boot check ran the debug build, which skips the step that strips unused code from a release. It now installs the stripped build, debug-signed, on an emulator and fails if the app dies in its first seconds. It cannot reach Bluetooth or the overlay, so it shows that the release starts, not that it works on a ride. - Every Kotlin, AIDL, Python and shell file carries a licence identifier and a copyright line, checked on every push, and the grant for apps built on the radar interface now names its copyright holder. - Dependency updates: the Kotlin Compose plugin 2.4.20, Compose 2026.09, navigation-compose 2.10.1 and Robolectric 4.17. ## What's Changed * build: bump the gradle group with 5 updates by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/39 * ci: bump actions/setup-java from 6.0.0 to 6.0.1 by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/41 * build: bump the gradle group with 3 updates by @dependabot[bot] in https://github.com/partymola/android-bike-radar-overlay/pull/40 **Full Changelog**: https://github.com/partymola/android-bike-radar-overlay/compare/v1.5.0...v1.5.1
• Sep 9, 2026 1.5.0
• Sep 2, 2026 1.4.0
• Aug 30, 2026 1.3.0
• Aug 21, 2026 1.2.0