Cgeo: Prepare for targetSdkVersion 28

[SammysHP]

Starting with November 2019 all apps must use targetSdkVersion 28.

https://android-developers.googleblog.com/2019/02/expanding-target-api-level-requirements.html?m=1

[Lineflyer]

Oh no ... :)
Thanks for the early heads up! So next year, we might end up with the same game as this year unless we get it done before the dead line, which would be fantastic.

[moving-bits]

I have no idea how much work the switch in itself is, but as there may be a lot of follow-up work (as we have seen with targetSDK26) I suppose to do the technical switch as early as possible (like "now") on master branch, to have enough time for tidying up any unwanted effects created by the switch. (Tidying up can then be distributed among the whole developer team, like we have done the last time.)

@ControlTheBit @rsudev ?

[jonas-koeritz]

There should be a project to adress this:

• Latest targetSdkVersion
• Latest build tools
• Latest Google Play Services
• Latest Support Libraries

[Lineflyer]

@jonas-koeritz
Do you mean a github project to summarize related issues or are you referring just to "the work to do"?

Regarding the second:
As we are kind of a bunch of free-time developers its difficult to setup a proper project....

[moving-bits]

@jonas-koeritz Are you thinking of something like we have done for GoogleMapsV2 etc.:
https://github.com/cgeo/cgeo/projects ?

[jonas-koeritz]

@moving-bits, @Lineflyer yes thats what I think of, a simple GitHub Project Board where the fine-grained issues can be collected.

[moving-bits]

I like to raise this issue again, since the remaining time shrinks rapidly...
Proposal: Shall we set targetSdkVersion to 28 after release of the next feature version? Then we can continue with fixes on release branch, and have time for testing on master. What do you think?

[jonas-koeritz]

Should be okay, moving towards the latest target SDK as soon as possible is always a good thing to do.

[moving-bits]

@moving-bits, @Lineflyer yes thats what I think of, a simple GitHub Project Board where the fine-grained issues can be collected.

I created a project board to track SDK28 related issues and progress.

[moving-bits]

I created a PR which raises target SDK to 28. Compiles fine, and so far (after a _very_ short smoke test) no obvious problems. No in depth testing yet, but that's the reason why I would like to see this PR in the nighlies.

[jonas-koeritz]

I'm looking forward to catching up with the latest Android features :)

[moving-bits]

I'm trying to summarize the current state and give a proposal for the next steps:

Current state is:

• [x] last state before Google Maps v2 and targetSDK28 is merged to release branch and could be released if time permits
• [x] Google Maps v2 branch is merged to master
• [x] CompileSDK is increased to 27 to match with targetSDK
• [x] several libs (including support lib) are updated to more recent versions for a better with with compile and target SDK 27
• [x] A PR to push targetSDK to 28 is available (#7868) - It is compilable and a quick smoke test generally works, including Google Maps. There is one regression identified up to now (#7854), though, but that one's not a blocker.
• [x] Setting CompileSDK to 28 is not ready yet, IMHO, as it breaks our tests (#7866) and by this our CI builds. (And there's a second regression, #7865)

Given that state, I propose to

• [x] increase targetSDK to 28 as next step (= merging #7868) to continue work on this project, ie check if there are more regressions and to fix the identified one.
• [x] Upgrading our test framework (#7866) and tackling the other regression (#7865) can be done in parallel to this and merged into master as soon as the builds do not break any more.
• [x] After that is done, we can increase CompileSDK to 28.

By using this approach we can continue our work towards SDK 28 and still have nightly builds available, so that our nightlies testers can start testing based on targetSDK 28 to get us more feedback.

If no one objects I would do the targetSDK 28 merge in the next couple of days.

Any opinions?

[UniQP]

We should ensure the invariant compileSDK >= targetSDK (see https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd#ee11). Thus, I'm in favor of increase the compileSDK before the targetSDK.

[bekuno]

We should ensure the invariant compileSDK >= targetSDK (see https://medium.com/androiddevelopers/picking-your-compilesdkversion-minsdkversion-targetsdkversion-a098a0341ebd#ee11). Thus, I'm in favor of increase the compileSDK before the targetSDK.

After reading this document from the first line - I would say that we not have to switch at first the compileSdk. But for sure it would be fine that both on the same level.
Nevertheless c:geo worked in the last years with a compileSdk much lower then the targetSdk.

I did not saw in my tests (and with my not so high android knowledge) an easy way to swich compileSdk to 28 without errors. So for me it is fine to switch targetSdk at first.

[moving-bits]

From my understanding of the article, it is good practice to use relatively recent SDK levels for both, compile SDK and target SDK. So we should try to get both to 28 until release ideally. But it is not a "must have" (as c:geo has proven over at least the last year).

Currently, I would like to move forward with target SDK, as it is a requirement by Google to bring it at least up to level 28 until November, as otherwise we won't be able to upload a fix to play store any longer. From our experiences with updating target SDK level to 26 I expect a couple of side effect from this move. (One we have found already.) This is why I would like to get target SDK 28 into the nightlies as early as possible, to have a broader user base testing for possible side effects.

That said, I'm not against updating compile SDK as well, quite in contrast. I just don't want necessarily to have to wait for it until we update target SDK. If someone is able and has the time to fix #7866 during the next couple of days, the timespan with target SDK > compile SDK will be pretty short.

[moving-bits]

closed with #7868

[bekuno]

reopen it, it is not yet completed

[bekuno]

After PR #7880 we have now

• targetSdkVersion 28
• compileSdkVersion 28
• supportLibraryVersion = '28.0.0'

We should now check if the code also is fine for Google Play:
https://developer.android.com/distribute/best-practices/develop/target-sdk#prepie
https://developer.android.com/about/versions/pie/android-9.0-changes-28

e.g. https://developer.android.com/about/versions/pie/android-9.0-changes-28#apache-p
was alredy configured by @moving-bits

@moving-bits did you checked all points already?

[moving-bits]

@moving-bits did you checked all points already?

No, I haven't checked all of them, and I can't - I'm not deep enough into all bits of c:geo and Android programming. But that's another reason why I would like to get current master out as beta version soon, to have some broader testing during the next weeks, before targetSDK 28 is mandatory for uploading to play store.

[moving-bits]

How to continue from here?

With the combined effort of the c:geo team we've made big steps toward a target SDK 28 compatible version throughout the last weeks. How should we continue from here now?

• We have a long running beta version with a couple of functional enhancements. As far as I know this beta behaves well and could be released.
• We have a master branch with Google Maps v2 API and SDK 28 changes. All major / blocking issues are closed, IMHO, tests are green. Nightly build fails, though, due to the SDK 28 license not being accepted yet on the CI.

As I would like to not mix up the functional enhancements with the GMv2 & SDK changes, and as I would like to get a broader testing base for the GMv2 & SDK 28 changes I propose to

• publish current release branch (beta version) as release "ASAP" (aka: this weekend),
• fix SDK 28 license on CI to get the nightlies back,
• wait a couple of days, and if nothing serious happens
• publish current master branch as beta version by mid of next week.

This would give us app. two weeks of beta testing with GMv2 & SDK 28, and if everything goes well, we could release right before play store closes for updates of apps not supporting target SDK 28. We would even have 10 days or so for a potential bugfix or rollback, if needed.

What do you think?

[Lineflyer]

Yes, I think its time to release the current beta into the field.
I will crosscheck the play reports tonight and perform the release if there is no objection here and no critical things in crash reports.

Also your idea for the next steps are perfect.
Lets get the nightlies going again, test a few more days and in parallel wait for potential problems of the release.

Then we decide when its time to merge branches.

[Lineflyer]

While current release seems to perform realy well (lowest crash rate ever, no major complaints on support, no suspicious mass crash reports) we should IMHO wait with merging branches until we have some insights about the recently submitted issues about image loading and display.

I did however just publish a FB posting to tell Android 10 users, that we are working on it and invited them (and others as well) to join the beta program.

[Lineflyer]

Now that the image loading issue(s) are solved we could really think about merging branches and prepare a beta version.

@moving-bits @rsudev @bekuno @jonas-koeritz What do you think?

[moving-bits]

Yes, good idea. This gives us at least two weeks of beta testing until play store closes for non target SDK 28 apps.

[Lineflyer]

Feel free to fast forward release branch. I will afterwards handle changelog and beta release.

The only thing open is the Crowdin import as we had a lot of new strings recently. @rsudev ?

[Lineflyer]

If we want to release a beta version coming weekend someone of @cgeo/core should bring branch release up to date with master

[moving-bits]

I'm AFK for a week...

[Lineflyer]

Anyone else available for merging branches? @SammysHP ?

[SammysHP]

Done.

[Lineflyer]

Great, I will check it and prepare beta release today or tomorrow as time permits.

[Lineflyer]

Beta version with targetSDk28 has been compiled, smoke tested and uploaded to Google Play. It should be available to our beta testers within the next hour.
Keep fingers crossed and thanks to all helping hands for your work! A big step forward.

I will try to monitor beta feedback and crash reports over the next days.

[Lineflyer]

Version name is: 2019.10.22-RC2

[Lineflyer]

RC-version is looking good so far. Reported issues are:

• #7915 (unverified, not so relevant for now unless reproducible)
• #7909 (PR ongoing to improve UI)
• #7908 (fixed but only on master)

Really a good job so far, seems to work really good.

I would say we are able to release with targetSDK28 but should merge the "fix" for #7909 (to release branch) and should bring the fix for #79098 to release branch as well.

Anything else?

[moving-bits]

I'll look into the two PR (#7908 and #7909). When both are merged to release branch, we should be able to release.

The other two open PR (#7856 and #7918) should not be part of this release and merged later, as both should receive some time for testing on the nightlies first.

[Lineflyer]

The other two open PR (#7856 and #7918) should not be part of this release and merged later, as both should receive some time for testing on the nightlies first.

Yes, those should be kept on master.

[moving-bits]

The other two open PR (#7856 and #7918) should not be part of this release and merged later, as both should receive some time for testing on the nightlies first.

Yes, those should be kept on master.

As the parts for the next release have been separated from master, am I right that I can merge those two PR to master now to get them into the nightlies?

[moving-bits]

I'll look into the two PR (#7908 and #7909).

Done.

[Lineflyer]

Anything we could do to avoid the login message being shown while still logging in?

[moving-bits]

Anything we could do to avoid the login message being shown while still logging in?

Ok, finally managed to get a delay at startup, see #7928

[Lineflyer]

Nice...Working for me.

Now we should deal with translation. Its really time to find a smooth way to up/downlod our strings to/from Crowdin (e.g. via CI job...did I say this already :))

[Lineflyer]

BTW found this with Google: https://github.com/Khan/jenkins-jobs/blob/master/update-translations.sh

[Lineflyer]

@rsudev See above

[bekuno]

How about using
https://github.com/marketplace/crowdin ?

[rsudev]

There is a description of the process to sync the translations in the wiki (https://github.com/cgeo/cgeo/wiki/Translation-%28L18N%29). Unfortunately is the branches feature of crowdin not as robust and workable as expected (some strings have different translations on the branches, but this is not easily visible in the UI) and in addition you have to take into account, that as a free open-source project we can only build a download package once every half an hour. This makes an automatic solution a bit complicated.
I have thought about giving up the branches again, as with the current release cadence this seems not so relevant any more, but couldn't make up my mind yet.
I trigger a translation sync for release this morning and again tomorrow.

[Lineflyer]

As we have most translations in now and there is no significant activity on support mail and Play console with respect to the beta version I would like to set it live in the upcoming week.

Any objection?

[Lineflyer]

As there was no objection I will start with the release process:

• [x] Check/Import incoming Translations from Crowdin
• [x] Check/Insert correct version name as headline in changelog-release.xml
• [x] Build release on CI server
• [x] Perform smoke test with resulting cgeo-release.apk before continuing
• [x] Upload and publish cgeo-release.apk to Google Play
• [x] Tag the release on Github
• [x] Publish the release on Github including upload of cgeo-release.apk to Github
• [x] Publish release on F-Droid
• [x] Trigger notification to status.cgeo.org via CI server once the release is available on Google Play
• [x] Post release info to Facebook
• [x] Post release info to Twitter

[Lineflyer]

Should be online via F-Droid already. Play Store is still working on it.
I will update the status in the posting above later on accordingly.

[moving-bits]

Yeah, finally got the targetSDK28 version on the road 👍. @Lineflyer Thanks for preparing the release!

Now we need to figure out what the Google Play Developer APIs are (#7942) and what impact the version change does have on c:geo...

[Lineflyer]

We are done.

@all Well done once again. Indeed targetsdk is done. Time for more ;)