Okay. Good morning everyone. I'm going to talk about signage mod, how we've taken it from Steve sitting in his bedroom, working at home, to working on devices such as the OnePlus and the U, which was announced yesterday, and how that looks at from a developer standpoint with our community. So, who am I? My name is Abhishek Devkota. I am developer relations at Cyanogen Inc. I also run senior engineering inside of Cyanogen Inc. And on the open source side of Cyanogen Mod, I've been participating for about six years now, so maybe six months after the initial release. You can find me at Twitter or at Google search for Swirl. It's a pretty unique handle at the bottom there. I'm on Google plus, Facebook, everything as well. So, for a show of hands real quick, how many of you actually know what Cyanogen and Cyanogen Mod is? Good. Perfect. That makes this part easy. Instead of me doing a little spiel, I figured I'd do a little cool one here. This is actually an excerpt from a Cory Dr. Rowe book called Homeland. He's an author, a blogger, an activist. He does a lot of things about proponent for open source code. And so this is what he had to say in actually one of his books. I knew about Cyanogen, of course. Hackers had taken the open source Google code and made it fully free and open version that can do all kinds of tricks. So, at a base level, that's very true. We take the Android open source project. We make it work on platforms outside of the Nexus devices. So, AOSP out of its box supports about six or seven devices today. We have on KitKat 163 as of yesterday morning, supporting KitKat with Cyanogen. We are also a public entity, so you can find us on cyanjama.com. And we also have a lot of privacy features as well, which we'll jump into a little bit later. Another interesting note about Cory is all of his work is also open underneath the Creative Commons non-commercial license, so he open sources his books, which is actually a pretty neat thing. So, from a hobby to a movement. We've been doing this about six years. Android came out in early 2008 with the G1 picking up traction towards the end of the year. Steve was our founder, started on the G1. He actually built on top of the existing XDA development system created by a hacker named Jesus Freak, who now works at Google. He is responsible for the Dalvik and Art project, if you're familiar with art with lollipops. So, the folks and names in this deck are a good core part of what Android has become over the past six years. And then we've done significant first with our open source code. Xiaomi was able to launch about five years ago. They use our code base for that. The Ubuntu Touch project is also using cyanogen mod code initially for their kernel sources. Because we do a lot of the legwork that they wouldn't have to do for porting Android to other devices and using a third party OS. About two years ago today, we launched Cyanogen Inc, which was a corporate entity. One to support the growth of Cyanogen Mod and take on bigger projects, which we'll touch on a little bit later. But also to take on product retail in terms of software engineering. So, we have partnerships with OnePlus and now with MicroMax with the U platform that Rahul Silgritiusly spoke about yesterday. So, the fun stuff.  We had no idea what we were doing. I was a student at the time, participating in college. Probably similar to a lot of you trying to figure out what I was doing with my life. We didn't have a plan. There was no road map. There was no vision. It was just, here's Android. Something new. It's something cool. It's Linux based. Let's see what we can do with it. Which was fantastic because it allowed for a lot of innovation to go really, really quickly. If any of you remember Android and Infancy, it was missing a lot of things that we take for granted these days. There was no store. There was no multi-touch. The behaviors and experiences were very just rudimentary. And so, there was a lot of gaps that a lot of companies identified. And we saw those same gaps through the open source code. And we just started plugging them with our own innovative and novel features to go with it. This had a trade-off, though. While it was great for hackers, and it was fantastic for incorporating new functionality, what ended up happening was we had settings upon settings upon settings upon settings. And if there was a feature idea, we didn't have the wherewithal or the really just confidence to say, no, that's not a good feature or no, that doesn't make sense. We just said, okay, you can have it. We'll merge it in and we'll make it a setting somewhere. So, if you look at the early days of Science and Mod, I dare you to find something within 30 seconds if you know what you're looking for. I get lost within those versions as well. As we continue to grow, myself, Steve, maybe five other people started, for lack of a better word, developer interests. We wanted to bring people in, especially with the push that Verizon did around marketing for the initial joy platform inside the US. That was that horrible robotic joy sound. So that brought in a lot of new fresh blood because before that, it was just the G1 and the MyTouch, the Ion phone. So, with that, we started getting a lot of interest from outside sources on actually contributing back to the project. And initially, we were using just GitHub pull requests. And so what ended up happening there was, yes, there was sizable amounts of code coming through, but it wasn't the best interface for code reviews or even code management or discussion. GitHub has a really good comment system, but it's not scaled and in tune for what we were using. So we launched our Garrett instance. Garrett is the tool that Google uses in-house to do their code reviews. It has various API hooks that you can use for continuous integration and Jenkins instances. So it worked out really well for us. And then this was our effort at Coordination. This is a Google Drive folder. This was how we brought in new developers.  It still is. I mean, there's some important pieces there that the CMC, CVE checklist, make sure that we're up to date on every CVE that makes a public round across all the devices. You can imagine doing the kernel patches for 153 devices for CVE can get tedious. But this was our organization, and this is not conducive to a lot of things, especially planning. So with the Garrett instance up, and we started getting a lot of contributions, we were overwhelmed. We didn't know with the five of us that were actually managing Garrett to handle the basis of we have so many more contributors, so many more patches coming through, and we were routinely about 60 days behind on code reviews. And the reasoning for that is, well, code reviews are fine if your peers are doing it for you, but the merges are within the hands of five people. And if those five people don't get through the code review in time and you need to rebase changes, you need to recode review, and then it just becomes this really tedious process. So we settled on what the Apache Software Foundation uses in-house for their own development, which is this concept of a meritocracy. So it's not a democracy. We don't vote. There is no show of hands for how things should be merged or what should be going. We base it on the capabilities of the actual contributor. So if you've been a contributor for three months and your work is consistently good, we'll give you merge rights or code review protocol over a specific project. And so what this does really well is scales for our needs. We bring in about three device maintainers every month, and with them come usually a little team of folks that they've been using for external testing on unofficial builds and XDA contributions and so on. So we can actually scale this so that they are in charge of their own platform and they are in charge of their own projects, and then we can give permissions to merge rights outside of the hands of just myself, Steve, or Coach or the others that you may not be familiar with. And then it's a self-sustaining system. They can just keep their code reviews moving along. They all have a core concept of what we're working towards, and they can go on from there. So, some growing pains that we've seen. The settings upon settings upon settings things really bid us with CM7. CM7 was the Gingerbread release to Cyanogen Mod, and it was a messy release. If you used it on one of your devices, it's probably the most still in use wide scale, because Gingerbread just won't die for the love of it. But it is just feature overload. I think there's about 12 different lock screens that we bundled into the OS, all with settings to go with it. There's a horribly invasive permissions control system that breaks a lot of third-party apps, because at the time we weren't really thinking about a larger ecosystem. We weren't thinking about being conducive and playing nice with that. So, CM9 with the Ice Cream Sandwich and the subsequent skip of Honeycomb, which never existed. We got an opportunity to start over fresh, and so we actually sat down and said, you know, we have this brand new code base, and it looks radically different from a software architecture point, but it also looks radically different from a UI standpoint. And so, why don't we just take what we have and reimagine all of them and reimplement all of them to be as if they were a part of the OS from the beginning. And that was one of the things that CM9 ushered in that CM7 didn't bother with. And so CM9 was very much our start of actually having a vision and a user story to tell beyond just hackers. So this does pose an issue with open-source platforms, particularly not everyone's fond of starting over and not everyone's fond of not having that overkill. And so we saw a lot of rise in external projects, and a particularly example would be AOKP. And so AOKP very much lived within the ethos of CM7, which was more is better. And so they would have a lot more features than we would end up having in CM9, but I feel that they suffered from what we suffered in CM7 and had to learn that same issue as they grew their code base as well, which is maintaining all that code, whether you have 20 or 100 features becomes chaotic when you have multiple contributors who have access to maintain and modify that code. And we are pretty hands-off in terms of management of our open-source contributions because we find that with too much management, you start killing some of the innovation. And so we tried to stay hands-off, and, you know, so the vision change will just made other folks want to do new things, which is fantastic. That's how open-source works, but we did lose some capable folks to that. So, yeah, we had more of an emphasis on our user experience and then as well as the documentation. One of the things with Android is Google does a decent job of documenting their Java docs and so on, but for the purpose of our developer community, it's basically if you wanted to do anything with respect to third-party operating systems, you had to do a Google search and hopefully you got a good guide. And so we put a very conscious effort in terms of our documentation. Our Wiki instance got an overhaul to make sure that it was up to date for everything. So documentation became another one of our core strengths in terms of moving forward. And then things progressed from there. As we had a core vision, we started specking out ideas for larger platform plays, features that would be multiple months' projects to work on. So, Arnav had a talk yesterday on NFC, and one of the things we did was take a bet on host card emulation. And so within Cyanogen Mod, we worked with the folks that simply tapped who were creating a mobile wallet using host card emulation and they innovated that technology, which eventually made its way into Jellybean's release of AOSP. So that bet paid off pretty well. The permissions controls were removed from CM7 and replaced with Privacy Guard, which has since evolved over the years to include what Google's done for their AppOps model, which I imagine they're using for an MDM solution. We started coordinating releases. Releases with CM have always been a fun time for us prior to any coordination. You can imagine with Jellybean, we had about 75 devices within the first month for release, and we actually didn't have a schedule. There was, okay, we've done enough work. It's been maybe two months. Let's do a release now, which was great because you got those features out, but it wasn't great because the code hadn't actually stabilized. We were still pushing code the night before and we just marked it, tagged it, shipped it, and kicked it out the door. And so once we started accumulating users, especially in the millions, that started being a really bad thing. The overwhelming feedback was, no, this is just broken. And so that became another element that we hadn't accounted for, which was people actually depended on this as a daily platform instead of just us tinkering. So with our proper release schedule, which we finally actually hit with CM11, we have a monthly cadence of a snapshot release, which is tagged, tested, and shipped. And so that, if you can imagine, we've been doing this for six years in CM11, it's KitKat and we finally got to it. It's been one of the hardest things that we've had to deal with because when you're coordinating with volunteers around the world and you expect them to sit there and test their own platforms with their own daily lives, it becomes hard. We also introduced Arjira, and Arjira has taken on many faces over the last two years. Arjira is responsible for our bug tracking. We moved off of the Google Code site. But it also does our research for future requests and improvements and enhancements. There's about 1,100 outstanding requests today, not to say that I'm going to go and create 1,100 new features, but this is one of the core things that puts us at the forefront of adoption amongst the enthusiast community is that they may not be technically capable. I'm talking to a room of developers or folks that are studying, but the average user doesn't actually know what it would take to make a system-wide change or anything like that. And so this became a really good voice for integration back, and it became a feedback loop. We would introduce a new nightly with a new feature. We would get immediately feedback saying, wow, that's a really good feature, but I feel like this should work in this way. And it's one of the key benefits that we have as we move towards signage and ink as well is this immediate feedback loop. If I'm testing an application or creating a new application, I can introduce it into a nightly build, and it will instantly be tested crowdsourced by 20 million users. And so that kind of feedback has been immensely helpful for our growth. We introduced the heads-up notification system that's now standard in Lollipop, actually into CM11 about four months ago prior to the preview releases of Lollipop from Google. And so we got a lot of feedback for what we're going to be implementing into CM12, which will be based on Lollipop. On that head start we got with that code and that feedback that's in those feature requests and enhancement requests. But there's still points of failure. We got bit really hard about a year and a half, no, it's probably two and a half now. Our code is meritocracy. Our Garrett is self-sustaining. Our Jira, they have developer access. They can close, start their own workflows. But our server infrastructures, we're all single points of failure, meaning that there is usually one person that owned the website side, one person owned the forum side, and one person owned the build clusters. And so you can see where this can break down very easily. If the person's out of town missing on vacation or in one instance malicious, we're essentially crippled. And so we actually lost total control of our domain for about a month. We switched over to signjima.org for a while there. Over one of these issues. And so that has been a lot of lessons by trial by fire. We want to go into this with open hearts and open minds and say, we're trusting of everyone that wants to come in and be participating and be useful. But we've had to put our guard up for a few more things and put more access controls around the server side of things to make it more robust and similar to the Garrett instance. Another thing is we slow down in terms of our stable releases, right? We have the monthly snapshots. We don't really do stables anymore. And a perception issue has kicked in over the last maybe two to three years, which is because you are now taking more time to focus on quality and user experience, a lot of people think that the innovation side of CM has gone away. I would argue that spending time and the extra time to make sure that the functionality that you're introducing is actually a benefit to the end user is a lot more rewarding than being able to say you have this list of features. One of the most favorite ones that we just recently introduced is if you long click on a notification from a game that says, hey, you should also install this other game for 20% cheaper or like an ad. You don't want to disable notifications from the game per se because you may get push notifications when it's your turn to play or whatever the case may be. So we actually added in a spam filter. Basically, we do a Regex match against the notification by package name.  And so that kind of innovative feature, that one actually came from that same gear list that was coming earlier. There was a external project called Exposed. Maybe some of you have used it. It does a runtime injection of Java code. Really messy. But they had a feature similar to this and somebody said, well, you know, that's actually a pretty good idea. And we said, yeah, that makes sense for a lot of people and it makes sense at a global scale. And so that's the kind of things that we look for when we're taking that feedback loop which is, you know, there's niche and then there's applicable to the crowd. But the most important part about our growth over the last six years has been relationships. Code and technical merit and people, they all boil down to how you can interact with folks. People will give you all kinds of really good stuff because there's a lot of really technical people all over the world, right? There's smart people everywhere and they will give you, you know, the stories behind them, privacy improvements, customizations and focus on the user. They will do what you want them to do and what you want your product to focus on. But if you can't maintain what those features are and you can't maintain that relationship and that open dialogue with your contributors, you're never going to get that kind of traction in an open source platform. It's easy to look at the Linux kernel because it's been established for so long. But one of the early things was that Linus has a pretty rough personality, right? He's a smart guy, but when he sees something wrong, he's very quick to point it out. And that's over the course of the years been called out many times. And now he has a team of folks working with him to maintain the kernel. But molding that relationship to be beneficial to the end product is one of the hardest things that I've had to do as a developer manager here. And so looking at our JIRA instance here, this is actually the JIRA project for CM-12, which is due out in about two months. And so in comparison to that Google Drive folder that I showed you where we were trying to do feature planning, I have now actual reports that I can generate out on how features are going, estimates of timeframes with the signage and ink resources. I can actually give engineers towards some of the harder problems that our open source features are causing or encountering. And so this gives a lot of visibility for a company into the open source project, but it also lets the open source project see that the company is actively supporting and helping and engaging. So that brings us to the company. Signage and ink was about two years ago. And the moment we announced it, the moment you say there's money involved in an open source project, you get that knee-jerk reaction, which is, well, you've just sold out. And I hear it every day and it's been two years and I get this question a lot, is, you know, how does the fact that you have a board of directors and a corporate interest and a corporate mandate affect what you're doing with signage and ink? And when we initially announced we lost about five maintainers to a separate project and they weren't happy with the decision to introduce this new angle. But this is interesting. The knee-jerk is one thing. I can understand that there's been a lot of open source projects over the course of time that have gone dark because corporate interests killed them. But then you have these lights in the darkness. Mozilla, Red Hat. Red Hat does open source first, right? They essentially sell open source as a service. They give you all the code and then they sell you these enterprise solutions on top. Mozilla has been very good with its MPL license for the browser and so you see all these gecko clones of the Firefox browser. So as long as the core interest of the community is maintained, you can actually introduce money and resources to help benefit that. We support our developers with build servers. They're about $9,000 each. Very powerful instances. You can imagine we do 150 builds a night of Android and so if some of you build Android, that's a pretty long build cycle. And so we've also introduced their capability to run one-off builds and so if they're a college kid who can't afford a powerful laptop, they can SSH into these build servers build directly against the server and test their deployments there. Which is one of the many things that we do to encourage that kind of open growth amongst new contributors. And then the same as the meritocracy argument earlier, by announcing a new entity, Sinogen Inc, we had to re-earn the trust of everyone that we've worked with over the last six years. I've called these folks my friends, I've gone to parties and dinners with them, but the money thing always introduces a wrinkle. So one of the first things I did was draft a new government policy basically providing a segregation between what is Sinogen Inc and what is Sinogen Mod, what happens when there's a conflict of interest between the two, how do we handle rights and responsibilities between the two as well. Because you can imagine the corporate side has product interests, they want to make these hardware platforms and some of these things need differentiation for you brand versus any other brand that we work on. But we don't want that to step all over the work of the open source folks either because, you know, one of the appeals of Sinogen Mod is that it's so neutral. It's a blank canvas for a lot of people to do a lot of things. And if we start going too heavily skewed in terms of closed source or apps that are specific to India versus somewhere else, you start breaking that model down. We also continue to focus on our open source and so all of our apps are built on top of the existing open source applications, not secondary closed source. Actually the entire product that's on the U platform that's launching is actually already open source. The only part that we haven't put out is the device and kernel tree. Every other piece of software that's one of the special apps that we've done for them is already up there and available to clone. We also were able to do larger bets on bigger technologies from the last talk, especially with the chat. Whisper Push is the tech secure protocol developed by Moxie, my lens book. He most recently, I believe, they're working with WhatsApp to integrate their end-to-end encryption services. We actually introduced that same encryption service into CM11 just after our public announcement about a year ago. And so this is something that is federated with tech secure and so if you are a CM Whisper Push user or a tech secure user, you're now compatible to that entire network of encrypted messaging. We're evaluating what the new WhatsApp deal does as well because you can imagine that just introduced millions of more people into that exact same network. And so this bet actually paid off pretty well for us in that we've managed to tap into a technology at its forefront just before the encryption scare of the US government and everything else that's going on around the world. And so that's a big win for us there. Another one that we recently announced was Nexbit which is a device-to-device sync and backup solution. So Google has an existing backup solution which will get you your apps back from the Play Store and your cursory information such as Wi-Fi and widget placement on the home screen. And then they also introduce Google Play for games which does game sync across the platform. But what we identified as a gap between what Google had and when we look at a model such as iOS if you lose a phone on an iPhone you plug it back into iTunes and you have a clone. It's exactly the way you left it. Now the community had done something similar using Nandroid inside of Recovery. They were essentially taking system dumps and being able to restore that back. What Nexbit does is actually introduces an API. The API itself is open source. It's inside of our frameworks and security stuff. But Nexbit's protocol allows that device-to-device sync and restore for other apps. So messaging. Games that don't use Play of Games. And settings that normally you wouldn't be able to do as a backup through GCM or cloud existing solution. Hopefully Nexbit takes off really well. We're running a beta trial I believe on their website this month. So if you're interested in participating in that any CM build after three weeks ago, it's already Nexbit capable. So you are eligible if you have a device that participates. We're also investing heavy into SDKs for more CM-specific APIs. So we have the themes engine which has been a very big focus for us for the last year. We rewrote it from the ground up using a part of a solution that was given by Sony to AOSP about five years ago. And then we made it run time instead of build time and then some additional enhancements there. So if you're a designer and you create icon packs or you're interested in the theming side the source is up. There's a theme template available through our Wiki as well. It's a Gradle and Eclipse capable so you can just import it and go from there. We also envision introducing more CM-specific APIs. A gentleman who spoke on yesterday morning, early morning, was talking about app-to-app communication. And I actually agree and disagree with parts of his talk. App-to-app communication is the future but I don't believe it's going to come the way that he thought it would, which would be an example you get an email message through to your standard email client and Foursquare detects that you've finally gotten to where that location was and checks you in. The reason I don't see it working that way is because the information contained in those apps, particularly the metadata, the user information, is essentially what is driving those apps growth. So Facebook is very unlikely to give their information for free to Twitter to do that cross-interaction. So what we envision happening is more so a glue that will sit between all these components and so we're writing an API it's already available on our GitHub instance that essentially will allow multiple apps to publish into one cohesive space and you'll get the cursory information from that app. So say you have a Facebook feed and a Twitter feed it'll be one feed consistent and if you tap through you'll get to Facebook and you'll get to Twitter. We think this is a more viable solution in that when we close it to folks it's not hey, give me your data, it's just hey, here's an API that will allow me to publish your content and it will actually encourage user interaction with your application. Because if it's available, think of BlinkFeed from HCC, if it's available directly on your home screen and I just saw a new picture come through that my friend posted but I'm not tagged that content will still surface and you can get it to it contextually and launch directly into that engagement. We see a lot of growth coming from there and look for more specific things on that coming soon and of course that's open source as well. With the hardware platforms that we're creating there's been an increased focus obviously on quality assurance. When we were just community based we could very easily say well it's a community ROM they chose to install it, it's their fault, beware, user buyer beware. When you're purchasing hardware that's not something that no sales company would say that. Quality insurance has been one of the main focuses for us for the past two years. So we have continuous integration using Lava which is I believe when RO makes the tool and Garrett in our Jenkins instance and so we can actually test every new code change that gets submitted into Garrett directly and deployed. We also have apps on the Play Store which are using this exact system and so we can actually do remote deployment build test, verify and publish which has been a really good win for us. Google gives a fair amount of unit tests within AOSP, a lot of them are broken but there's never been in conscious effort prior to the last two years for CM specific testing. We would just write the feature and that would be what would flush out the bugs. So there's been a very heavy push for unit testing and against the CM specific functionality. There is also the CTS compatibility test suite. This is required to get Google Play certification on any device that's sold. It takes about eight hours to run.  It basically tests every component of core Android. So we are trying to get the CTS compliance against all the hardware devices that we have available. Then when we talk about you and other devices that we're working on, there's regional certifications, regional testing, RF testing, SAR value testing that are specific to the India region versus other markets. This is my third to fourth trip to India in the last two months. We're here often working on this platform. But at the end of the day, the promise is to keep core to the open source nature of the project. So the company is instead of saying, we're going to keep repeating that message over and over again, we'll just continue to show it. The unit testing tools that we've done, the services testing tools that we're developing are also being open sourced because we feel that open source got us where we are. It's opened a lot of opportunities for us as a company. And it also is one of the key components of our innovation factor. And so I've actually I'll tweet this out from the science and mod handle after this talk, but there's a little survey up. We're working on some dialer specific changes and network optimization items for India. And so I'd be curious to get some feedback from that link there. But I'll tweet that out afterwards. All right. So I think we have about 10 minutes for questions. Excuse me.  So where does the money originally come from? So we are funded by two rounds of investing.  These come from actually a lot of open source proponent investor companies. So one of our investors is Redpoint which is actually a benchmark which are actually both supporting Twitter's open source initiatives for their testing tools and Red Hat as well. So they've had a lot of experience taking open source and making it a product that is still open. Hi Abhishek. Hi. This is Ashishya. First of all I'd like to say kudos to your company. I'm a happy cyanogen user. So a couple of questions. Sure. First of all if you could give us any snippets of what we can expect in CM12. So I actually have CM12 running on my device right now. This is the OnePlus. I didn't bring the U model with me. It's a lot from the hotel. So with CM12 you'll see- If you could show it on the screen with the camera. Is this running? Yeah. So I'll do this on the OnePlus. One of the new unique features here is if you get a- Have you ever used Moto X? Ever seen a Moto X? The ambient display. So the ambient display on the Moto X was basically you get a notification and the lock screen would breathe. It would wake the display and just illuminate the pixels on the AMOLED display. It's exactly where it was because that's one of the capabilities of AMOLED. A lot of people tried to recreate ambient display for multiple devices, particularly in the developer community. They wanted that neat functionality. But it didn't work with LED screens because you need to power up the entire LED to get the display to show up. It doesn't work in the same fashion as AMOLED. And so with the OnePlus and the U platform the screen we've actually introduced a feature called Doze Mode, which takes an exact snapshot of the frame buffer of the lock screen itself when the content comes through. And then it breathes that twice at a very, very low power state. And so we've been able to recreate the ambient display using the Doze Mode stuff on the devices. And so that's one of the new ones that you'll be seeing. We announced the video a couple weeks ago for the new themes chooser that we can feel. Which is not actually on this build but that's coming as well. The other one is the quick settings have fundamentally changed versus what they've done in the past three or four years. I'd say they took a cue from us in that previously if you tapped Wi-Fi it would actually take you into the settings instead of killing Wi-Fi. And so there are more quick shortcuts than quick settings. And so we're really imagining how to do this space in particular. Because I think the idea here is really good and they've started well with the dynamic changes of if you touch something it'll take over that bottom row for about a 40-day window. But we think we can do a lot more with actually creating an API where if you are an app developer you can actually generate a quick settings just by being installed. And so you could elevate yourself to this arguably important dashboard. And so that's in motion as well. Was there another question? I wanted to know the story behind the domain trouble. Was it like an internal conflict? He said some malicious thing happened. It was. So I don't mean to disparage anyone's names but there was a gentleman who was a contributor for about four years and his contributions were running the websites. He was the first one to host the downloads for CM3 and he stood up the wiki the way he did a lot for us. He essentially felt underappreciated and this was before the bunny came through this was before there was even a science and ink. It was just the developers got appreciation because they're always creating these new features and they're getting highlighted every week and he was more of a behind the scenes kind of guy and so he thought that he was lacking in appreciation. We eventually caught him making deals using signage and mod to do referrals to the website as well that we don't really condone even we don't even have a donate link on the website anymore if you're donating send it to the EFF for somebody that needs it now. And so he was arguably it was a sense of betrayal that he portrayed on us and so when we asked him to depart and give us control over the domain and he was a single point of failure for the domain he was the only one with the keys, he refused and so we were kind of left in a really hard spot and that made us question a lot of the judgment decisions that we had done in terms of the trust level for that kind of management. Hi. My question is from a very app developer point of view I think on Android I use NDK for a lot of stuff so for developing on signage and mod is it going to be less tedious as compared to Android because J&I interactions for Android system services is a big pain. Yeah, so at this core signage and mod is still Android, right? So everything that you would use to develop on Android will be one-to-one with signage and mod. Right. Some of the additions that we're doing, the SEA changes that we're adding are meant to be plug and play and easy for you as an existing app creator to just add a new permission or new activity and so it should be very lightweight to make modifications. The glue instance the API I was speaking about that works in that same fashion so the permission change so your Android manifest will get one line change and then you would have a new activity that we call out and then we take care of the rest the generation of the view and so it's actually very lightweight for yourselves to make modifications to utilize CM-specific stuff. Thanks for the talk. I have a question related to how difficult you found it to contribute to the AOSP Is that still your upstream? We have multiple upstreams we have two in particular so we use AOSP as our main base and then we use a lot of code from Qualcomm through Code Aurora is what they call their platform and so there's two upstreams there contributions to Qualcomm are basically a side for now right they do chipset manufacturing and just bare bones bring up AOSP has a Garrett instance the issue with AOSP is less that they're not willing to take changes they're very willing to take changes it's just you need to be very persistent in talking to people and it makes me feel like sort of an ass when I do it but you have to tag people you have to email them at their Garrett aliases and say hey look this is really essential that you look at and so they've been quite receptive to some of our changes especially when it comes to security master key exploit from last year the second one the patch that's in AOSP is one of ours from our contributor in Lisbon and so no it's difficult but it's not because they don't want it it's just their structure is they're working right and you need to basically interject and make them pay attention to your thing thanks a quick related question now do you think AOSP and Sanogen have different objectives like fundamentally objectives different enough for two to exist yes I do so AOSP and the Nexus platform are part and parcel right they're meant to showcase the next evolution in Android and software and a medium range of premium hardware it's not always the top generation of where that life cycle Android is going to be at so KitKat Android wasn't using as powerful hardware as when it's going to die next year right and so Google tries to aim for that middle ground that comfort zone and so by virtue of that they restrict themselves to the reference platforms that they're working on so a choice example would be multi sim which is very important to India was actually not introduced into Android into a lollipop because when they were developing these reference platforms it never was a factor for them Google didn't pay much attention to that because it wasn't in the hardware that they were using as reference with the introduction of the Android 1 and things more specific to this region and now lollipop you can see them focusing now on that side of thing and so CM has had multi sim support since our jelly bin release we actually took the Qualcomm implementation because they had an open source stack which is what most manufacturers here are using anyway and so we integrated that as the band aid for the lack of multi sim being inside of Google and so to the point of purposes of AOSP and CM AOSP's purpose is to showcase Android on those devices and it's very restricted to that scope of mind CM's purpose is one to enable a lot more creativity and innovation in the platform itself and the high level customizations that we have but also to have high access and so if you look at AOSP it only supports seven devices and CM across since the entire lifecycle now supports over 500 on an A build of CM it's kind of a you can see that the focus for us is just distribution we added on as many platforms to a good state as possible how you differentiate Amazon Kindle and Amazon Word what was the Amazon Kindle Kindle, Kindle, Kindle no it's a custom OS and the fire fire OS okay so the question is how to distinguish between these two Amazon Word and Amazon Amazon took the fork concept of AOSP to the whole another level Amazon is quickly growing its own ecosystem of suite of apps the store their support apps that they have now they call it Mayday and so they've taken Android but they're not trying for the the total compatibility that is what we're doing here we feel that at this moment to sell a compelling device it still needs Google certification because if you don't have an ecosystem of apps the push notification frameworks it's not a good experience for the end user and at the end of the day you're still creating a product there Sanjim Mod the source code itself is neutral it doesn't ship with either so if you wanted to install the Amazon suite of apps you can if you want the Google suite of apps you can if you're in Russia and you want to use Yandex you can any store that you choose can be capable of being your Sanjim Mod store on the Sanjim Inc devices that we're doing with partners like you the market right now is still dictating a very Google heavy experience of buying a retail Android device and so that's where that's going I don't think the ecosystem is quite ready for what Amazon tried to do with the fire phone I think the failure of the fire phones says a lot about that but I believe it was just yesterday that Forbes announced that Amazon's working on a fire phone too to try and correct someone what went wrong so it'll be interesting to see that side of the world develop as well Android battery draining problem is very battery draining very easily on Android yeah so battery drain is one Google play services is very heavy on battery and so Google has done a lot of work over the last I think 8 months to address some of those concerns but they're still holding a lot of wake locks and a lot of cycles and 2 it's the modem reception right the signal strength will vary your battery very greatly particularly when you're looking at a region like India where the towers I think you're at 3G now just on the cusp of 4G towers coming out if you get into a low signal area your phone is working that much harder and so one of the things that we're doing with you is looking at software solutions to try and address that if we know that we're in a bad network area we can shut down the radio for a little bit and try and conserve some power another one of the novel features on the device is a quick boot mode which is basically hibernate for your cell phone and so instead of shutting down your phone when you know you're going to be in an office classroom somewhere that you can't use a phone for a meaningful time because entirely powering down your phone takes a lot of juice and powering it all the way back up takes a lot of juice as well we actually have a hibernate mode where it'll take it'll turn it off and it'll go into zero power state and it'll turn back on within five seconds and because it's coming out of the hibernate mode instead and so it's features like that that we try to work in to make sure that we pay attention to the battery life. What happened with OnePlus? What happened with OnePlus? I gave them a hug yesterday, didn't you say me? No, Bridget and Vikas and a few of the OnePlus folks were here yesterday at the end of the day we've sold devices and we're going to continue to support all the devices that we've sold. The agreements and what not are basically I don't deal with those but they're in place for contracts and contracts happen when you're doing business negotiations but what I don't want and what no one at Cyanogen or OnePlus wants is the users to be left in the dark to support and so I believe we put out a blog post the other day and so we'll continue to support the devices and so hopefully this is just some water on their fridge in a month's time.