heh

@MatthewRead Yeah. And now he complains why we closed it, being such a specific question, asking what makes it off-topic. Didn't even bother to follow a single of the links from my comment it seems :( Told him to do so now.

Btw: Thanks again for your thorough answer on my application-debuggable question. I could give you some examples if you want, but there are several Github projects of Android apps (which you find neither in Play nor at F-Droid) having an app-debug.apk attached to each release (right, multiple that is), but no app-release.apk.

And admitted, I had "second thoughts" – namely whether to add such apps to my F-Droid repo or not. For testing purposes I've initially filled it with apps I'd normally not picked (most of those are removed again already) – and each time such a debug-able app was amongst, fdroid-server complained with a big warning "this app is debuggable" (but again gave no details why it's worth a warning).

So before striking the "experimental" from this repo's naming and making it public, I wanted to know whether I'd better a) remove those apps b) place a warning along or c) leave them as they are (with a "small print note" maybe).

@Izzy the main problem is that probably the app is signed with a debug key, not a proper signing key, so you can only upgrade the app to another APK built from the same SDK install

@DanHulme Good point! I was aware that there are different signing keys (debug vs release) but completely forgot this implication (stupid me)! At least worth a comment there to not get lost.

Still, at one point in development there should be a switch to the release-signed app. Maybe have one or two tags with both (giving testers room to switch) – but from what I have read up to now (especially the post done by Matthew), the dev should at least make the users "more relax" by showing some care :)

From what I read on another post, debuggable app might behave differently (using if-condition and checking the Manifest flag), so it's up to dev what they do with it: do they print it on LogCat? or even use publicly-displayed Toast? Other than that, dev tools are needed (e.g. LogCat, ADB, DDMS/Monitor). Android SDK Monitor can do these things on debuggable app. Still not sure about security implication from attacker side though

I don't think there is any security implication. If somebody would link the question I might be able to contribute, but I haven't seen it yet.

@DanHulme What are the security implications of using an app built “for debug”?

@Izzy To my mind, that's exactly the kind of question I was talking about in my answer to what policies we should change. He's not asking for recommendations or shopping advice: he has a specific problem, and wants a solution for it. He even says explicitly in the question that it doesn't have to be an app, it could be some way of post-processing the video.

@DanHulme Then it is very, very unlucky phrasing. Title: "Is there an app …", body: "I'd like to have an app … tried out a few apps … couldn't find any app". It nowhere says he accepts any solution but an app. I don't recognize the explicit statement you're seeing there – it could as well reference to a "post-processing app". In fact, that's what it says: "post-processing software". So I strongly disagree with you. This might be a well received question on SR, but not at A.SE.

And we have consensus on those "is there an app for X" questions: answers can recommend an app as solution for an issue – but questions cannot explicitly ask for. Beside that, explicitly asking for an app as solution can also be considered an XY problem :)

@Izzy I don't think you can call it the XY problem when he's telling us exactly what the problem is that he wants to solve.

You want to solve problem X but you're telling us Y... oh wait, you're telling us X as well

Sure he tells us X along – but he doesn't want "something" solving X, but explicitly Y. But I see your point: replace the "can" in my previous post here by "might" ;)

it's like the yes/no game: you have to go the whole length of your question without using the magic word "app" or gong your question just got closed

I'd tried to salvage it, but it seems too... localized/broad to me. There are many inter-related things: video, GPS coordinate -> geolocation, speed. It's like needing at least 3 apps: camera to record video, app to log GPS coordinate (to calculate the speed, I don't know if there's app that can record and log your speed), and the result will be combined with Google Maps Location History.

@AndrewT. yeah, I think his quest is a bit desperate

which is a shame really, as he made a good effort at describing the problem fully

it's a cut above the "help my screen is broken what can i do" standard

I think if those 3 components were asked as separate question, it might be salvageable.

(well, the video recording is trivial, probably no need to ask)

@Izzy No problem. @DanHulme 's point about the signing key is good, I guess I assumed we were discussing unsigned-release vs unsigned-debug. I would assume Google Play and other stores that require signing would also require non-debug versions....

@MatthewRead I agree. I also doubt F-Droid would offer such packages in its main repo :)

Unfortunately, I cannot even add this as additional AntiFeature with my repo (list of AntiFeatures is hardcoded) unless I change their code :)

@MatthewRead Hehe, just gave myself an idea: fdroidserver is open source, written in Python. 10 seconds, and the new AntiFeature was added #D

(in my clone, that is)

Just not sure what the client says to that …

hehe, nice

@MatthewRead Just updating sources in the client currently. Need to make sure my change doesn't make it crash when it finds an "unexpected antifeature" ;)

Luckily, my repo is still defined as "experimental", so noone can complain #D

Let me guess: the FDroid devs are all working on Windows. And their servers run on Windows. Who else would convert the entire URL to UPPERCASE when creating a QR code for the repo? Ouch.

Nice! Almost couldn't be better! The client notices an "unknown anti-feature", cannot translate it, and thus displays its name in red letters :)

So for affected apps, there's now a red eye-catcher showing ApplicationDebuggable – yupp, fine with me :)

And as for the web frontend: apt.izzysoft.de/fdroid/index/apk/com.netease.qa.emmagee

@Izzy Very nice

@MatthewRead Thanks!

A little more testing, and I soon can remove the "experimental" keyword. Will then integrate the repo with my main Android site :)

Also nice is that most apps are updated automatically from Github (those who have the .apk file under releases/ and tagging their releases correctly). Without updates, a repo wouldn't make that much sense :)