 My name is Anand. I work for an Arab. I am an Android coding engineer, as you can see from my touchy. So I will be covering Android coding basics. I will be covering coding into mobile phones like what sandwich and what do. I will be covering how you code Android on development boards. Development boards means with a board or any kind of development board which you are aware of. But these are not just limited to any particular board. These are very well applicable for mobile phones also. So let me get started. I will just go through the interview for this session. I will be covering the Android software stack. I will be covering what all different layers Android software stack consist of. Next important topic is Android open source project. I will tell you how to get the code, what the code consists of and what is the code structure for AOSP and how to build the configurations. How to configure the builds and how to configure the end end options. Then I will be covering Android boot process and lastly I will be covering Android debugging and troubleshooting. So we will start with Android software stack. So take some time to go through the layers. At the lowest level you have an experimental. The next level is the same. It says that it goes like if you are capable of running Linux on a device then you can very well learn Android on it. But it's just the same. It doesn't work most of the time. Because it has some memory requirements. The next you can run starting from 32 MB of RAM to it goes up to 1 GB and more. But actually anyone has attended yesterday's talk regarding memory optimization. So in that talk Mr. Satish talks about what is the minimum memory your system should be having just to run and run smoothly. But yes Linux kernel is something which is the building block of Android. Then second layer is Android hardware section layer. Android hardware section layer is that part of code. That part of software stack which talks in between which talks between which helps your Android framework to talk to Linux kernel and eventually the hardware. Then we have got libraries and entire libraries. Your media framework, your whole library is Dalvik VM. Then starts the Android application framework. There you can see all the system services, your media servers, your network payments, solution managers, everything is part of the application framework. On top of it you will find Android applications. It could be anything like this, it could be realistic term, few of them home, dialer, camera. So how it works is that once you start your application it has to go through the Android frameworks. It has to go through a couple of services or more services. Then it will talk to your Linux kernel, hardware, to your hardware section layer and this middleware libraries. I have also put a small firmware binary section here which is essentially it is not a part of your kernel, it is not a part of your hardware section layer. This is something which you load or which you have put loads on to the hardware directly. Now I am talking about Android open source project. First thing is how to set up your dynamic machines or how to set up your host and dynamic machines. If you people are aware of Android mailing list and all these Android official channels, communication channels. There is an Android engineer called JBQ. He recently shifted a mail on Android building list where he mentioned that what is the requirement for ICS. If you are planning to put ICS or if you are planning to use ICS and build it for your systems then what is the requirement it is going to be. So I have just done this section of that mail which says that it is going to be about 6GB of download, 25GB of disk space if you do a single build. Now what he meant by single build is that USB comes with a couple of tablets or a couple of bills, default bills and other ones. Plus you can add your own bills. So here 25GB is only for a single build. Now it is in your disk space to do all the bills, default bills which comes with a part of USB, 16GB RAM. And then he mentioned that how much time it took for him to build ICS on his dual core machine. This is mainly from the host machine point of view. Host okay. When I am talking about a host machine I am talking about your development machine. And when I am talking about a target machine then I am talking about your development boards or your machines on which you are planning to run and run. So the second point is initializing and load build environment. 64-bit Ubuntu 10.04 machine. It is just officially Google says that it has to be 64-bit Ubuntu machine to build a USB. But there are a couple of workouts available through which you can build and run on 32-bit machines as well. The other dependent packages are Sanjama. Sanjama is a core of Android. That is the way you have to run it. So this is a dependency. It is a huge list. If you go to this link, actually this is a link. This is a hyperlink. So if you go to this link you will find all the dependencies. Plus the commands which you have to run on your host machine to met all these dependencies. If you are using Ubuntu or a Debian-based machine then these are going to be apt-get installed for your Fedora and USB-based machine. You have to find corresponding targets. Now the point is AOSP code access. So here I will be covering what AOSP consists of. How to download AOSP code. And what is this rapport tool. Now AOSP consists of multiple independent projects maintained by Git. Now what does this mean? Git is a code versioning system which is vastly used in Linux world. So AOSP is not a single project. You should see AOSP code if you have downloaded any of these AOSP codes. You will find that it is a set of hundreds of independent projects. Git projects. So what Android does is Android releases a tool called repo. So repo is essentially a shell script. It is a wrapper over git. So what it does is it downloads each individual project from that repository. So that you don't have to do it manually or one by one. Because as I have told you those are independent projects. You can download them individually as well. Initially Android AOSP was hosted at kernel.org. But due to some recent events they have to move to the new location. It's android.googlesource.com. Currently you cannot do web preview. That means that you cannot go through the code or web. So you have to download it and then you can do it. And since web preview is not available you cannot get it. It is also not available. Get it is a tool through which Android AOSP maintains its patches. So if you are planning to contribute something. If you have a feature or a patch or a bug fix in mind. So what you have to do is you have to set up this get it at your local machine. And then you have to push it to direct channels. And how it essentially works is how it works is that you specify the number of reviewers you want to approve. One reviewer or two reviewer won't tell you this. I'm not going into that much detail because of them. The last thing is manifest file. Of all the application developers here AOSP or Android project manifest file is different from application manifest file. Application manifest file is something that you specify. You have resources, permissions and other things. In this AOSP manifest file we specify the location of projects from where I'm going to download. I'm going to specify the branch from where I'm going to check out or the commit ID which I'm going to check out. I can just show you how it looks like. You can see this is the get location. Let's take a project. This is revision means your branch or it could be your commit ID. So this is a typical line. It says that the project is going to be Dawek. This is the project name. It's going to check out the revision 235. This is it. Revision is something which is either a branch name or it could be a commit ID. So we'll move on to next slide. How to download the code? How to actually use repo tool? This is the list of command to actually download the code. You will see that this repo init is something where you specify your project manager or your main host server where your projects are listed. B is for which branch you want to check out. It could be a possibility that you started with 235. Now then you move to 237 and now with ICS you have moved to 4.0. You have maintained your code as a separate branch. You can check out 235. So you specify hyphen b your branch name. Hyphen m is manifest file as I've shown you earlier. It will tell you what projects to check out and what commit IDs to check out. This first command rubbo init doesn't download. It just initializes your download. It will check for the existence of this project if it is there or not. It will ask for your name, email address and anything else. And this repo sync is the command which actually will start download. In this example I am checking out ICS code, Ice Cream Sandwich code from Enright's official channel. Now the code structure. How it looks like is, once you have downloaded the code, this is how the directory structure looks like. You will find a couple of these, a few of these directories. Bionic, bootable, build. The cscope.out and tags is not a part of your speed. This is something to do with me having these files. So in this section I will be briefly covering what all these directories are there for. First we will start with Bionic. Bionic is Android's C library. It is different from a GCC library. They have their own modifications. Essentially they wanted to move out of GCC because of licensing things. Plus a couple of features which they have added. Second directory is bootable. This is a legacy directory. No one uses it anymore. People use it only for reference. Only for reference because it contains fast boot code which has to go in your boot order if you are planning to have fast boot. So this is only for reference. Third directory build is an important directory. This is the directory which comes into picture when you actually do a build. So when you do a make and specify your target platform, then how your Android build takes those parameters. This is how the whole thing is configured in this directory. I will be covering this directory later. CTS is Android's competitive test suite. There is something which has nothing to do with booting. But it is important if you are planning to have Android market in your device. This is a test suite which you have to pass if you are planning to have your device certified. That you can say, OK, how it goes is that you say, my device is 99% CTS competitive or 100% CTS competitive. Then you go to Google and you say, OK, my device is Android competitive. I need an Android stamp on it. That OK, OK. It is capable of running Android market and other competitive things. Licensing things actually. Now it contains a virtual machine code, development container, test cases, mainly tutorials, multi-code. Device is again an important directory from a booting point of view. Because all the vendor specific, all the target specific directories, all the target specific files will go into device. External is, external directory is again an important directory. External directory holds all the projects which are directly or indirectly or not at all developed by Google. So you will find the Bluetooth, the WPS applicant, SCIA, everything which is not directly related to Google in this directory. Framework is your base, your Android core application framework, your service managers, your, all commitments, all the services which you learn is essentially a part of this framework directory. Hardware is your hardware specific, you will find all the hardware specific libraries modules here. Kernel is Linux kernel, Libcore contains Apache Harmony code which is kind of a complement code to Senjava. NDK is the key development kit, packages, AOSP stock applications which comes as a part of AOSP. Pribil contains of Pribil binaries, mainly two chains. SDKs, Android software development kit, you are most likely aware of this, what SDK is. System is something very important, some system contains your Android core system libraries or binaries. And Android system puts up it, what initially few binaries which run, which we run or which Android runs is a part of system library. So this is something which may be of interest for you. I wanted to check, I wanted to have a quick look into Android kernel because if you find all these development boards are any other board or any board if you get a hands on, they release only a stock kernel, they release Linux kernel, they don't release Android kernel. For example if your device is on 2638 kernel, but upstream your device can support 3.1 kernel. Now 3.1 kernel is a vanilla kernel, it doesn't have your Android patches. So what is the process to get those Android patches, put it in your latest kernel and then just run it. So how it works is, this is that history I'm talking about, Android or Google, it maintains an Android commentary. This commentary is hosted by Google in their GitHub repository. So what they do is, they put all their Android patches on top of Linux's base tree. For example if this Android comment is on 3.1, so what it essentially means is that he has taken Linux's 3.1 kernel and then applied its 470 patches on top of it and it has released it as a commentary. So once this is done, all you have to do is just extract the patches. If you are not aware of how to do it, there are a couple of git commands through which you can specify that okay, give me your patches starting from this commit ID and that commit ID is going to be Linux's commit ID. So it will extract all the patches on top of that patch and it will give you a list. Then you have to apply all those patches on your devices kernel. I'll quickly go through the Android kernel features. Binder is Android's IPC mechanism, it is mainly used for IPC mechanism. So how the services talk to each other, how the transaction flows. Azure memory is an anonymous shared memory also, sometimes known as Android shared memory. When we have logger, logger is an important thing because it is the driver which maintains your system logs. And now when I'm talking about system log, I'm essentially talking about 4 types of logs. Android driver, this logger driver maintains 4 buffers. One buffer is for your system logs, another buffer is for your radio logs, one is for your event logs, and one is you must finish your kernel logs. There's something which is very handy when I'm going to cover the debugging session because that is where you've done those logs. That is where you specify okay, I want to see my radio is not working fine, I want to see what is going wrong there. So instead of just dumping all the 4 buffers, you can specifically dump logger, you'll just dump radio logs. Wake logs is some, it's an invite feature which prevents the system to end up suspending or low power sales. How it works is that from your application or from your native service, you request for a wake log, and once you have a wake log acquired, that means that system is not going to sleep and it's not going to sleep. So you can do whatever you want to do and then you have to just release it. Once you have released the wake log, you can go to system log. Out of memory handler, this is something which application developers are getting very, very well aware of what it does, that if it finds your system is going out of memory. So it starts scaling process based on their priority level. Now this priority is something which you set in your init.rc file. I'll be covering what that init.rc file is. Aram is Android's Aram timer. Ram console is again something which is helpful in debugging. Paranoid network is Android's term where, you know, you can only lay around your network settings if you have a particular user ID or a group ID, namely which is a root ID. Okay, so here we are. As I told you, hardware abstraction layers are that part of code which sits in between your framework and kernel. So your framework can talk to your hardware abstraction layer and then it can talk to your kernel and your hardware. Now here what I have covered is I have covered that part of code where your hardware abstraction layer is hooked to your Android framework. So how it works is that you can see the star hardware interface. Now what does the star hardware interface means is that your interfaces, your C++ class has exposed interface class which could be camera hardware interface. It could be audio hardware interface. So once you have this hardware interface implemented, you have to implement your hardware abstraction layer and then your application framework will call this hardware get module or this DL open dynamic linking. So how it works is in that hardware get module is specified that my module name is this. If you see the usage of this function, it requires a tag and then some other parameters. So based on that tag, it will load the module, it will search for your hardware abstraction layer in the runtime space. Second thing is how hardware abstraction layers are linked to framework is one thing is this runtime binding where you just open the directory or you use hardware get module function or you use dynamic linking. Second option is to do a build time linking. At build time you specify I am linking to this module so at runtime it will load these modules. Third is the standard direct C++ or slash def node entries where you just open the C++ entries right into it and then let the driver take care of everything. So in this case there will not be any specific library in between. Your framework can directly talk to your driver. This is what happens in case of Wi-Fi. If you guys are well done with Wi-Fi or something like this, there is no firmware in between. Now firmware is there, there is no hardware abstraction layer in between. So what it does is it just writes to some sentence C++ entries and it just let the driver take care of everything. Firmware here are different from hardware abstraction layers. I just use firmware but don't get confused. Firmwares are not hardware abstraction layers. Okay, so I will be covering and I build process. These are the generic commands where you just run and you expect them to work straight away. First of all, set up your build environment if you okay. With this... This should... So this is the build entry I was talking about. What it consists of is... This is the top layer of main client. It does nothing. It can do anything. It is just a make file. So it can configure your targets here. By default, there are no targets defined here. It will just include build code, main.mk. Which is... Here you will find different targets defined. I'm assuming that people are aware of make files. So what are targets and how make file works. So this drive, if you see... Drive is a default target. If you are not specifying any specific target, it's going to assume drive. Okay, I'm going to build drive. What drive means is that it's going to build your system images, your user data images, but not kernel. Because kernel is not part of drive. Okay, so... This is something that she can check it out later. This is the one which we run... This is the script which initializes your build. So if you see, it exports certain binaries, like mm, mm, mm. It exports your target products. It exports your configurations which is present here. Build code, config.mk. See, this file contains your build configurations, which are the default build configurations. Okay, so this is it. Mostly, they are specified the 2-chain path. What is that default 2-chain you want to use? For example, you don't want to go with this 2-chain. We have our own 2-chain. This is what we do in our app. We are always on top of the latest GCC 2-chain. We use GCC 2-chain to build. So we just modify this path. We specify, okay, we are going to use 4.6 2-chain. Now, after running the first command, it will export certain variables. This is lunch. What lunch does is lunch helps you choose what target product you want to build for. Tablet product is something which you specify for your product. I'll be coming to this later. Then, while building, you can use Ccache. This is mainly used to cache object files because ASP building is a huge process. On normal machine, it takes around 4 to 6 hours. If you are sharing that machine with someone else, and if you are using this variable, that means those object files are already cached. So for the next person who is going to do a build, it's not going to take that much time because it has already cached certain object files. But the limitation here is that it only caches C and C++ object files. So all the dev files is something which you have to build again later. Then you have got MakeCommand, which will just start your build. MM or MM commands are mainly make commands, but they are mainly used to build independent projects. Because Android has only one top-level make file. It doesn't have separate make files for independent projects. Independent projects come with a make file called android.mk, which is not a standard make file, it is android's make file. So you can find the androidization there. So you use these commands, MM, when you specify target product. So these M or MM, they know what does, I mean, what android.mk is. I have a question here. Yeah? You see, without use make, I couldn't do an extra specific way. I know that in one of the forums that the extra view can be the number of threads single code. Yes. Single code. So you can give make minus a 2. Sometimes they say it's two threads and single code, possibly minus a 4. And here we have written plus 1. Yes. So it's all a little confusing. See, ideally you should not give plus 4 for a single code. Okay, yes. Then you can do, yes. You can give up to minus 8. You can give whatever you want to do, but it's not going to use it. So there's a limit, there's a limit on the number of threads it can spawn. So basically, if I give the number of threads, it should be good enough. Number of threads plus 1. This is what people recommend. Would you know why it has plus 1? No idea. Yes. But you know, instead of giving just any number, what people recommend is just give number of threads to your CPU server plus 1. I need one more question. Yes. This is going to be the standard architecture. Okay. You mentioned about the explainer for the standard in the CE or normal language, but it's not standard. Suppose I want to have new service or new applications there. Okay. What I'm supposed to do is combine the common machine if you're planning to do it as a service. Yeah. Right? So it has to go in framework. Yeah, but I think of the standard inside or if you take the next one. You have to make the entry in the next one of the entry file for building handle. Okay. So if you take the next one. No, you have to make the entry in your port configuration file. There's a HTML called product underscore packages. Okay. So in your device configuration files, you specify that apart from the default packages I want to build these many packages. Okay. Okay. So I will talk about this thing in the next session. Right? So how to add your own project. But as far as the service thing is goes, service or specific part is a, you know, Java jrx part. So it should go to framework. It should not be in standard. I mean it should not be. So it is a configuration files. It will go main contract product that mk product that is called mk. These are just for reference if you want to be to, you know, show it. I am already showing to you. Okay. So I will just go through my slides. Somebody here is that you have to export these three variables product device, product and target device. Now these variables are something which you have to define in your both configuration files and direct them to both configuration files because both are something which is very important. But these are the ones. First thing, because the first line you say that the build time configuration files are invite products both config and invite both dot mk. And write dot product, products dot mk is the file which you specify all your board specific files. So for example I am really talking about going to Google under both dot mk. Can you specify my product device and other things. Now comes your board configuration file. Okay. So this is going to specify your build options specific to your target. For example, for a new device, if I have a new device, what I do is I will build it with all the stuffs. I will try to make sure that you know the basic, the core of invite comes up. Audio is not working. I am not worried about. Camera is not working. I will just use stuffs. So what I do is instead of using these also audio and stuffs I will use this. Board uses general audio. Similarly I will use board has a camera stuff. So this is something which you can can, these are build time configurations for your target. Which you can specify there. After these build configuration files there are 10 configuration files like init.rc and other things. init.rc is just a script. It's like an android own small scripting language where it specifies certain triggers. Triggers are like early boot. What should android do in early boot phases? What should it do after it boots up? What should it do in the initialization phase? So this is what I am talking about. On init, on boot. These are not triggers. So what it does is these are just commands. Change the ownership, change the permissions. And the end is the fun part. This is where android initialization starts. So this is it. We specify the number of services which we want to run. So services this, service that, service this. We can see WBS a pick and native demo and everything else. So that is our init.rc. Similarly you have certain runtime configuration files. This is the optional product.mg. Packages package which I am talking about. If you are planning to add no extra package then this is where we have to add it. Now the android boot process I will just go through it quickly. Android kernel will start the init process. It will go through the init.rc script and then it will start all the services and all the commands which I will stick there. It will start zygote. Zygote is your first process. Not the first process but the process which will initialize your line and spawn other processes. Then it will go all the services I have mentioned in the init.rc. Zygote will start the system server. System server will start all the services. Now all the services I don't have time to show you the code but it is in framework based services, Java and system server.java. So you will find that there it is starting all these services. Once these services are out essentially your system is out. Now how other applications get spawned? Applications are spawned by Zygote Dalvik which is larger. Android application talks to other services. Now how these services talk to each other is that the service manager I have mentioned specifically because the service manager is the context manager. Context manager means it is the one who is going to do the IPC who is going to initiate the IPC. So you know we talk to service manager service manager to talk to binary. You know it will reply back and it will talk to your application. So I am going to be talking about troubleshooting. These are commonly used tools. Most important thing is to better logs as much as possible. So in init.rc I have shown you that there is something called log level which you can increase. So more you increase the log level more dumps you will get. DMSS is your kernel log, log cat and dumps your system logs. Four types of logs. It is almost empty. KDP DMS you might be in love with it. This is an interesting thing. The last KDP DMS is what it does is it stores your last KDP message in this file. So which you can retrieve in the next boot. TraceView is something a lot to do with Android applications. And for help you have all these Android communities you have ILC channels Robots forums where you can ask a question and you will get back to you. So any questions? We can take one question here. Any other questions? Basically I am trying to get TraceView in the next one. I don't know if it will come in stock. I just want to know. For example, I have got an EPK file. I have another EPK shell open. It will be in the same emulator. And I do a log cat. Can I see what is happening in terms of that app thing? Yes you can. But I couldn't. So I don't know what is the problem of an EPK file. No, because I have checked things like this with logs. You will get complaints like just download it to your system and restarting the EPK. So this kind of work is something that I have seen. Okay, but I have not done anything to increase the log level. It should come either ways. It should come either ways. Because log levels are mainly for in-it level log levels. And for if you are doing a log cat and if you are using any level which is about debug level then it should come. I mean debug or warnings, alerts, they should come. So it depends on your EPK or your application. By starting how many messages it is happening. If it is not happening anything you will not get anything.