To reactivate the BETA program we should add a new build configuration that allows to install the beta versions of the app in a device that already holds the stable app, granting that both operate independently.
To get it, will be needed a buildType different to release (debug could be good enough) where at least:
applicationIdSuffix is specified, so that both BETA and sable versions can be installed in the same device;res/values/setup.xml are replaced by different ones (for instance, appending the same applicationIdSuffix) for the current build.The list of values to update in setup.xml should include:
cc @theScrabi , FYI. For any question or improvement, let's comment here :)
Follow up https://gitlab.com/fdroid/fdroiddata/merge_requests/2344
buildType or productFlavor with a different applicationIdSuffix. res/values/setup.xml specific for the new builtType, with new values for app_name, account_type, authority, document_provider_authority, file_provider_authority, search_suggest_authority, search_suggest_intent_action, data_folder, user_agent.sendStickyBroadcast(intent) in the app with calls to LocalBroadcastManager#sendBroadcast(intent).cc @davigonz
BUGS & IMPROVEMENTS
Sorry when I ask this question, but I don't see how this new beta build configuration differs from the old one. The old beta could also be installed separately to the stable version and operated independently.
@davivel Maybe we should also use a different icon for the beta app, so you can directly distinguish between this an the stable app.
@theScrabi
FYI: https://github.com/owncloud/android/issues/1227
Sorry when I ask this question, but I don't see how this new beta build configuration differs from the old one.
The old one is currently unmaintained.
The variant build configuration should allow to build the new beta easily.
Also, the new beta will be built from master, not from a separate branch. That should mean that any change included in the beta app should be available in the next official release, unless something really wrong is revealed during testing.
By the way, sorry for coming back so late, but finally the time has come :)
@lefherz FYI ^
Maybe we should also use a different icon for the beta app, so you can directly distinguish between this an the stable app.
I've created an icon variant for the beta app. Here it is:

Any feedback is welcome
CC @michaelstingl @theScrabi @davivel
Steps:
Manage SpaceCurrent: Crash
Expected: not Crash
Tested with Huawei 6P v7, Nexus 5 v5
@davivel @davigonz
Steps:
Current: Crash
Expected: Content shared
Tested with Huawei 6P v7
@davivel @davigonz
Both bugs ready to be tested, @jesmrec
Current: URL does not appear in login view
Expected: URL appears
Approved
@davivel @davigonz
The merge for the reworked metafile for fdroid is submited:
https://gitlab.com/fdroid/fdroiddata/merge_requests/2344
However I've noticed several things:
initWith debug here must be removed.Hi @theScrabi , thank you for the merge creation, I have several questions about the things you've noticed.
- The app must not be debugable, which means the line initWith debug here must be removed.
Why should the app be debuggable? Is it a fdroid requirement? We think that It would be good to keep this option enabled so that community can give us some logs to track and fix the errors easily, which is basically the aim of the beta version.
- fdroid can handle build flavors better than build variants.
We were discussing about it before the beta implementation, reading some documentation about the topic and we finally decided to use build variants because:
CC @michaelstingl
Hello @davigonz:
Why should the app be debuggable? Is it a fdroid requirement? We think that It would be good to keep this option enabled so that community can give us some logs to track and fix the errors easily, which is basically the aim of the beta version.
I see your point. However, I was not able to compile the app unless I disabled debug. As you said it, fdroid probities that.
We may have to ask the fdroid people if it is possible to have a debugable app in their repository.
About the build variants:
As I said fdroid was better in handling flavors, but in the end using build variants was not such a big problem, so we can keep that.
Hi again @theScrabi , I've just seen you've asked to fdroid people about uploading the app debuggable, thank you.
In case it is not possible to put the app debuggable in fdroid and we have to disable debugging, we will have to sign the apk but I can't see that part in the merge request build, it seems that the apk is being generated without signing it. How does it work on fDroid? Because Android system requires that all installed applications be digitally signed with a certificate
Fdroid will sign the app with their own certificate.
Hello again @theScrabi , I've just removed the debug flag and updated the oc-android-2.5.0-beta.1 tag with the recent changes in the code so you should be able to compile the app now.
Do you know when could it be published in FDroid? Thank you very much
The state and the buildstate of the app on fdroid can be found here:
https://f-droid.org/wiki/page/com.owncloud.android.beta
will it be automatically updated, once the gitlab PR comes into effect?
Yes
It's on fdroid! We did it! nice work, guys!
I'll publish a blog post announcing the new testing client tomorrow.
Hi @theScrabi , could you please check the url https://fdroid.org/packages/com.owncloud.android.beta/? It should include the beta owncloud apk and more details but Not found is shown instead.
Hm. God question why this does not work, but I assume that it might be because fdroid changed the website recently.
The URL https://fdroid.org/packages/com.owncloud.android.beta is working now. I would say our work here is done, the problems with the web and with the certificate are specific of F-Droid website.
Thanks everybody!
Most helpful comment
I've created an icon variant for the beta app. Here it is:
Any feedback is welcome
CC @michaelstingl @theScrabi @davivel