Closed IzzySoft closed 6 years ago
I'd like having the app on F-Droid too! It's just that I already had some of my apps on F-droid before and somehow they got removed so I lost interest π But I may give it another try ...
About the .apk
, is there an upload/submission form for your repo?
@markusfisch as for those removed apps: let me know their package names (and repo URLs), and I can check what happened. We might get that fixed.
As for the APK: No, no submission form. If you'd just attach them to the releases/
(see: Creating Releases in the GitHub Help) I'd pick them from there. Starting with the last release (v1.3.2) will suffice. Once set up, my auto-updater would pick new versions within 24h of your tagging and attaching.
Guess I'll set up a repo on GitLab for "submissions" soon. Currently it's mostly me hunting, but that way others could make proposals as well. I'd say GitLab (not Github) as sometimes apps not meeting F-Droids inclusion criteria are referred to me β and with F-Droid having its corresponding repo (RFP, Requests For Packaging) over there, that'd be easier for cross-referencing.
Sorry for the delay, I created a release and attached the latest APK: https://github.com/markusfisch/BinaryEye/releases/tag/1.3.2
The app that somehow vanished from F-Droid was de.markusfisch.android.shadereditor https://github.com/markusfisch/ShaderEditor
I think I also had de.markusfisch.android.wavelines on F-Droid but that one is quite old now.
Thanks! Find BinaryEye here now β and of course here :wink:
de.markusfisch.android.shadereditor hasn't vanished from F-Droid, see https://f-droid.org/packages/de.markusfisch.android.shadereditor/ β and the latest build was already added to metadata (as of 2017-12-10), so I'd expect it to show up soon:
Build:2.9.1,38
commit=2.9.1
subdir=app
gradle=yes
And de.markusfisch.android.wavelines is in F-Droid Archive now, with one package, added on 2013-12-15.
Great, thank you too!
Odd, I tried to find Shader Editor in F-Droid a couple of weeks ago and couldn't find it π€ Anyway, thanks for checking and I'm happy it's still available there!
I absolutely forgot filing an RFP for Binary Eye π± So here finally is the RFP.
Ouch. Failed. You have 2 binaries in the source tree. Those are not acceptable for the official repo. Could you somehow "get rid" of them? One way would be git submodules. That should definitely work for ZXing (their code is at Github AFAIR), but I don't know where your camera view comes fromβ¦
Well, the cameraview-1.8.0.aar
is just another open source library of mine:
https://github.com/markusfisch/CameraView
It's a binary library because I use this CameraView
in a lot of projects and it's quite handy if I can simply update the AAR file instead of a directory tree. I prefer embedding AAR's directly instead of putting them into some Maven repository because it's more robust.
It would be possible to simply include the cameraview
subproject from https://github.com/markusfisch/CameraView
into Binary Eye and remove the pre-built AAR. But it would end up to be the exact same thing, once compiled into an APK.
Can I declare the origin of those binaries in any way to make them acceptable? Would it be okay to do this in a branch?
It is a bit puzzling for me that, of all things, embedded binary compilations should be a problem. I mean, almost every modern Android app implicitly includes a number of binary dependencies that are declared in app/build.gradle
(e.g. https://github.com/markusfisch/BinaryEye/blob/master/app/build.gradle#L64). The only difference to my embedded AAR is, that Gradle automatically downloads them. I don't understand how that is acceptable but embedding AARs directly is not.
Thanks @markusfisch β good to know both are available in source! I've mentioned that in the RFP (could you please specify from where you built ZXing? There are several repos/forks offering that.
AFAIK there is a way to specify the two source repos in the build recipe at F-Droid (srclib
). I have absolutely no build experience (I'm one of the F-Droid maintainers, but my focus are "metadata": descriptions, links and the like). Hopefully one of our "builders" can come up with a recipe.
The ZXing jar was built from https://github.com/zxing/zxing
Please let me know if there's anything I can do.
Thanks! I've forwarded that. Our integrators still would prefer a gradle/submodule solution. Raw guess: a flavor should work for that? Inttegrating the two as submodules while keeping the binaries. Use the two binaries in the one build you run β and the submodules in the fdroid
flavor?
@markusfisch apart from the two JARs, our bot's report looks good. So now we're just waiting for your response if you could provide the two via git submodules combined with a build flavor (so you don't need to recompile each time, but we can).
Speaking of a grade/submodule solution, would it be okay to include the libraries via a Maven repository?
diff --git a/app/build.gradle b/app/build.gradle
index 1444135..7fdffe3 100644
--- a/app/build.gradle
+++ b/app/build.gradle
@@ -60,8 +60,9 @@ dependencies {
}
testImplementation 'junit:junit:4.12'
- implementation fileTree(dir: 'libs', include: '*')
implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
implementation "com.android.support:appcompat-v7:$support_version"
implementation "com.android.support:design:$support_version"
+ implementation 'com.google.zxing:core:3.3.3'
+ implementation 'com.github.markusfisch:CameraView:1.8.1'
}
diff --git a/app/libs/cameraview-1.8.0.aar b/app/libs/cameraview-1.8.0.aar
deleted file mode 100644
index 872c5b2..0000000
Binary files a/app/libs/cameraview-1.8.0.aar and /dev/null differ
diff --git a/app/libs/core-3.3.2.jar b/app/libs/core-3.3.2.jar
deleted file mode 100644
index 0c713aa..0000000
Binary files a/app/libs/core-3.3.2.jar and /dev/null differ
Of course, I can do that in a build type/flavor (rather a build type because a flavor should be user visible):
diff --git a/app/build.gradle b/app/build.gradle
index 1444135..718aef7 100644
--- a/app/build.gradle
+++ b/app/build.gradle
@@ -41,6 +41,10 @@ android {
minifyEnabled true
shrinkResources true
}
+
+ fdroid {
+ initWith release
+ }
}
lintOptions {
@@ -60,7 +64,11 @@ dependencies {
}
testImplementation 'junit:junit:4.12'
- implementation fileTree(dir: 'libs', include: '*')
+ debugImplementation fileTree(dir: 'libs', include: '*')
+ releaseImplementation fileTree(dir: 'libs', include: '*')
+ fdroidImplementation 'com.google.zxing:core:3.3.3'
+ fdroidImplementation 'com.github.markusfisch:CameraView:1.8.1'
+
implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
implementation "com.android.support:appcompat-v7:$support_version"
implementation "com.android.support:design:$support_version"
But I'd rather switch to using gradle to keep things simple.
The maven repo must be one of the trusted, see https://gitlab.com/fdroid/fdroidserver/blob/master/fdroidserver/scanner.py#L98
@rudloff may I call you for assistance?
Well, if you could get the dependencies from one of the repositories we whitelist, that would be perfect. zxing is available on Maven Central: http://central.maven.org/maven2/com/google/zxing/core/3.3.3/ And CameraView seems to be available on Jitpack: https://jitpack.io/com/github/markusfisch/CameraView/1.8.1/
And of course, if you want to switch to Gradle entirely, there would be no need but a custom fdroid variant then.
Okay, then the first option should be fine! π
So I removed the pre-built libraries and fetch them from whitelisted repositories now: https://github.com/markusfisch/BinaryEye/commit/ac900ec8555ded01361abb088eec009e434e7455
I confirm ac900ec8555ded01361abb088eec009e434e7455 works correctly, thanks! Feel free to ping me when you tag a new release and we will work on publishing the app.
@markusfisch when do you plan to tag (just for orientation)?
@IzzySoft Just tagged 1.3.8.
There's a potential update to the camera library I was waiting for, but it's not all that important.
@Rudloff ^^ tag is there :smiley:
@markusfisch thanks! Just pinged Pierre as he's the one waiting for it.
Would you mind attaching the
.apk
to your/releases
for folks without Playstore? Or even better, having your app available at F-Droid? It looks pretty privacy-friendly, so us tin-foils would really appreciate it. For F-Droid, the blob inlibs/
might be an issue β but there's always my repo if you can provide the.apk
:wink: