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

Re: [GSoC] Introduction and Project Discussion



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


Reply to: