Here are some other small contribution ideas: * attempt to build a simple Android app using the current packages, that would require downloading some of the pieces from Google, and file bug reports to the failing packages
* research the differences between the Android QEMU and the QEMU in Debian, to see whether we can use the Debian QEMU, and post the results on https://wiki.debian.org/AndroidTools * figure out how Google builds the Android SDK docs from source, and file a Intent-To-Package (ITP) bug report with that info * backport android-tools 5.1.1r29-2 to Debian/stable (jessie) .hc Hans-Christoph Steiner: > > Hey Chirayu, > > Working with the Android Tools team means coordinating with lots of > other projects like Android, apktool, fdroid, etc. It will help your > application a lot if we can see real contributions. You can try working > on bug in any Android Tools package: > https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org > > Or try fixing this issue in apktool that is blocking it from working in > Debian: > https://github.com/iBotPeaches/Apktool/issues/1166 > > The Android Tools team work is ongoing, so what needs doing will have > changed by the time the GSoC period has started. Also, as with any > technical project, it is difficult to predict how long chunks of work > will take. So we will work out the exact pieces you'll be working on > when the GSoC work period starts. If you want to work on specific > pieces only, that might be possible. We try to work as a team, and > decide together what needs doing when, and who is working on what. > > .hc > > > > Chirayu Desai: >> Hi, I have submitted a draft proposal. [1]: >> >> I would like to add something. >> >> This is a large project with multiple sub-projects, and I'm willing to >> work on either of those. >> I have past experience with Android, being a maintainer multiple >> devices for CyanogenMod, making them run on open source code, and >> porting newer android versions to them. >> >> My proposal includes a few of the suggested sub-projects, and I'm >> ready to change those with something else to not overlap with another >> student. >> >> I could work on a few from the below. >> * SDK, and tools to build android 'apk's - updates, and new packages >> * NDK - new package, for tools to create apps with native code (C/C++/etc). >> * Android Studio - new package, IDE based on Intellij IDEA >> * Emulator (and target platform) - for testing apps >> * make all Android Tools packages build reproducibly - study existing >> solutions, and apply them to current and newer packages. >> * Continuous Integration tests for the above >> * Third party tools for android development (such as apktool) - >> updates, and new packages >> >> The above list includes all but one from the wiki, which is: >> "improve package build systems to be more tightly integrated with >> upstream build systems" >> I have interest in build systems in general, and have worked quite a >> bit with android's make based system as well. >> However, as discussed in earlier e-mails, it is currently undergoing a >> transition. >> You can currently build the AOSP master tree with a ninja based build system. >> This would be something I would like to discuss further, say in the >> community bonding period, or even before that. >> >> Regards, >> Chirayu Desai >> >> [1]: >> https://wiki.debian.org/SummerOfCode2016/StudentApplications/ChirayuDesai >> >> On Tue, Mar 22, 2016 at 2:41 AM, Hans-Christoph Steiner <[email protected]> >> wrote: >>> >>> Chirayu Desai: >>>> On Mon, Mar 21, 2016 at 3:30 PM, Hans-Christoph Steiner <[email protected]> >>>> wrote: >>>>> >>>>> Hey Chirayu, >>>>> >>>>> Chirayu Desai: >>> >>>>>>> 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. >>> >>> Building everything from source is the end goal, but it is a large task, >>> so it could make sense to provide some packages that download Android >>> SDK/NDK binaries in an easy, automatic way (like the flash packages, >>> some font packages, etc). But everything in the main Debian >>> repositories must be built entirely from source. >>> >>> >>>>>>> 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 >>> >>> Ok, looking forward to it! >>> >>> .hc
