MapView.setUseBuiltInZoomControls(true/false). If this doesn't work for you, fork, fix, and pr. The old zoom buttons were actually built into the Android and were memory leak prone and will log some nasty warning messages under certain circumstances.Version 6.0.0 has some major changes. I'd suggest extensive testing with your application(s) before rolling out updates.
onPause and onResume. These calls are passed on to all overlays classes. In general, this was added to help reduce the amount of boilerplate code that users of osmdroid-android would need to do properly handle start/stopping the compass and gps sensors. This code was all incorporated into those overlays. Bottom line, you can probably delete any code you have in your application related to starting/stopping GPS or Compass overlays and replace it with mapView.onPause() and mapView.onResumse() calls.IConfigurationProvider interface. If you've written your own, expect to do some work (it's minor). If you've extended the DefaultConfigurationProvider, then you should be ok.view.setHasTransientState(true) when the MapView is created. If this causes issues, you can opt out of this setting via the new IConfiguration#setMapViewRecyclerFriendly(boolean) settingOpenStreetMapsTileProviderConstants have been removed. Replacement calls are now in IConfigurationProvider.setMapListener, replaced by add/remove MapListenerIConfigurationProvider interface. If you've written your own, expect to do some work (it's minor). If you've extended the DefaultConfigurationProvider, then you should be ok.SimpleFastPointOverlayConfiguration.getInstance().setMapViewHardwareAccelerated() before the MapView is created (layout inflation counts!)Overlay.onDraw() is now a public method.Configuration.getInstance(). This is a significant change and may cause unexpected behavior if you don't handle this situation in the future (the mount point with the most free space, can change, therefore you should handle setting the cache path as a user preference). Threadpools are now adjustable via this mechanism. User Agent is autopopulated by the application package name.No APIs changes, just bug fixes
No APIs changes, just bug fixes
Overlays no longer require a Context constructor
The "Doubles" branch was finally merged. This means that osmdroid uses doubles internally now for higher precision as lower zoom levels (higher numerically). All 1E6 based APIs are deprecated but still accessible. This does not resolve issues with zoom > 20 due to Android using an integer based coordinate system.
osmdroid has always stored map tiles to the local file system. When upgrading to 5.1 and from now on, downloaded tiles will be stored in a database named tiles.db which contains the tile source name, the tile id (x/y/z), and an expiration date. When osmdroid (or apps that use it) starts up, it will automatically prune old tiles from the database. This only happens when the map is created and it happens asynchronously.
Tiles that were already loaded in device....
TBD do we leave it or delete it? Or run an import routine, then delete from local storage....
Mapquest now apparently uses MapBox for map tiles. Go to MapBox's website to get an access token, then use that access token for both MapQuest and MapBox tile sources.
The MapBox tile source formerly used the "ACCESS_TOKEN" meta-data entry in the manifest. It now uses "MAPBOX_ACCESS_TOKEN".
MapQuest uses "MAPQUEST_ACCESS_TOKEN" and "MAPQUEST_MAPID" (default is "mapquest.streets-mb" if not defined)
Everything based on overlay has had it's constructor simplified in order to support the creation of overlays in an async task. As such, you may have some work to do for updating overlays. There was one field removed from the base Overlay class, mScale, which wasn't used anywhere except for the ScaleBarOverlay. The old api with Context parameters is still there but set to depricated.
If you were using OSMBonusPack with osmdroid, there's been some significant changes recently. Namely, everything but the KML/GeoJson parsing and online routing tools have been migrated (with Git history). As a consequence, several packages were shuffled around and renamed in order to prevent collisions and to better align with osmdroid's package structure. We also made some minor, hopefully non-breaking changes to the CacheManager and to Marker (both from OSMBonusPack).
Included with the migration of OSMBonusPack's capabilities is the Mapsforge Adapter, which lets you use on device rendered tiles with Mapsforge's rendering engine. Since Mapsforge is LGPL based license, so is this adapter.
Ever wanted Lat/Lon gridlines? We have to covered.
The command line and swing GUI tile packagers also received some attention and are now included with the distribution. This adds a number of bug fixes.
All my location type overlays were consolidated into it's own package
If you were previously using IMapController.isNightMode or setNightMode or extended IMapController, these functions were removed and migrated directly into the TilesOverlay. The same functionality can be implemented using the following
this.mMapView.getOverlayManager().getTilesOverlay().setColorFilter(TilesOverlay.INVERT_COLORS);
If you were using the ScaleBarOverlay, the constructor has changed from passing in Context to MapView.
There were some changes to the resource proxy interface. If you inherit from one of the provided implementations, you're probably good to go.
Output target is now AAR and the default osmdroid resources are now included (my location icon and whatnot). If you 'borrowed' those icons from osmdroid, you now will no longer need to include them.
If you use any custom map tile sources, a parameter was removed from the constructor so you'll need to adjust accordingly.
If you used a custom overlay manager, that class was interfaced and refactored. Please now extend from DefaultOverlayManager or implement the interface as appropriate.