Re: [GSoC] Introduction and Project Discussion
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 <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: