Bike Radar

Releases

• 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