 Hi everyone. Today I'm here to talk about the Android SDK tools in Debian. This project is a Google Summer Code project in 2015 and 2016 we've been working on. There are three Indian students and I work on this project. In this project we package basically package Android SDK into Debian. And so why are we doing this? The first reason is the SDK from Google is not free software. The SDK bundle downloaded from the website is not free software. It's not Apache 2.0, it's proprietary. If you use that you'll have some limitations. For example, you can't load any SDK component onto a mobile device or you can't even use the SDK to develop applications for platforms other than Android. And the next reason is by packaging SDK into Debian we can build it from source and we can make sure the SDK is reproducible. And we can make sure the SDK can produce a reproducible APK. For example, my mentor, Hans Christoph Steiner has passed Zbellion to add an option to zip out the timestamps inside the APKs. And we can also deploy completely free FJoy build servers provided that Android SDK is in Debian. So we can just use one line of command and you can install everything to deploy a build server of FJoy. It's like Debian. It's like Debian's build. You upload the Android source code to the server and it builds for you. And having Android SDK in Debian also is handy for... If you are going to route your phone or you're going to flash your ROMs you can just install ADB and fastboot. Actually, most of the people don't need other components in the SDK. They only need ADB and fastboot. And if ADB and fastboot are in Debian then you can just install these two. You don't need to download the entire SDK. And the last reason which is the most important one is packaging Android SDK into Debian. We can prevent the Xcode ghost on Android. Xcode ghost is IOS virus broke up in last year. There were about 1,000 applications were infected by this virus. First, most of them are Chinese apps. Those Chinese developers sometimes have difficulties accessing App Store to download the Xcode. It is very slow to download the Xcode from App Store. What they do is to download the SDK, download Xcode from web drives like Baidu Web Drive or other places and they are unofficial and maybe they are modified and actually they are modified planted with Xcode ghost and all applications combined with that Xcode is planted with Xcode ghost. And these apps are uploaded to App Store and you just download the apps from App Store and you get infected by the virus. It's terrible. You can't do anything if you are ordinary user. So in Android, it's way worse because in China every piece of Google is blocked. So you can't download the SDK without using a VPN. So I think many Chinese developers only download SDK from some unofficial places and perhaps this Android SDK has been planted with some virus. I don't know, but perhaps. So if we can download the SDK from Debian and everyone can get this SDK all around the world and we can make sure these SDKs are unmodified without any virus and we can prevent Xcode ghost happening on Android. So the current goal of this project is that we are making sure that we can have a minimalist build environment on Debian. You can just build the apps using one command line, Gradle, Assemble and that's it. We are not doing the full environment yet because they are too big. Additionally, we will do SDK and support libraries and Google libraries because they are necessary, sometimes necessary to build Android apps. And the SDK is too complicated to build from source for now. So we are doing it using a via installer package and the Google libraries are proprietary software so they are also via installer package. And we are not doing the emulator or system image for now because the system image is basically an entire Android system and it needs to build from several GB of source code. It's too big and practical for doing in Debian so it can be ignored for now. We can still do it with installer packages and the Android Studio is also too big for us so we are not doing this for now. And during the project we met some difficulties. Actually the first one is that they have too many versions. The SDK has their own version and the SDK basically has three components. The SDK tools, the build tools and platform tools and all of them have different versions. And Android has an API level and Android has its own version. So we are not... We didn't know in the first place how to... which tech should check out in the Git repo to download the table. But finally we settled down with the Android version. We checked out the Android version in the Git repo to get it upstream. And there is another difficult... There is another problem is that these components in the SDK typically has... Some of them have circular dependencies. For example, we have these two source packages and one produces ADB, fastboot, liblog and lib blah blah blah and the other repository has these two, f2, fs, utils and ext4 utils and turns out that fastboot depends on these two libraries and these two libraries depends on back to liblog and these two packages have circular dependencies. And what we did to solve this issue is that we used build profiles. Build profiles is a mechanism that you can make the package produce some components in stage one and produce the rest of the components in stage two. So what we did is that the first Android platform system called produce ADB and lots of things except for fastboot in stage one and then we have Android platform systems and actions for these two libraries and then we produce the fastboot at the full stage of that repository then it solves the circular dependencies. And we have other difficulties like some components need multiple upstream web posts. For example, the Android.jar which is the Android platform framework, API stuff, it's only API stuff but it needs four repos from the Android repositories and we don't like to merge multiple upstream into one package but we have to in this case. And there are also difficulties that the Android source code does not have a usable build system, a small build system. It doesn't have this. They have Android.mk in every directory and we can only read the Android.mk to handwrite the McFile to compile the libraries. It is handwritten so it's airplane and it needs too much work effort. So perhaps in the future we can develop some script to interpret Android.mk and automatically generate the McFiles. And some Android repos have C++ projects as well as Java projects so it's quite tricky to deal with a package with two languages. And finally Google also forked a lot of things. I say he forked because Google used those third party libraries but he also makes some little modifications. Maybe you are not aware of that but he just makes modifications sometimes the modifications are so big that you can't even build a project using the upstream libraries. And so far we have packaged two upstream libraries that are modified by Google which is LibUnwind and LibSE Linux. They won't interfere with the existing libraries in the system so we also packaged DocLava which is necessary to build the Android.java and they also forked OpenSSL which is boring SSL but we don't need to package boring SSL anymore because we later on found that boring SSL is not necessary to build the Android.java and also the Debian security team also objected to this idea. So the progress so far is that we have updated Gradle to 2.0. Before we did Google some of code back in 2015 Gradle was still version 1.5 and now it's 2.13 I guess. And we updated Gradle because we need to use the Gradle plug-in and now the Gradle plug-in is also inside Debian but the artifacts are not installed into memorepo so basically it's quite hard to use right now but we will polish the package later on and the Android.java is almost done and we have as I have said Android SDK has 3 components platform tools and SDK tools and build tools and we have packaged both of the platform tools here as we can see and we have packaged some of the build tools but we haven't been dealing with any SDK tools yet but we will do that later on but so overall this SDK is not usable for now because we have been testing using this SDK to build minimalist Gradle apps, Android apps and it just has errors so it's not usable for now but we are making progress so we are making progress but the progress is low so if anyone is interested in this project or you can join us or anyone has some questions you can ask us on these two IRC channels Debian Mobile, we will usually be in Debian Mobile channel and we usually put most of our information into the Android tools wiki page so any questions here? What's the long-term goal? Do you plan for example for Android in Debian to be usable with official Android Studio or other IDEs like I don't know IntelliJ or something like this Do you want for it to be usable with official emulators? What's the longer term goal? Longer term is that those emulators and system image will be packaged using an installer package so it's some kind of non-free software because it's hard to build from source and now the goal is that we are building a command line environment we can just build the apps using command line we are not doing the IDE for now because it's too big I'm not asking about packaging IDEs but for example when I'm installing Android Studio for example I can point it to already existing SDK on the disk so do you plan to provide something like this? So I'm installing all Android Debian packages then I'm installing per Android Studio and then I'm pointing it to USR-Leave Android Studio Android SDK something like that Well that is in our discussion now we think we can do that because we don't want our Android SDK in Debian and it's so limited so I think we can solve this problem we can just patch the code Okay Thank you Hello How do you deal with... do you package also Bionic Lib C and other core components to get a tool change so you can build this application and then when you... this is one question and then when you get the application do you have some kind of compatible layer that you can run the application in the Debian system or like hybrid library that provides I think like that I'm sorry I can't understand Okay This is Chiraru Desai he's one of the students working on this project Thank you Paichu I'm also working on this Bionic is used in the user space of Android so that is not something we are packaging right now what we are working on is getting the Android SDK into Debian so developers can build applications then as far as some sort of a hybrid layer we aren't working on anything like that right now or we don't have it planned but what we are saying is we haven't really thought about it it would be quite complicated to try to run an Android app to try to get the Android Java virtual machine running on Debian and then try to run an Android app and Bionic is also the Android Lib C we are not using that we don't need that to build apps it's in the NDK that's also something we are not doing right now any other questions roughly could you estimate what's your sort of percentage completion progress and how many more people would you need to get this done and say before Android 7 gets released Right now I would say that we are kind of halfway through the SDK thing we have identified what we need to fix like we have this one strange bug with app where it's an Android tool and if we use the binary Google provides it will work if I compile a binary myself from the Android sources it will work but if we use the handwritten make file that he wrote and if we try to compile a binary with that it crashes we have yet to debug that but that's kind of some of the challenges we are facing but apart from that we have everything in place so we just need to fill in the missing stuff and we should be able to build I would say a majority of the Android apps by the time we are done with GSock in August we should be able to build a lot of the Android apps So any other questions?