Just checked, it seems I have mistakenly deleted the folder (not sure when). 
1 Like
No problem! Probably for the best as we will now not get the old builds and new builds confused. 
1 Like
Yes, if it not a hurry, I can look into it. It will have to wait a few days, I think.
But do keep the CONTRIB file with the instructions. We just have the goal to move the credits list to an AUTHORS file. And if possible, we might add some copyright years and people to the individual files.
Sounds like a good plan! 
@vdbhb59 The SDK-15.0.0_r9 is uploaded. Do you still have the last link I sent you? Or do you need a new one? The link to the folder is the same, with all the files inside having changed.
For the group, what we really, really need now is some testers to make sure these work properly. Know anybody?
I have those links.But both the folders of yours show no files. I just checked. Maybe you need to allow share.
1 Like
Sent you a DM/PM with a new shared link. 
And SDK 14 is done.
Update: SDK 13 is done.
1 Like
EULA is included in SDK 12/12.1. More edits needed. Will investigate.
1 Like
A post was split to a new topic: Sources for termux-api
Okay, so SDK-12.1 and down included the Android system image file, which comes with the EULA clause.*
- Good call by @Slinger to not erradicate the EULA file directly, because now we see a different file pulling it in.
Question, does that apply to the system.img? I have to do some more research.
The fix for 14+ works to remove it from the SDK itself, but the NOTICE file with the EULA still comes with the system image.
Thoughts?
I am starting my new job today, but I still plan to look into this. But, if anyone beats me to it, that’s great too.
1 Like
Thanks a lot for your kind words. 
Sorry I have been away for so long. I thought I would be back after a few days, but it became more like a week. Good luck with the job! And please feel no hurry with this. It is greatly appreciated, and I’m still happy to help in any way I can, but I too have stuff that will cause delays. So maybe we can agree to keep working on this according to whatever schedule that fits? And maybe I should create a gitlab account after all, if I will be doing more editing beyond just the quick fix for the EULA?
Alright, we might have something else to look into regarding the EULA sneaking in. At the same time, I wonder: do we even need the system image? If it’s in a different zip, and we don’t need it to build apps, then maybe we can just skip it for now? Given amount of stuff it contains, it’s possible the android image is one thing google actually could force the EULA on? But I don’t know, I am not a lawyer.
By the way, I recall trying to set up a vm for development (without using gradle and the other tools). I don’t recall why, but I decided against it. Maybe because the image and/or the emulator was a lot of prebuilt and EULA-encumbered software(?). Instead I’ve been relying on adb and real devices. Just a simple rule/target in my build system to automatically reinstall and start the app using adb… maybe not the fastest but definitely enough for my simple testing needs.
Speaking of testing all of this: can we somehow use our own packages with the f-droid build system right away? I mean, that would make it possible to test building a lot of apps automatically. Maybe even make a custom f-droid mirror with apps built this way, so people can test whatever they want (when/if it built successfully)? That said, I am pretty optimistic it will work for building apps in the end. I did try one of your old SDK builds for my project and the resulting app worked fine. On the other hand, my build system is just a few makefiles instead of gradle, so it was easy to change. For apps using gradle it might be harder?
Actually, I just realized: do we need to make a modified version of gradle[w]? I am asking because many apps use it for the build, and I seem to recall two things:
- It tries to force the user to agree to the EULA (it will check for a file/stamp that indicates the user has clicked “I agree” somewhere in android studio or sdkmanager). And we don’t want that now, do we?
- It really likes to automatically download stuff. It might try to use the google packages. Or update itself to overwrite any changes?
So maybe a minimal adjustment that disables the EULA-checking, the self-updating and only downloads the ZIPs from our own URL?
So, I need to double check, but it looks like the EULA comes into play in the image because of the downloaded SDK used to build it, again, like a circular loop that we saw before. Seems a mute point, but hopefully tomorrow I can provide references.
- been a little busy with the new job, they make you fill out a lot of paperwork, like benefits and taxes.
Well, in and of itself, gradle is licensed as Apache2.0. License Information
Seems a shame to replace something that in and of itself is FOSS. Sure, it can download other things, which may or may not be Foss, but that is more user configuration than gradle itself, right? E.g., the files using gradle ask it to download that stuff.
Edit: my spell check changed gradle to cradle.
1 Like
No problem! I’m pretty busy at the moment as well.
I mean: since we don’t need the system image to build apps (and the most recent SDK versions doesn’t build it by default), can’t we just skip redistributing it?
Regarding gradle: my point is that it actively checks if the user has agreed to the EULA (the sdkmanager or maybe android studio will create a file stamp to signal that the user clicked on it), and gradle refuses to continue if that is not the case.
I am also concerned that it might try downloading the google SDK/NDK zips and replace our own (and itself). But it was a while since I used gradle, so I don’t remember if this is a problem. Maybe we can still use our own packages with the f-droid build system without any problems? The EULA enforcement in gradle still feels like a problem, though.
Yes it still does that. At least when I tried doing something 3 months back.
This sounds like a good option, but does beg one further question:
Do we just unzip the final product, remove and rezip? Or do we need to have that as an automated part of the building script, so people using our build script get the exact same product that we did?
Edit: By the way, sorry for the delays, my new job has very limited internet usage, slowing down my usual progress on this. Usually I work on this during breaks at work to pass the time.
Don’t most contracts have stipulations that creations on work time/services/hardware/property are owned by them?
1 Like
I checked with my company supervisors beforehand. I’m good to do this during breaks, as long as it doesn’t affect my work, they don’t really care. Most of my coworkers watch Youtube videos. I try to do things that are constructive. I have shown my supervisors that my work on these ‘side projects’ makes me a smarter employee in my IT field, and that makes them happy.
3 Likes
Again, please don’t feel bad for the delay. Any and all work you put into this is greatly appreciated, and I don’t see any kind of deadline to worry about. And I’m just as absent right now. I really should write together the way-overdue AUTHORS file.
I had assumed the system image would be inside a separate zip file. Is that not the case? At least it used to be we would get several zips (for build-tools, platform-tools, docs, etc). But now, looking at the files on @vdbhb59’s server, I instead see a single big zip for each sdk version, which in turn contains each of the previously mentioned zips… hmm… Is the system image bundled together in a zip with some other part of the sdk?
Also, if we really don’t want to modify gradle, it might be possible to just extract our zipped versions to where appropriate, create a dummy “I accepted the EULA” file stamp, and try using it directly with an f-droid build server?
@hans mate, how exactly do you mean by this? Emailing you about this now.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.