OneBusAway
Support pure AOSP devices (non-Google and non-Amazon)
App no longer works on AOSP devices which aren't running the google spyware suite.
Previous versions must have packaged the maps libraries with the app binary, I guess. I haven't looked into the technicalities.
I'm assuming that the devs for this app have just decided that this isn't a problem. So, in the comments, does anyone know of an alternative way to get bus location data working with, say OSM, or any other alternative which is free.
It's not that it's not a problem, it's just not the biggest problem we have :). If it makes you feel any better, v1 of the app used Google Maps API v1, which was also only available on Google devices.
Supporting pure AOSP devices has been on my wish list for a while. The one major component we need is an open-source map implementation. Now that we support the Amazon Maps API v2 via Gradle build flavors (https://github.com/OneBusAway/onebusaway-android/issues/158), if we can find an open-source drop in replacement for the Google/Amazon Maps API v2, it would be relatively trivial to add an open-source build.
To my knowledge, however, this doesn't exist. The two closest options would be:
- OSM Droid - https://github.com/osmdroid/osmdroid/
- Mapzen Android (via tangram-es) - https://github.com/mapzen/android/blob/master/library/src/main/java/com/mapzen/android/graphics/MapzenMap.java
However, neither of these provide parity to the GoogleMap/AmazonMap v2 APIs (OSM Droid is based on Google Maps API v1, and Mapzen has it's own API).
If anyone knows of an open-source drop-in replacement for the Google Maps API v2, I'd be happy to add a pure OSS build for AOSP devices.
Actually, looking at the Mapzen classes, it's much closer to the Maps API v2 than it was in the past - Mapzen must have made significant progress lately.
Here's the MapFragment, which would be equivalent to the SupportMapFragment from Google - https://github.com/mapzen/android/blob/master/library/src/main/java/com/mapzen/android/graphics/MapFragment.java
However, there are still some missing classes - BitmapDescriptorFactory, MarkerOptions, PolylineOptions, and more.
I'll open an issue with the Mapzen Android SDK to see if full API parity is on their roadmap.
Thanks for putting the effort into making this happen. I'd even be happy if the onebusaway.org webpage was even slightly more mobile friendly. That's what I currently use and it's painful.
Unfortunately this is looking less likely to happen as Mapzen shut down at the beginning of the year, and their SDK was the closest to mirror the Google Maps API v2.
Have you tried http://pugetsound.onebusaway.org/enterprise/m/ on mobile in the interim?
It's a bit better than the old http://pugetsound.onebusaway.org/where/iphone/.
I had no idea that existed! Thanks! Is it supposed to work with GPS? I can't get Firefox or Chromium to prompt for access to my location. It simply says "Unable to determine your location" when I click the "Nearby Stops" or "Nearby Routes" buttons.
Yeah, it's not widely know, and I'm not entirely sure if it's officially supported in Puget Sound :). It's an artifact of the same server software stack being used in other OneBusAway regions and being officially supported in those regions. It's supposed to use device location, but it doesn't seem to be working on my Galaxy S8+ either.
Sorry, just fat-fingered on my mobile and accidentally closed the issue. Just reopened.
I can ask around and see if location not working is a known problem.
So the answer is real-time location for Nearby isn't supported, as the mobile site itself isn't officially supported. But you're welcome to use what is there that works.
Just popping in to note that this also affects LineageOS with MicroG - the app fails with "please install Google Maps." This is odd, because in principle MicroG is supposed to fake all the Google Maps APIs.
@nolanlawson Could you please provide a screenshot?
I'm interested in which exact dialog you're seeing.
Sorry, just fat-fingered on my mobile and accidentally closed the issue. Just reopened.
I can ask around and see if location not working is a known problem.
geolocation now requires a secure context (file, localhost, https) for some browsers. https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts
Is the MapBox SDK for Android an option? The API looks suspiciously familiar. :)
https://docs.mapbox.com/help/tutorials/first-steps-android-sdk/
I'm going to continue investigating I think, since there may be some quirks. I'm looking for a good mobile OTP frontend for my de-googled phone and breaking these play services/google maps dependencies seems like it might be easier than writing my own app from scratch.
@ellenhp Maybe! At a glance those docs look a lot more promising than the last ones I saw from Mapbox - they are definitely Android Maps v2-inspired at the least.
If the API is a 1:1 match with the Android Maps API v2 you should just be able to add another platform build flavor, like the Amazon one shown here:
https://github.com/OneBusAway/onebusaway-android/blob/master/onebusaway-android/build.gradle#L83
...and then update the copyMapsApiV2Classes task to copy the Google classes over to a new Mapbox folder and re-write the package imports to be from Mapbox instead of Google (the same way the Amazon platform flavor classes are written).
I started writing a Medium article on the above approach that I haven't finished yet, but feel free to take a look at the top part of the draft which explains the above in more detail: https://medium.com/@sjbarbeau/supporting-similar-sdks-with-one-code-base-7e7812e67708
breaking these play services/google maps dependencies seems like it might be easier than writing my own app from scratch.
To close the loop here, I ended up writing my own from scratch. No mobile client yet though. The project very predictably avoided solving the one problem that I originally intended to solve. 😆
@ellenhp oh, I remember seeing this on Hacker News in 2022 (here's our back-and-forth: https://news.ycombinator.com/item?id=31538083). Very cool! I didn't realize that this was the genesis of that project.
Ah! Yeah, I ended up doing exactly what I described. I don't think we support GTFS-RT but I've been away from the project for some time, so it's not a true OBA replacement. It uses OTP under the hood though so it wouldn't be terribly difficult to add. I think I might still have an API key for the Seattle OBA GTFS-RT feed, so maybe I'll talk to the current maintainer about getting that set up on maps.earth. :)