New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug/#1098 - Bump support lib to 26 #1204

Merged
merged 6 commits into from Nov 24, 2018

Conversation

Projects
None yet
2 participants
@cbalster
Contributor

cbalster commented Nov 24, 2018

The recent commits concerning #1098 only covered part of the problem: Having compileSDK on a different version than the support libs is guaranteed to cause issues.
This PR brings the support lib up to version to 26.x. Please note that I just made sure this builds an the tests run - there still might be some issues due to the rather large jump and the corresponding behavior changes in various components of the support lib. Ideally someone should go through https://developer.android.com/topic/libraries/support-library/revisions and check the notes for possible issues.

Most importantly this PR also raises the minSDK for the demo app to 14, since the 26.0 support libs require it.

cbalster added some commits Nov 24, 2018

Bump support lib version to match compileSdk
24.2.0 deprecates support for API 8 and lower
26.0.0 raises minSDK to 14

So basically to be able to upgrade and comply with the playstore
rules minSDK MUST be raised to 14!

osmdroid-android doesn't have any dependencies to the support lib,
so we can leave the main minSDK at 8 and only set it to 14 for the
packages that do require support libraries (MapViewer, simple-map,
wms). This way the core lib will remain compatible down to API 8.
BUT this also means that running tests on AVDs below 14 will not be
possible and thus compatibility for API<14 will no longer be tested!
Manifest cleanup
values are overridden anyway by values set in build.gradle
Mark license texts as non-translatable
to prevent lint warnings
Fix travis build without signing config
In https://raw.githubusercontent.com/gradle-fury/gradle-fury/v1.1.4/gradle/android-support.gradle
we have a hack to prevent builds from failing due to missing signing
config. This is done by removing the signing task from the build if
no keystore/pass is provided.

At some point the signing task has been renamed from
"validateReleaseSigning" to "validateSigningRelease", thus obviously
breaking the build again.

This simply adds a copy of the relevant code from
android-support.gradle adapted to the new name.

This should be cleaned up in the future!
@spyhunter99

This comment has been minimized.

Collaborator

spyhunter99 commented Nov 24, 2018

cool, thanks. building it now as a release build + sonatype push, then i'll drop the sonatype repo when done. it's really the only way to test this to make sure we can still release

@spyhunter99

This comment has been minimized.

Collaborator

spyhunter99 commented Nov 24, 2018

this is good to go, the only issue i ran into was related to my gpg key, everything else checks out

@spyhunter99 spyhunter99 merged commit a1156f5 into osmdroid:master Nov 24, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@spyhunter99 spyhunter99 modified the milestone: v6.0.3 Nov 24, 2018

@cbalster cbalster deleted the cbalster:bug/#1098 branch Nov 24, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment