parawanderer/OpenTagViewer

Minor visual annoyance in app 1.1.0/1.1.1: when you restart the app and with Google Maps as the map provider, you will always have the map render itself staring at the maximum zoom out level, and show an animation zooming in to your position. This is annoying and fixable by preserving the last position the user was zoomed in to + the zoom level, and initialising the map from those if present, followed by the standard zoom to the user's current location. This is more aligned with how other map apps work and less visually disrupting. Note for anybody interested in implementing this It would be nice to have a video clip demonstrating the new behaviour in any potential PR

If you have an iPhone or iPad as well, you will notice that Apple's Find My updates a tag that this app says nothing about for hours. That is not a fetch bug, and no amount of work on the Apple-network path will fix it. This issue exists to answer the question once, and to point anybody who wants to close the gap at the work that would do it. The short answer An AirTag only broadcasts to the Find My network while it is separated from its owner's Apple devices. While it is connected to one of yours, no passing iPhone reports it, so there is nothing for this app to fetch — Apple's app is not fetching either, it is being told directly over Bluetooth by the device the tag is talking to. So the thing that makes Apple's app look better is the thing this app does not have: an Apple device in your pocket. When you will get a location A location report exists only when somebody else's Apple device walks past your tag while it is separated from yours. In order: Your tag loses contact with you

The map's tag cards currently spell the battery out in words: Nearby (●●●○○) · Battery medium An icon says the same thing in a fraction of the width, and that row is competing for space with the tag name, the signal dots and the time. This is a self-contained front-end change — no Apple protocol, no account, no network. What to change NearbyTagLabel.shortBatteryLabel returns a string resource per level. The four levels come from FindMyAdvertisement.BatteryLevel: Level Meaning FULL MEDIUM LOW VERY_LOW critically low Four states, and exactly four. There is no "unknown" on this path — batteryLevelOf defaults to FULL, so every sighting has one of these. The text is assembled in MapsActivity at the nearby_now_with_battery_and_signal / nearby_now_with_battery strings, so the icon needs to go into that row rather than into the string. Where the icons come from This project already uses Material Symbols and they are Apache 2.0, so nothing new needs adding. E

The connection-reuse fix removed the deterministic 429. It did not remove all of them. One turned up in the app while testing the 1.1.0 build: press sign in, 429, press sign in again, straight through. The deterministic case is real and still live at Apple Six unauthenticated POSTs to gsa.apple.com/grandslam/GsService2 with a junk body, down one reused connection: pooled (one reused connection): [404, 429, 429, 429, 429, 429] The shipped path avoids that, and still sees the occasional refusal The same six requests through FindMy.py's HttpSession, which routes gsa.apple.com through a force_close connector: unpooled (HttpSession, shipped): [404, 404, 404, 404, 429, 404] So the residual one is not connection reuse — every request there is a new connection. It clears on the next attempt, which is why pressing the button again works, and it is the argument for the app retrying a 429 once itself rather than presenting it as a failure. A user who does not know to press the button again re

Tracking issue for playing a sound on a tag that is near its owner. Ringing a tag that is separated from its owner is #139's job; this issue covers the case that path doesn't reach. The reading list and what has been tried so far are collected in docs/owner-connected-tags.md. Two control points Characteristic Used by Plays sound when 4F860003, non-owner control point anyone the link is unencrypted, and (per the DULT draft) only while the accessory is separated from its owner. Otherwise it answers Invalid_command. 4F860002, configuration control point the owner the link is encrypted with the bond key the owner's Apple ID holds What is known #193 (@LiamJ74): an iPhone ringing a RAVEMEN ABF01 writes to 4F860002 over a link encrypted with a stable LTK. Byte-identical writes from Android, unencrypted, are acknowledged and play nothing. Android's public API cannot encrypt a link with a supplied LTK, and the rooted BlueZ route failed because the kernel lacks N_HCI. A vendor Find