Because a message we queue from the foreground may cause the background to complete, exit, and tear down the AsyncTask, we have to block queue processing until we've finished our call to AsyncTask::send().
Broadening the scope of a mutex is scary, but I audited the code of our four implementations of AsyncTask and I don't see any way this could cause a deadlock.
Only the logo view’s baseline is aligned to the attribution view’s baseline; the X-height doesn’t need to be aligned. Previously, macOS ignored the X-height constraint inferred from the alignment rect, but now it honors it in addition to the baseline.
This updates the package script to include a pre-built iOS app in the published assets of the dynamic SDK. It symlinks the Mapbox.framework in that dynamic build to the demo app so the only real increase in size is the demo Xcode project itself.
The addtional step in the publish script checks that the Mapbox.framework that is symlinked in for building in the demo project can actually be built. If it cannot, then the step is skipped and the build will continue as it normally would. Since the demo app is currently not required for publishing it should not block publishing a build.
Updated comment to reflect that MapView's lifecycle callback in a fragment should be called from onDestroyView rather than on onDestroy. This is consistent with that MapFragment is doing.
* [macos] Deploy macosapp as part of releases
Added steps to the packaging script to archive and export macosapp. Upload the exported, compressed application bundle to the GitHub release when deploying a release.
* [macos] Explicitly named function argument
* [macos] Consolidated xcodebuild invocations
* [ios] Fix toCamera.centerCoordinate in shouldChangeFromCamera has same center as oldCamera.
* [ios] Update changelog.
* [ios] Remove unnecessary variables.
* [ios] Clarify changelog doc.
* [android] - downgrade minimum sdk version to 14
* [android] bump MAS version to the one which includes min sdk version 14
* bump lost version to 3.0.4
* [android] fix map snapshotter marker example
The reference to the MapSnapshotter needs to be held for the duration of the snapshot, otherwise it might be GC'd
* [android] MapRendererRunnable - avoid weak reference table overflow
Apparently on some devices the weak reference table is limited (numbers around 52000). Even though we don't use that many weak references, when GC is not called for a while they can stack up and a crash will occur before the GC has had the time to clear the references. The C++ peer now holds on to a global ref (strong) which can be obtained to queue the java peer and then release automatically so that the GC can take over after the runnable has been executed.
