On Mon, Mar 21, 2016 at 3:30 PM, Hans-Christoph Steiner <[email protected]> wrote: > > Hey Chirayu, > > Chirayu Desai: >> Hello everyone, >> >> I am a first year student doing computer engineering at the Silver Oak >> College of Engineering and Technology, Ahmedabad. >> I am interested in working on the project "Android SDK Tools in Debian". >> >> I have worked with Android in the past (and still do), in fact android >> is what got me into development and OSS. I am a CyanogenMod device >> maintainer, and I currently maintain most of the supported Sony >> devices. I have been involved with that project since 2012. As a >> result, I'm somewhat familiar with the android source code and build >> system, and while I have not worked too much with the SDK, I believe >> my past experience will help a lot in learning that. > > > Sounds like you have enough relevant experience, the tools for building > a ROM are basically the same as for building the SDK. How much have you > worked with Debian or a derivative (Ubuntu, Mint, etc)? Have you ever > done any packaging for Debian or any other distro (even cygwin or homebrew)? I've only been a user of linux distros for the most part. Ubuntu is what I started with years ago, Mint after that and then Arch Linux (which is what I have on my PC since I started "proper" development) Debian is what I prefer for any servers I have control over though, and I'm using Jessie on my personal VPS. So I have some experience with using / managing a debian install, some basic sysadmin tasks, but packaging is something I'll have to learn, and I believe I can do that before GSoC starts. > > >> Below lines copy-pasted from [1] for inline comments. >> >>> finish packaging all of the core development tools (lint, gradle-plugin, >>> SDK Manager, etc.) >> After reading the AndoidTools wiki page [2], it looks like there has >> been work to fork the relevant android projects into debian for >> getting the SDK part build, I can continue with that. >> >>> update android-tools and relevant pkg-java packages to the latest upstream >>> version >> The source already seems to be close to the latest, if not the latest >> (6.0.1r16, there is a r22 now which does have significant changes from >> r16) >> >>> update androidsdk-tools to the Android Tools Team style, and update to >>> latest upstream version >> The current version is r22, which would correspond to Android 5.1 >> Lollipop (API 22) >> The latest is r23, which corresponds to Android 6.0 Marshmallow (API 23) >> As for the Android Tools Team style, I take it to mean > > The versions in the Android SDK are super confusing. See the section in > the AndroidTools wiki about them. the r22 here, is not like the > android-22. It is actually like this: 6.0.1_r16 is like 6.0.1.16, and > 6.0.1_r22 would be 6.0.1.22. > Oh yeah, I was confused when I started writing this, mid way through the draft I had a realisation when I re-read the AndroidTools wiki page. I was also confused by the old style android-tools package, which appears to be deprecated now, and the new format of having source repositories under android-tools/ and their relevant packages. > >>> package new parts of the Android upstream source, including the NDK, target >>> platforms, emulators, Android Studio, etc. >> This would involve more repositories being pulled under android-tools/ >> It would be made easier by the fact that the NDK is less coupled with >> the build system than other tools, and there is also a repo manifest >> to build only the NDK - which doesn't fetch too many repos, especially >> if you don't count the prebuilt toolchains [3] > > Since Debian always builds everything from source, the prebuilts will > count too. Unfortunately, those can be harder... > Right. So that means even the prebuilt toolchains would have to be built from their android fork? That would be quite a bit of work. Doable, but a lot to compile. > >>> make all Android Tools packages build reproducibly >> I would look at the debian-reproducible project first, and see what >> they have done to make the building of any similar packages >> reproducible. >> Apart from that, I also saw some patches Google did to make the >> android build reproducible, and I believe we could use at least parts >> of that. [4], [5] are a few, and I remember seeing more / followup >> patches too. The point being that given Google is working on this too, >> we can expect to benefit from that work by taking what's committed in >> master, and more might also probably be available in future releases >> (N, after that..) > > The good news is that almost all of the SDK packages in Debian are > already building reproducibly. Its also nice to see that the Android > team is working on this themselves. So I don't expect it will take much > work on our part to make sure our packages are building reproducibly. > Nice! > >>> improve package build systems to be more tightly integrated with upstream >>> build systems >> One thing to consider with this is that the upstream in this case >> (android) is undergoing an effort to change build systems, moving from >> plain makefiles to ninja generated makefiles (soong), with a stop-gap >> system (kati) in between. See [6] > > That is good to know, thanks for that info! Maybe this will give us a > better integration point for our work. > > >>> add Continuous Integration tests >> This could involve the android emulator in some way, try to build a >> few sample apps with the SDK and see if they work. >> Could also use some tests from the android CTS[7] for this. > > Using CTS tests could be good. I find that running tests in an emulator > can be quite brittle, and require lots of maintenance. I think we can > start with tests that just build and run things as part of the build > process, and see how far that gets us. > Totally agreed. The qemu emulator is flaky. That sounds good, I'll look more into it. > >>> package and improve related tools, like apktool, androguard, fdroidserver, >>> drozer, etc. >> Doable, probably much easier as they would likely be independent tools >> then be something so tightly coupled as android. >> >> Overall, I view this as a good challenge for me, given this is a part >> of android I haven't worked too much with before. And that too for >> debian, which is something I've only used. >> It would be a great experience for me to be able to work with the >> debian project, and contribute with the help of the android knowledge >> I've gained over the years. >> >> I'll upload a draft proposal to Google's site if the above looks okay >> to you guys. > > Yes, sounds good, please upload a proposal! > I'll try to get it done by tonight, or tomorrow. I have exams in college right now, so that is what I was busy with for most of the day. i do have two holidays coming up before the deadline though so I'll be able to dedicate most of my time to this, and study things in detail to write a proper proposal > .hc > > >> Thanks and Regards, >> Chirayu Desai >> >> [1]: https://wiki.debian.org/SummerOfCode2016/Projects >> [2]: https://wiki.debian.org/AndroidTools >> [3]: >> https://android.googlesource.com/platform/manifest/+/master-ndk/default.xml >> [4]: >> https://android.googlesource.com/platform/build/+/6a66a887baadc9eb3d0d60e26f748b8453e27a02 >> [5]: >> https://android.googlesource.com/platform/build/+/d75d893da8f97a5c7781142aaa7a16cf1dbb669c >> [6]: >> https://groups.google.com/d/topic/android-platform/Hhl_4hfOONg/discussion >> [7]: http://source.android.com/compatibility/cts/index.html >>
-Chirayu
