get minSdkVersion back to 14

[ildar]

I've CM9/Android 4.0 and got stuck with MissedNotificationsReminder version 1.1.5 Is there a strong reason to raise minSdkVersion ? Is it possible to at least fix https://github.com/httpdispatch/MissedNotificationsReminder/issues/12 for the oldware version? Thanks a lot!

[httpdispatch]

@ildar there are 2 product flavors: one for API 14+ and second for API 18+. I don't know why f-droid prepared only one build.

https://github.com/httpdispatch/MissedNotificationsReminder/blob/master/app/build.gradle#L102-L111

[ildar]

Thanks for answering. Am I understanding right that one can change to API 14 build with some kind of option set? If so, then could you give the instruction how to do that so I can forward it to F-Droid team?

[httpdispatch]

Looks like they forgot to add v14. You may compare

https://gitlab.com/fdroid/fdroiddata/commit/495409c0ac9bb48c61d3dc5d2ad00648c4827ca8 (has v14) and https://gitlab.com/fdroid/fdroiddata/commit/d4ae0c90726dbe017252a70b981fc018457d7f2c (v14 is absent)

[ildar]

thanks, reported back to f-droid.

[Grossdm]

@ildar, has there been any progress on an F-Droid build of version 1.1.19?

[ildar]

it wasn't even tried. https://f-droid.org/wiki/page/com.app.missednotificationsreminder notes that "VC is generated at buildtime", maybe this is the reason Autoupdate is off. @httpdispatch , can you comment?

[httpdispatch]

@ildar how i remember there was a problem with the build codes for v14 and v18. Recent version v14 code was always lower than any v18 code even for previous app version. I've reworked code generation and now recent v14 version has code higher than the previous v18 version. So perhaps it should be possible to enable autoupdate

[ildar]

ok, I'll contact F-Droid team. Thanks a lot!

[ildar]

ref: https://gitlab.com/fdroid/fdroiddata/issues/1337

[licaon-kter]

@httpdispatch It's not the higher version that's the problem but that VC is generated at buildtime (also versionName)

DEBUG: Directory: build/com.app.missednotificationsreminder
DEBUG: > git clean -dffx
DEBUG: ...fetch auto name from build/com.app.missednotificationsreminder
DEBUG: Parsing manifest at 'build/com.app.missednotificationsreminder/build.gradle'
DEBUG: ..got package=None, version=None, vercode=None
DEBUG: Parsing manifest at 'build/com.app.missednotificationsreminder/app/src/main/AndroidManifest.xml'
DEBUG: ..got package=com.app.missednotificationsreminder, version=None, vercode=None
DEBUG: Parsing manifest at 'build/com.app.missednotificationsreminder/app/build.gradle'
DEBUG: ..got package=com.app.missednotificationsreminder, version=${versionMajor}.${versionMinor}.${versionPatch}, vercode=None
DEBUG: Parsing manifest at 'build/com.app.missednotificationsreminder/app/src/v18/AndroidManifest.xml'
DEBUG: ..got package=com.app.missednotificationsreminder, version=None, vercode=None
DEBUG: Adding possible subdir app
DEBUG: fetch_real_name: Checking manifest at build/com.app.missednotificationsreminder/app/src/main/AndroidManifest.xml
DEBUG: ...couldn't get autoname
INFO: Finished

/LE:

Looks like they forgot to add v14.

Not really, F-Droid can't have two versions with the same versionName but different versionCode, it either builds v14 or v18

What are the exact differences (besides minSDK of course)?

/LE2: for DEBUG: ...couldn't get autoname above there's now https://github.com/httpdispatch/MissedNotificationsReminder/pull/32

[httpdispatch]

What are the exact differences (besides minSDK of course)?

@licaon-kter The main difference is in the actual notification listening implementation. The NotificationListenerService was added only in API 18. In API 14 i have to use AccessibilityService to monitor for incoming notifications.

[ildar]

No, Евгений, the issue here is the VC being calculated during the build. This makes Reproducible Builds very hard or impossible. The thing is very important for any build service, including F-Droid, of course

[ildar]

Oh, I may be wrong. If so, I'm terribly sorry. Just wanted to help

[licaon-kter]

@ildar More about building in an automated way. Where kinda far from represoducible ;)

[httpdispatch]

@lidar how i understand the problem is that app has 2 product flavors which is not supported by f-droid

[ildar]

@Licaon_Kter , how should VC be handled in case of two flavors? (VC for two builds should be different obviously). Can you give an example (in repo)?

[licaon-kter]

@ildar I guess you could release 2 versions every time (does Github allow this?).

• sdk14 version 1.1.20.14 versioncode XXX14XX
• sdk18 version 1.1.20.18 version code XXX18XX

Newer Androids can install either, but old Androids will get automatically updated only to the compatible version.

Normally we keep 3 versions so we could up this to 6 versions.

[ildar]

@Licaon_Kter , thanks. Yes, this should work. But that would require:

1. making useless commits to change VC forth and back
2. tuning f-d metadata per-version to use different flavors

And that way renders project flavors useless and even burden-some. Should there be a bug in F-Droid about that?

[ildar]

Opened this: https://gitlab.com/fdroid/fdroiddata/issues/1339

[licaon-kter]

1. making useless commits to change VC forth and back

Not commits, Tags (that point to the same commit)

2. tuning f-d metadata per-version to use different flavors

You need to manually update the metadata anyway since VC is generated at buildtime!

[httpdispatch]

@licaon-kter is there any issues with VC is specified at product flavor level?

[licaon-kter]

I don't think, but then again I don't read random build.gradle files for fun :)

I understand you want to update in one place only, don't get me wrong I like optimizations too, but these functions to generate versions feel like overkill, to what gain? Oh you don't update the version code in 3 places but only in one.... How many chars did you save? 6? Really? :)

[httpdispatch]

@licaon-kter This function is to reduce possibility of mistakes in version name/code. I've borrowed it from JakeWharton's U2020 project https://github.com/JakeWharton/u2020/blob/master/app/build.gradle

[httpdispatch]

@licaon-kter so how i understand i should do the following

1. move app name from titles.xml to strings.xml
2. add explicit version codes and version names
3. version names should be unique for every flavor
4. create 2 tags for every release

[licaon-kter]

move app name from titles.xml to strings.xml

I don't understand why you've split them up in the first place anyway

add explicit version codes and version names

Plain, not generated

version names should be unique for every flavor

And unique version codes Careful since you need to have them higher than current, else current users can't update. So you are stuck with this format: XXXXXXXXXX and you can't go below 2010119018 Eg: for 1.1.20 you could use say sdk 14: 301012014 -> 3 (<-bigger than 2 see above) 01 (dot) 01 (dot) 20 (dot) 14 (<-sdk)

Or you could skip any meaning in the code and be like 3000000114 where 14 is SDK, and 1 is release 1, and the rest is just the fluff you are stuck with.

create 2 tags for every release

If it does not bother you to change you current code and you think it's nice for fdroid to pick updates automatically, yes.

[httpdispatch]

@licaon-kter so are these codes correct 2010120018 for v18 and 2010120014 for v14

[httpdispatch]

@licaon-kter How will f-droid know which tag should be used for v14 and which for v18?

[licaon-kter]

How will f-droid know which tag should be used for v14 and which for v18?

Right, I don't think it can now, I'll explain, the new build block will follow the same pattern, so

• fdroidbot will see the new tags
• will copy the last build block to a new one for 1.1.20.14 code 2010120014 for sdk14
• but the last one had v18 as gradle flavour hence the new one will get it too
• will copy the last build block to a new one for 1.1.20,18 code 2010120018 for sdk18
• will set recommended version at 1.1.20,18 code 2010120018, but SDK14 devices will see only the SDK14 versions as recommended
• fdroid will build both versions from v18 (wrong)
• a human must edit the metadata....

TL;DR: Maybe this needs some more thinking, I'm not sure it can be fixed right now... :(

One idea could be to split the app in two, keep current ID for v18, make a new ID per flavour for v14 (or the other way around?), hence 2 app in F-Droid, from the same source, each one with its correct build block. But, this still needs the 2 Tags per release thing, eg. maybe add a prefix v18-1.1.20 / v14-1.1.20 than fdroidbot can pick on autoupdates.

Maybe...

[httpdispatch]

@licaon-kter how i understand independently of all these changes autoupdate will not work anyway and it is not possible to have autoupdate for apps with multiple flavors.

[ildar]

thanks to Licaon_Kter v. 1.1.19 will be in F-Droid soon. ref: https://gitlab.com/fdroid/fdroiddata/issues/997#note_99438664

[httpdispatch]

@licaon-kter thank you

[Grossdm]

Thanks to everyone for working on this!