 So, I am going to talk about the Android SDK add-ons, so how many of you are app developers, I hope many, and how many of you are a system developers who really work on the Android source code? Oh, few. Fine. So, let's begin. Myself Satish Patel and I work for the Linaro, currently I am working for the Google Sara project, it's a modular phone, I am not sure have you heard of that, how many of you have heard of the modular phone? Yeah, fine. So, I am working for the Android customization for the modular phone and as a part of that I got a chance to dig into this topic in bit details. Okay, so we will talk about what is SDK add-ons, why we use the SDK add-ons, why OEM vendors use the SDK add-ons, what is the pros and cons, how the application developer can use the SDK add-ons that is released by the OEM vendors and how the platform developer should create the SDK add-ons and make it available to the application developers. And I have one example, if time permits I will show you. Okay, so before going to Y part, I mean what is the SDK add-on and why we should use the SDK add-ons, how do you use, I mean have you written the apps which is OEM specific or which use the OEM features, anybody, yeah, so how do you use that? You take the entire SDK from the OEM vendors or you just take some libraries from the OEM vendors, how do you do that? What is the general traditional scenario that you have followed till now? That means you are giving the full SDK, okay, fine, so generally I think if you would have some of you have written the application for the Google Glass or STC Sense UI or some of the device from the Sony and the Samsung, so they have the different terminal, they have the different distribution mechanism by which they make these features available to the application developers. So how they connect? So we have the various distribution mechanism, one is you just modify the endosource code, build the full SDK and give it to the endo developer. That is a non-traditional, I mean it's like when you open the endo studio you need to install the, you need to download the full SDK from the OEM vendors, install it in the endo studio and then start working on the endo devs. Another way is you just distribute the OEM specific changes, that's the leaves, whatever you are saying and the distribution format should be such like that, okay, fine, you go to endo studio, open the SDK manager and just say, okay, fine, I want the changes from this OEM vendor and it should automatically install all the lips and the documentation for you. So you should not manually copy all the stuff from the OEM, it just mentions one URL and everything should be working out of box and that is called as SDK add-ons. So the first approach, what is uneasy about that? So mainly is SDK size, it's normally more than 300 MB, when it goes to the SDK add-ons and if you are not including the emulator and the system image, it might be few kb. So I forgot to put a sticker over there. So it depends on how much you want to expose to the application developer. So sometimes it, I mean at least whatever we have done it's only 80 kb for the application developer. So it's easy for them, it just pays the URL and it's ready to go. The challenging stuff for the, when you use the full SDK from the OEM vendor is how do you hide the magic, how do you hide the code that the OEM vendor writes for the application developers. So SDK add-ons has that facility that you can hide the implementation details over there and that's why we use the SDK add-ons. So the size is less, it's easy of distributions, we can maintain the version, we can host them on any HTTP server or we can even ask Google to add the XML stuff for us so it can work out of box with the SDK manager. And yeah, it has a very nice support in the SDK manager and the Ender Studio. So that's how all this has been connected with the Ender SDK and the add-ons. I think this has been followed after, I mean since I was concerned with it. So it's consistent after that. Okay, let's took a little deep dive in what is the SDK add-on. So it consists of two things, one is distribution and one is actual package. So distribution is nothing but it's just the XML file which describes what is there in the package or which API version that you should use it for the application development and what are the libraries and the documentation and the water license and terms and all this stuff. And the package is actual libraries, Java docs, system image, if it's there, otherwise it's optional. Stubs, I'll go into a little more depth in a little of, yeah, okay, fine, slide. So what is stub? So stub is nothing but, okay, fine, it's just a wrapper APIs for the application developer. So when they install the SDK add-ons and they really want to dig into JAR file, they will not see anything. They'll just say, okay, fine, there is a function foo underscore variable one and it's just say return null or it will return some garbage value. And this is what available to the application developer, there is no magic over there. So they just download the SDK add-on, they write the application for that and when they run that application on the actual target and actual OEM specific device, then the actual call links to the library which are inside on the target. So it's dynamic linking and the OEM logic will be over here. In fact, the SDK add-ons has the specific feature that you can say, okay, I have a 10 APIs, I just wanted to open the five APIs to the application developer and other APIs I don't want to expose to application developer, they should not know even this API exists or not. So it's a build time option, so I'll show you that how to configure that, okay. So the SkyView is the OEM or the platform or the system developer, whatever. They write the code, they produce the library which they wanted to expose to the application developer saying that, okay, fine, you use this library and you can have access to the OEM specific features. Then we need a distribution cycle where we generate the nice distribution package and we host in the some of the HTTP server and give link to the application developer to use the same. And the final application developer. So I'll go through right to left as we have many application developer over here and I thought of that, so my slides are in that sequence itself. Fine, so how to use that one? So let me show you the quick stuff. So you just open your Android Studio, open the SDK manager, by the way, I'm a not a app guy, so I have written very simple, oh, it's not my fault. So you just, we have to just open the SDK manager and if the URL is already added by the Google main XML file, you can, it will be visible over here. Or else you can actually add, go to manage add-on sites and then say user defined sites and just say new and specify the XML that is provided by the OEM. So it can be, let's say for HTC developer.com and they will say, okay, fine. You put this URL and then everything will be up for you. So once we put this URL, then probably we can see, let's say for here, I would say it's visible for the RR development kit. So it's already installed. I can do one install and I can show you, okay, fine, how it gets installed. But once you click on the URL, this will be visible and then you just say, okay, fine, accept some license and it will install for you. It will fetch from the net and it will install from, and it's ready to use. So when you go to the actual, so it gets copied in the SDK folder. So when you go to the Android SDK, you will see the special section called add-ons. And that's how it gets copied. So if you see the contents, it has the docs, it has the library, it has the manifest files, everything. Docs are nothing but okay, fine, how to use the SDK add-ons. So that has to be created by the platform developers. Okay, so this is just a snapshot that I put in the presentations for the reference. So this is the license term that we need to accept and license can be OEM specific. Okay, how to use this OEM specific features? So you must have used the use feature tag in the Android. So OEM can say, okay, fine, they have to include these things. And this is used when you download your app and it just check, okay, fine. This hardware is present in your phone or not. If it's not present, it will say, okay, fine. This app is not compatible with this device. And that's where we use this functionality. So we have implemented the I2C and the GPIO APIs, which expose all the hardware I2C and GPIO to the end users. So that's why we have introduced a new feature called, okay, fine. If it has a I2C API support, it's ready to go. And then we need to also include something called users library. I have not mentioned over here, but it's there in the actual code. Users library and then you need to mention, okay, which library that you want to use as a part. What games as a part of SDK add-ons and what is there in the documentation by the OEM vendor. For example, in this such case, okay, fine. So yeah, so I'm using the two libraries. One is GPIO and I2C, then it will expose all the functionality for me. So I can say, okay, fine, it's I2C manager. I can get the instance and then I can use, I can open the device. I can set the slave address, whatever, fine. So it's good to go for the application developer, refer the API documentations, implement the app, and get ready to run on the actual device. Any questions for the application developers? So the next section is for the mainly for the system developer. So you might get bored, but yeah, any questions still now for the application developers, how to use the SDK add-ons and fine. I think you might have more patients when you use actual, when you build the actual application for the ARA phone, it's all modular. So you might have to develop the application for the different kinds of models, the tons of models are coming on. System developer, so how do you create the SDK add-ons? So when you are building any specific device, the first condition is you have to compatible with the Android CDD. It's a compliant document by the, and Google. So you say, if you want to call this device as an Android device, these are the definition and you have to comply with that. So the first rule is you cannot touch any existing platform specific APIs. So whatever feature that you want to implement, implement separately, but you cannot, by definition, you cannot change any of the existing API signatures. You can introduce new system service. You can introduce new background service, native codes, whatever, but you cannot touch the platform stuff. So always it is recommended to create a new service under device, whatever OEM name and the, the simple mental libraries over there. Okay, so once we have the source code which can access to OEM specific feature, let's say GPU or let's say high square C or the GPI or let's say custom hardware. You write a library which can talk to your stuff and then you have the APIs which is available for the application developer. And you need to, you need a special make file text in order to build as SDK add-ons. And then there is, there is a packaging mechanism for that. So let's go one by one. So make file, I think it's, it's, it's common across the Android source code. Just a simple make file that where you mentioned that this is Java library and I'm, I'm building as a Java library. This is the permission. So this is where you define, okay, fine. This API use the, the feature called high square C. So if Android manifest.xml, if application developers say, okay, I'm using the high square C. And if this xml file is not present in your target device, then by definition, it will not allow to install your app on that device. And this is the magic it happens on the, the Android source code level. You can hack it around if you want. Then documentations, make sure that your code has the proper Java documentations. If it has, then just put this line of stuff in your android.mkfile. It will generate the, the order for you. So no need to do our separate documentation for the SDG add-ons. So this is all about the, the, the Android.mkfile that you need to define when you generate the library for the application developer. Now the second part is how do you package and how, how do you distribute as a part of your target system image, which are, which you are going to flash on your device and the host library, which are, which you are going to distribute as a part of your SDG add-on distribution stuff. So there are a couple of, so these are the Android specific source code. So if, if you have any time clone the full Android source code, you might know this direct trace. So there are something called device directory and in device, there is a OEM directory and then you do all the OEM specific stuff, what you want in the, in the Android build, what OEM features that you want in the OEM build that you put it over here. So first one is SDG add-on.mkfile where you define the packaging information, what you want as a part of SDG add-ons. Second one is tub. It's, it's, it defines what you want to expose to application developer. The manifest is nothing but the version of the SDG add-on and the source properties mainly for the license and the API level that it has to comply when you, it depends. So it says, okay, my target has the minimum API level 23. So if, when you distribute the SDG add-on, you say, okay, fine, you should be having the minimum level, API level 23. You can work with the above, but you should be having the minimum level API 23 and then code is ready to go on the device. Oh, it's a long make file, but yeah, we need to, so these are the non-traditional, you cannot find this in a traditional device.mkfile. So this is specially for the SDG add-ons. So you need to use product underscore SDG underscore add-on underscore copy files for copying the files, then the copy modules where the module gets built. The stuff definition that, okay, fine, I want the stuff definition as well. So you define everything, what you want in your SDG add-on package. And finally you define the product name and the brand. So when then somebody installed the SDG add-on, this will be visible, okay, fine. This SDG is from this particular product ID and the vendor ID. Stubbs. So as I told you, so stub is, here I just mentioned, okay, fine, plus one something dot, taste dot, try to square C. It should be visible to the application developer. And if I just define by minus, and I just define the package name. So all the internal star will not be visible to the application developer. I mean, there is no API, even though they dig into the jar file, they won't find it. So build will just, it's a nice feature by the Android build. So they will just extract out all the minus stuff and prepare the mini library for the application developer. And the manifest file, it just defines the vendor ID, vendor ID, product ID, API level, and what are the libraries are there. So these are the stuff that we are putting over here. So if you observe, okay, fine, we are copying the source dot properties, manifest all these files. We tell build system, okay, fine, I want to copy this file as a part of my SDG add-ons. It makes sense when somebody installed the SDG add-ons in the Android studio, this file get passed and then you will see the beautiful dialogue saying that, okay, fine, this SDG is from this vendor. This is the license. So license is defined in the source dot properties. So there is something called PKG.license ref, sorry, PKG.license. You put the entire license header over here and it will be visible when you install the SDG add-ons. Okay. Finally, you just put your MK file should be part of as a regular build. So there is something called android product dot MK. Just reference over there. So it will go as a part of regular build. And this is a final build command to generate the SDG add-ons. So when we run this command, it will generate everything with regard to the SDG add-ons in the out host SDG add-ons directory. So it will have the emulator image. It will have the zip folder which has the Java document and the libraries plus XML file. The next part is packaging. How do you, sorry, packaging and the distribution. So how do you package? So this is the XML file that we need to write it. So there is a tool to generate this XML file, but we need to manually edit. We need to manually edit the size of the package that we are going to distribute and the URL of the zip file where it contains the libraries and the Java docs. So initially I told you, right? There is a distribution stuff and there is a actual package stuff. So distribution is nothing but the add-on.xml and these are the package information. So you can say, okay, find my SDK contains this many libraries and all sort of stuff. So to fill the few of steps in the add-on.xml, these are the few tricks. This is how you can generate the checksum and the actual size and you fill the data over here, size and the checksums and whatever. And then finally you can validate your XML schema using one of the schemas present in the actual rebuild folder. So you can just run this command XML link. It will show you, okay, fine. Your XML is fit to go and fit to host in the HTTP server. And you can give this XML to any of your application developer community to use your features. Oh, so fast, fine. So I can walk you through that. I think we have a time, right? Cool, fine. Let me show you, okay. Let me uninstall this stuff first. So we can go step by step. So I'm just deleting this package. And I'm also deleting this link. Fine. So now nothing is visible. And if I build my code, obviously it will show the tons of error that you don't have the light libraries for you. Fine. So now the next step is let's install SDK add-ons. I just wanted to show you how it looks like when you install. So you can give the local path or... Oh, so this is how the XML looks like. So it has the headers and license headers, and it has all the sort of stuff. But we don't need to worry about those things. You have to just paste the link over here. Close. Yeah, we got something where just say install package. So it will pop up saying that all the vendor and the product information is on top of that. This is the Android SDK license, and this is what the RR Development Kit whatsoever. And you have to accept the license, install it. Yeah, that's done. So it will unzip the full package, whatever we have hosted on the HTTP server. And it will manually pass the manifest and it will find out, okay, what are the libraries and what are the documentation. And then it's ready to use. So documentations, as I mentioned that you can go to the SDK add-ons libraries, there's a docs. And for every library, there's a doc. So it will pretty much looks like this. If it's a Java doc, it depends what are the comments that we are putting in the code, but it's a Java docs, it looks like this. You can even access this from the Android Studio. Okay, fine. And when you build against these things, you need to do the open model settings, and then somewhere here. So you just need to mention, okay, fine, I need to compile against whatever install, new install SDK package. And then your app is ready to go. So I have the little board over here. It's called as 96 boards. It's a 64-bit quad core. And then I'm using this board as just a prototyping, the new features, callyscracy and the GPIO in the Android software stack. So I have the target library on this more than, oh, it's no USB device phone. Let me check. It's booting now, so it should be available. My bed are not connected to the cable. Okay, so how many of you really knows iscracy and GPIO hardware stuff? So it might be a little annoying for you, but it's just a hardware. I mean, most of the sensors, I would say it's more than 50% of sensors, typical sensors, temperature and the ambient lights and the proximity. They are based on the iscracy protocol. So all the hardware is on the iscracy and the GPIO protocols. So apparently the visor is not running. There's some issues. I'm not sure. I don't know why it's not running. So what I did is I just hacked the code this morning and I'm just doing everything over here. I'm just opening the iscracy device. I'm setting the slave address and then I'm just reading the value over here. So slave address is nothing but the 30 and I'm reading the value of 3A registers. This is nothing but identification registers on one of the power ICs which are based on the iscracy on this device. So before I do anything, this is the command shell for this device. And I'll just run the few command line operation just to show you, okay, fine. This is the slave address and this is the registers that we are going to read. So 32 is nothing but the slave address and the 30A is nothing but the register that we are reading. It should be FC. So let's do from the application now. So I have the... Oh, it's already read. So let me rerun. I'll just create the lock at minus C. Let me run the stuff. Sorry guys, I have... Even though I'm not a good developer guy, I have written a small app which has a nice feature. Not nice feature, but at least you can set the slave address. You can pass some register value. It will read for you and all this thing, but the visor is not running. So I just hacked it for a moment and whatever, it's not running. So I'm not quite familiar with the Android studio. I have to test my SD card and then I'll start running on this thing. I don't know what happened. Any idea? What is going on? Okay, so I think it's failing to connect to the device. It's there. It says device is offline. I'm not sure. It's installed or not. Let's check the logs. Lock at minus C. Fine. So 252 is nothing but the fc, 0x fc. So it returned the correct value. So we can eventually set any I2C registers and we can get the values. So that's it about the SD cardons, but it is in a way, it's a nice feature that we have to just put whatever OM specific logic in the separate library and get it distributed to the application developer to make the use of it. Any questions should not be for the application developer, but if somebody's there from the system developers, they might have. So this will become a now a traditional way for the OM vendors to distribute their SDG. So they might not distribute the full SDG. They might just queue the SDG add-ons and you can go through it unless they have the features which are not platform dependent. Fine. Thank you very much. Thank you. You got a question. Can we do something similar like this with third-party libraries? Third-party library and just distribute as the way we are distributing as you get. You just create the package out of that. Okay. So how will distribute that third-party library? Okay. So you have a third-party libraries and you define, let's say I want to expose 10 APIs out of third-party libraries. You just write a wrapper for 10 APIs, which will eventually call the third-party libraries. And for this 10 APIs, you generate a separate lib, which will be again hooked separately on the host and the target. On the host side, it will be just a wrapper. On the target side, it will be actual call to your third-party library. So I would say you no need to even distribute your third-party libraries to the application developer. You just distribute the wrapper of the third-party libraries. Let your third-party libraries be on your device for the application developer. It should be just a wrapper. Like I have never used add-ons and all because like my concern is that it will be then very specific for just some... Have you used the Android support libraries? Yeah. It's one of the SDG add-on features. But it works for every phone out there. Yes. So Google is giving all the support libraries as a part of SDG add-ons. So you might not be observing because you are not doing these manual steps. So when you launch the SDG manager, it will give you the list of the API version and the support libraries. You just click on that and you just install it. So if you want a similar way for the VM, you just ask Google, okay, fine. I am the authorised the Android distributor. And this is by the add-on link. You just add it to your main add-ons script. Then when you launch the SDG manager, it will be up here over there. And just click it. It is ready to go. So you might not have followed this step, but it comes when you just launch the SDG manager. Yeah. So whatever comes over here, right? So yeah, it says something called extra. So Android support is nothing but the SDG add-ons. On the market, which use these features other than libraries? There are many apps. There is apps from the Samsung mobile. There is apps from the SDG Sense UI. So initially, SDG Sense has distributed the SDG add-ons. And then now the Google has taken as a regular AOSP source code in the AOSP main tree. And now it says distributed as an Android SDK. Any of you have used the USB accessories? USB accessories? Yeah. So they have initially distributed as a part of SDG add-ons. So in a Honeycomb and the Ice Cream Sandwich. And then eventually it becomes the part of Android SDK. Thank you. Yeah. Yeah. I just noticed previously that for license header and the API level, we have to mention it in a separate file called source.properties. Yeah. As opposed to when you are having a framework package or a system package that you have, you mention it in Android.mk or a device.mk file. Any special reason for creating this file source.properties? So we never define the license. So all the definitions that we put in the Android.mk file and some other place, it's just for the source sake. But when you really distribute, when you package and distribute something, you need to put the external header saying that, okay, fine. This package has this license. And that's why you need to put all the stuff in the separate source.properties. And this is how the SDK manager will take it. So SDK manager will take the add-on.xml file, try to unzip over there and then find, okay, fine. This is a header. I need to show it to the user if they accept and it will go ahead and install. Can you give us a time frame for when the project are will be launched? So I'm not authorized to do that. I can't say. Just a rough time figure. But it should be before the end of this year. Should be. Yeah, I mean 2016 or 2015? No, not 2015. Oh, okay, fine. Probably next year. Okay, thank you. Yeah. I mean, again, I said, I don't know. So I'm not authorized person for that. Okay. But yeah, so many stuff are coming. And you might have access soon to write to develop your own modules or your own hardware and write your own custom apps which can access to your hardware. It's a pretty cool stuff which are coming after the log. Not on this flag. All right. Thank you so much. That's it for today. We hopefully will see you tomorrow. Before that, please do drop your feedback forms outside. There's a box near the registration desk and you can still buy tickets for tonight's dinner, which is at Hakuna Matata.