Trackers added in the last release!

[IzzySoft]

My updater just pulled today's release and screamed an alarm:

Offending libs:
---------------
* Crashlytics (/com/crashlytics): NonFreeDep,Tracking
* Firebase Data Transport (/com/google/android/datatransport): NonFreeNet
* Google Mobile Services (/com/google/android/gms): NonFreeDep
* Firebase (/com/google/firebase): NonFreeNet,NonFreeDep
* Firebase Analytics (/com/google/firebase/analytics): NonFreeDep,Tracking
* Firebase Installations (/com/google/firebase/installations): NonFreeNet

6 offenders.

That's an absolute no-go for an app that should take care for personal data, so I had to remove Alpha-5 from my repo again and disabled auto-updates for now. I very much welcome your switching to per-ABI builds so I can keep multiple versions, which I'll certainly do once those trackers have been removed again. Can you please do that?

[XayahSuSuSu]

Does DataBackup-1.0.0-alpha05-arm64-v8a-foss-release.zip pass the test? If it does, can you just only track the foss builds of the future release?

[IzzySoft]

Does DataBackup-1.0.0-alpha05-arm64-v8a-foss-release.zip pass the test?

to 100% – not a single offender detected, wonderful!

If it does, can you just only track the foss builds of the future release?

Certainly! My updater understands regular expressions for which APKs to ignore and which APKs to focus on (here: ApkIgnore: /premium/i and ApkMatch: /v7a-foss-release/i, for example). But I need to pick an ABI then (my setup does not support multiple per-ABI builds at the same time – F-Droid.org does, so you might wish to apply for inclusion there – which btw is not necessarily an XOR, there are apps served by both repos). I'd suggest taking the armeabi for widest compatibility (even on older devices, currently only excluding the Pixel 7 plus which is arm64 only) but would be open to take arm64 instead if you prefer. Just let me know which one to pick once they're available at the release, and I'll set things up here accordingly, re-enabling updates.

Thanks a lot!!!

[XayahSuSuSu]

Does DataBackup-1.0.0-alpha05-arm64-v8a-foss-release.zip pass the test?

to 100% – not a single offender detected, wonderful!

If it does, can you just only track the foss builds of the future release?

Certainly! My updater understands regular expressions for which APKs to ignore and which APKs to focus on (here: ApkIgnore: /premium/i and ApkMatch: /v7a-foss-release/i, for example). But I need to pick an ABI then (my setup does not support multiple per-ABI builds at the same time – F-Droid.org does, so you might wish to apply for inclusion there – which btw is not necessarily an XOR, there are apps served by both repos). I'd suggest taking the armeabi for widest compatibility (even on older devices, currently only excluding the Pixel 7 plus which is arm64 only) but would be open to take arm64 instead if you prefer. Just let me know which one to pick once they're available at the release, and I'll set things up here accordingly, re-enabling updates.

Thanks a lot!!!

Noiice! Just follow ur suggestion, let's pick armeabi, will push new release soon:)

[IzzySoft]

Ugh, missed it's up already :see_no_evil: Just fetched 1.0.0rc1, re-enabled auto-updates and will now keep 3 versions. Thanks a lot! Issue solved :partying_face:

[XayahSuSuSu]

Ugh, missed it's up already 🙈 Just fetched 1.0.0rc1, re-enabled auto-updates and will now keep 3 versions. Thanks a lot! Issue solved 🥳

Thx:)

[XayahSuSuSu]

Sir I changed the package name for the next build, can you have a check for it?

[IzzySoft]

That means everyone using it needs to re-install. Are you sure this is intended? If so, is it possible to export/import settings (and whatever else is needed)?

PS: Apologies for the delay, I was on vacation.

[IzzySoft]

PPS: Whoever has the app installed with the original package name won't receive any update notifications to tell them they'd have to switch. So if you're sure you want to change the package name, how to inform existing users? Not even the release notes mention the renaming. Further, changing the package name also means the link to my repo will change.

So if you really want to change the package name, a suggested path would be:

1. build a last APK with the original package name which on each start pops up a message box telling to switch to the new application
2. I set up the new application in parallel
3. my updater pulls both
4. once both show up, you adjust the link in your Readme to the new package name
5. we give everyone a month or so to switch (exporting/importing config etc if possible), while I keep only the latest APK from the "old" package name (plus of course the new package name's APKs as usual)
6. I remove the "old" application from my repo.

[XayahSuSuSu]

PPS: Whoever has the app installed with the original package name won't receive any update notifications to tell them they'd have to switch. So if you're sure you want to change the package name, how to inform existing users? Not even the release notes mention the renaming. Further, changing the package name also means the link to my repo will change.

So if you really want to change the package name, a suggested path would be:

1. build a last APK with the original package name which on each start pops up a message box telling to switch to the new application
2. I set up the new application in parallel
3. my updater pulls both
4. once both show up, you adjust the link in your Readme to the new package name
5. we give everyone a month or so to switch (exporting/importing config etc if possible), while I keep only the latest APK from the "old" package name (plus of course the new package name's APKs as usual)
6. I remove the "old" application from my repo.

Thanks for these great suggestions, I mean to develop the latst version for the old package indeed and, it may take some time, will let you know when it's ready:)

[IzzySoft]

That sounds good! How long do you estimate will it take – round-about? Just asking as I get the alert every day, so if it's more than a week or two I'd like to tune down updates from (currently) once-per-day to once-per-month to avoid the annoyance :wink:

[XayahSuSuSu]

That sounds good! How long do you estimate will it take – round-about? Just asking as I get the alert every day, so if it's more than a week or two I'd like to tune down updates from (currently) once-per-day to once-per-month to avoid the annoyance 😉

It may not be soon, once-per-month is fine

[IzzySoft]

Thanks! Done that then. Gives us time until the end of the month, then pulls the most recent version again complaining to me once more, which can serve as reminder to check with you how far you've got :laughing:

[IzzySoft]

Looking forward to the next release then, thanks!

Btw, checking my notes and your releases: for IzzyOnDroid (which your Readme still links to), the updater was pinned to only fetch APKs matching /v7a-foss-release/i. There are no such APKs at the latest release. Will there be again at the next one? Will they still use com.xayah.databackup as packageName? If not, what are your plans concerning IzzyOnDroid?

[XayahSuSuSu]

Looking forward to the next release then, thanks!

Btw, checking my notes and your releases: for IzzyOnDroid (which your Readme still links to), the updater was pinned to only fetch APKs matching /v7a-foss-release/i. There are no such APKs at the latest release. Will there be again at the next one? Will they still use com.xayah.databackup as packageName? If not, what are your plans concerning IzzyOnDroid?

I'm so sorry sir, I almost forgot it :(

I'd follow your great suggestion, will build the last 1.0.x version with old package name(com.xayah.databackup) and inform users about this. Then we can migrate to new package(com.xayah.databackup.foss, 1.1.x and above).

Btw, now foss version is build from f-droid server, can we use the same apk in IzzyOnDroid?

[IzzySoft]

Cool! And yes, the IoD updater just takes the APKs you provide at releases. If you upload the F-Droid built APK there, that would be fetched. But that way you'd loose the advantage of faster updates, as you had to wait for F-Droid's build (which usually takes 3..5 days), then needed to fetch that manually and add it to releases (at least several more hours lost), and then wait for the IoD updater to fetch it (less than 24h). Which means a delay of a week instead of a delay of a few hours from the time of your new version being ready. You're sure you want it that way?

[XayahSuSuSu]

Cool! And yes, the IoD updater just takes the APKs you provide at releases. If you upload the F-Droid built APK there, that would be fetched. But that way you'd loose the advantage of faster updates, as you had to wait for F-Droid's build (which usually takes 3..5 days), then needed to fetch that manually and add it to releases (at least several more hours lost), and then wait for the IoD updater to fetch it (less than 24h). Which means a delay of a week instead of a delay of a few hours from the time of your new version being ready. You're sure you want it that way?

It seems that there's no better workaround for it, if I build foss version with my own signature, there'll be two different signatures for foss build, it may be confusing.

[IzzySoft]

if I build foss version with my own signature, there'll be two different signatures for foss build, it may be confusing.

You should have established reproducible builds. You still can switch to those at F-Droid – though that would mean for everyone having installed the app from there to uninstall and reinstall to move to the changed signature then. And F-Droid has no RB specialists anymore (the one they had left F-Droid, and those who left are now working together at IzzyOnDroid).

As long as there'd be two different signatures, that would mean people are stuck with the place they originally installed from. They wouldn't see the other one in their clients (unless they enabled the related expert setting). So you could e.g. look at it for a while and then decide whether you want to go RB (for easy switching), recommend one place over the other, or just point out the differences together with their pros and cons to let folks decide for themselves.

Of course, if you think that's too much, and your app available at F-Droid.org suffices, we can also remove it from IoD. Just sticking with a rather outdated version here would not be good.

[XayahSuSuSu]

if I build foss version with my own signature, there'll be two different signatures for foss build, it may be confusing.

You should have established reproducible builds. You still can switch to those at F-Droid – though that would mean for everyone having installed the app from there to uninstall and reinstall to move to the changed signature then. And F-Droid has no RB specialists anymore (the one they had left F-Droid, and those who left are now working together at IzzyOnDroid).

As long as there'd be two different signatures, that would mean people are stuck with the place they originally installed from. They wouldn't see the other one in their clients (unless they enabled the related expert setting). So you could e.g. look at it for a while and then decide whether you want to go RB (for easy switching), recommend one place over the other, or just point out the differences together with their pros and cons to let folks decide for themselves.

Of course, if you think that's too much, and your app available at F-Droid.org suffices, we can also remove it from IoD. Just sticking with a rather outdated version here would not be good.

It would be really a pity if we stop updating on loD :(

as you had to wait for F-Droid's build (which usually takes 3..5 days), then needed to fetch that manually and add it to releases (at least several more hours lost), and then wait for the IoD updater to fetch it (less than 24h).

How about this? I can move builds manually after froid builds are complete, it seems to be the only way to handle this.

[IzzySoft]

I can move builds manually after froid builds are complete, it seems to be the only way to handle this.

That would still mean having to wait for the F-Droid build cycle to succeed with a build. Might shave off 1..2 days from the above. Thus the only advantage you'd have were the additional checks done here at IzzyOnDroid, while losing the advantage of your releases becoming available faster. And those having installed your app from IzzyOnDroid would need to uninstall and reinstall one time as well, as the packageName changed.

Wouldn't it be preferable to achieve reproducible builds at F-Droid.org then? Yes, those having installed your app from there would then need to uninstall/re-install once (it cannot be avoided that one party has to). But then you'd have both advantages.

If you can run that F-Droid build and provide me the APK(s), I could check how close you are to RB already. Remember, the RB specialist now is with the IzzyOnDroid team :stuck_out_tongue_winking_eye:

[XayahSuSuSu]

Wouldn't it be preferable to achieve reproducible builds at F-Droid.org then? Yes, those having installed your app from there would then need to uninstall/re-install once (it cannot be avoided that one party has to). But then you'd have both advantages.

Well, I'll have a try, thanks!

[XayahSuSuSu]

If you can run that F-Droid build and provide me the APK(s), I could check how close you are to RB already. Remember, the RB specialist now is with the IzzyOnDroid team 😜

Hi sir, I'm trying on RB, I wonder can build in the same embedded path, and strip timestamps fix this error?