[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] Introduction and Project Discussion

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:

Or try fixing this issue in apktool that is blocking it from working in

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.


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 <hans@at.or.at> wrote:
>> Chirayu Desai:
>>> On Mon, Mar 21, 2016 at 3:30 PM, Hans-Christoph Steiner <hans@at.or.at> 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

Reply to: