Shared publicly  - 
 
Running this on my 10.1 right now. Definitely needs a bit of a tune-up, but lots of potential and I look forward to having it in CM9 :)
223
79
Alvaro Cuesta's profile photoRafael Gawenda's profile photoBart Trojanowski's profile photoCarlo Di's profile photo
126 comments
 
This would make my Android experience!
Bob By
 
OH GOD YES PLEASE
 
OH MY F*CKING GOD.
IT WILL BE AMAZING!!!!!!!
Will it be part of CM9 for tablets?
 
Talk about a killer feature. I wish Google would pick of some the guys doing this great work and build it into Android.
 
So what this post is saying is that I need to ditch my ASUS Eeepad Transformer and buy a Samsung 10.1?
 
CyanogenMod + Onskreen (opensource) = Winning Bet!!!
My GTab 10.1 is trembling with excitement :)
 
If I had it my way, it'd be like the metro version of Aero snap in windows 8, grab a card from the multitasking menu and drag it somewhere on screen, and it'll snap into a certain fraction of the screen. Very nifty and almost certainly a giant pain in the ass to implement
 
It really does look great! The only thing I don't like is the UI as it doesn't fit into the ICS theme..
 
Okay, let me please please beg you not to do this. I can guarantee you this introduces all kinds of application compatibility issues. We work really hard to give our developers a consistent environment where their apps will operate correctly across all the devices Market runs on, not being impacted by negative reviews from bad devices that they should not have to deal specially with.

If you start making your own distributions of Android behaving in such fundamentally different ways, I suspect we are going to need to start doing things to prevent you from impacting our app ecosystem. I'm not sure what, but I could imagine things such as restricting how users can interact with Market apps on these devices (not allowing reviews or such).

We have let a lot of things in this area slide -- for example to be allowed to include Market on your device you are supposed to fully pass CTS. However, if you start really diverging from the core Android platform (I would argue this takes you well into the realm of a fork rather than a customization) then some deep issues are going to come up about how we handle these custom builds.

We have been putting a lot of thought and work for a number of years into how to let Android applications run on increasingly diverse and dynamic screens. Doing this correctly, without impacting our app developers in a negative way, is a really challenging problem. I also think it is something that needs to be done at the mainline platform level, not as a customization, because doing it right is going to require new well defined interfaces with applications for them to interact with it, possibly starting with just a facility they need to use to opt in to it.
Steve Kondik
+
39
40
39
 
+Dianne Hackborn This is definitely not something we'd turn on by default under any circumstance for all the reasons you are stating. I still think it's definitely a useful feature for those that want to use it though, and like I said, it needs a lot of polish.
 
+Joaquin Vacas Verísimo I know it was, but the way windows 8 does it is sexier. Cornerstone is nifty, but clunky. Its probably fine for CM's fan base, but for a wider audience, I'd rather see it be a little more metro
 
+Alan Paone My idea was to be able to drag stuff from the recent apps list into these windows. It's a little less clunky than the mini-launcher that they implemented.
 
You guys should stick to making Stock Android great. This looks kinda like a Dell skin
 
+Joaquin Vacas Verísimo its more the drag & drop and minimal chrome that I like. Cornerstone is cool, but looks rather eclair-ish, not very icecream-y
 
+Steve Kondik maybe have that gray sidebar thing pop up with the multitasking previews
 
+Dianne Hackborn Simple solution:
1/ Add new CTS test that break cyanogenmod
2/ Wait for cyanogenmod to fix CTS
3/ Ban older (bad) CM versions from market
4/ repeat until every compatibility issue has been resolved
5/ ????
6/ Profit
 
Does anyone else's mtp not work on ics on the gt10.1? Cause mine isn't
 
if cyan did get in trouble and stopped, not sure i would buy and android device again. Due to manufactures not updating phones. Cant wait to see how cyan uses corner stones to make the Android experience even better.
 
We need a Pure Cyanogen device. I'm shocked no one has gave you an offer.... a pre rooted unlocked sexy beastly android phone already running CyanogenMod with direct update from you guys! I'd pay for that without hesitation
 
looks a bit like that Windows 8 stuff... but is a great idea if you want to watch something but still for example watch out for new tweets... ;) cant wait to get it!
 
Where could i get a test app...i wouldnt mind testing...
 
Why does it keep aborting the install? Anybody else have that problem?
 
So... whats CM9 for the 10.1 going to be released? doh Just broke Rule 1 of CM :P
 
THIS. This would make me get a tablet.
 
I have been drooling over Onskreen for a LONG time!!! I'm amazed it took this long to get attention! I'm guessing it has gotten the attention because it went open source.

I believe this is ESSENTIAL for Android's future. Maybe, not exactly this - but, something VERY similar!
 
Holy shit balls this is bloody awesome :D i want this so bad right now on my gnex :D maybe a vertical version for the Gnex :D
 
I've been hoping for this. This is great news.

To all the haters: Cornerstone can be turned off. You don't have to use it. But as long as CM puts the framework code into place, the rest of us can (optionally!) have something awesome.

The day a stable CM9 comes out I'm going to buy a Nook Tablet and make a donation to CM. Keep up the great work!
 
+Dianne Hackborn By having a new layout such as this, it doesn't specifically mean that developers will need to update. By installing this different ROM, the user should understand that what they are doing to their device is not supported at all and that they cannot expect applications to work as well as they would in an unmodified device.
I just hope the user is able to understand this. It has been working out quite well for the ROM scene, hasn't it? The different ROM's have different apps that are compatible and those others that are not- and it seems that developers still flock to the platform. I don't believe an inclusion of this modification will severely impact the App Ecosystem.

In addition, the user is able to disable the service at any time- therefore, they don't need to use it. If they want the normal version of the application, all they need to do is simply disable the service, and it will be like the application is not even there.
 
+Dianne Hackborn, I'm confused. Are you advocating that CyanogenMod stop adding extra functionality to Android? Because, if so, you've missed a lot, that's kind of the whole point really. To extend and better the platform through third-party innovation. Plus, I find it hard to believe that Google, or anyone really would consider CM a fork of Android. To use linux terminology, it's more like a distribution. Not really more different than any of the manufacturer editions of Android, to be honest. Just better.

I understand the hope to keep the platform unified, hell that was one of the main drivers of a lot of what went into ICS, but if so, then perhaps Google should just open up the development process of Android more, or merge some of the CM tweaks upstream. After all, the reason CM adds all these new features and functionality is because the community wants it. Which, is how the process for OSS development has always been done when it works. Why would anyone oppose such an idea?

All the best,

-Sam
 
You guys are missing point. This adds complexity. There is no real user looking for windows on tablets. This is basic reason most users bought tablet,they don't want computers and their complicated interfaces.
 
+Adam Sobotka I disagree with your premise. I don't want Windows on my tablet... Cornerstone is NOT Windows! It is restricted to three apps.... Which is FINE. This enables those of us with Android tablets to do a couple of tasks (most likely that compliment each other) at the same time. IMHO Onskreen is very simplistic, easier to use than Windows, and would provide me the functionality of my tablet that I always expected would appear - without making it too complex or an attempt to replace my desktop.

Yes, Onskreen does add a very small amount of complexity - but, the trade off is well worth it. Honestly, if something like Onskreen HADN'T come along - I would have been VERY disappointed! Also, Onskreen would make Android a better competitor for the Windows tablets when they hit the market for the above reasons. An Android tablet with Onskreen would have the ability to have true multitasking without the complexity of Windows!

Again, IMHO this is a win/win!
 
I have to agree with Diane. CyanogenMod gets a free pass to use Google Apps and access the market while all of the other OEM's need to pass the CTS to guarantee their compatibility just so that they are allowed to use Google Apps and access the market. There is nothing more frustrating for a developer than to receive a bad review because the person that downloaded their app was using some alpha build of CyanogenMod or some other flavor of the week ROM, that had the Google Apps and Market hacked into it.

Frankly, I'm surprised Google doesn't require CM to pass the CTS to be allowed access to the market. I can only imagine how many bad reviews are attributed to these cooked ROM's.
 
+Cal D This statement: "CyanogenMod gets a free pass to use Google Apps and access the market while all of the other OEM's need to pass the CTS.." Is incorrect/NOT valid.
1st - CyanogenMod is NOT an "OEM."
2nd - CyanogenMod doesn't "get a free pass to use Google Apps" or the market. Users of CyanogenMod must install the market and Google Apps through other means than installing CyanogenMod. Steve received a cease and desist letter long ago from Google preventing the official Google Apps from being included with CyanogenMod. AND, the CyanogenMod team complied. Your lack of knowledge on this is astounding since you are basing your complaint on these two premises.

CyanogenMod also can NOT be held responsible for "these cooked ROM's" as the team doesn't have anything to do with making those Roms.... Android is open source and anyone can create a ROM from the Android source. That many Rom "cooks" use CyanogenMod is no more CyanogenMod's fault than it is Android's fault. Like Android the CyanogenMod team has even (in the past) tried to "hide" a release while it was being developed because it had too many bugs.

So, finally you can complain all you want - but, really - the complaint lies with the ignorance of the end user and not a ROM developer. And, there is no lack of stupidity in user comments on various applications market accounts... The biggest number I see are when a dev makes an app and lists in his market entry the supported devices - and, half of the complaints will be from people using devices NOT on that list!
 
+Shane Shepherd Did I say CyanogenMod was an OEM? No, I did not. I simply stated that Google requires OEM's to pass the CTS to be granted the right to use Google Apps and access the maket. CM doesn't need to pass the CTS, but is still allowed to use Google Apps and access the market. Also, I'm familiar with the story about how Google allowed CM to use the Google Apps and access the market. Frankly, your misinterpretation of my comments is not only astounding, but baffling also.

Incidentally, how many bad 1 star force close reviews are in the market from people running alpha or beta builds of CM? Do you think it's beneficial to the developer to have to deal with complaints or handle support for devices that cannot be fully guaranteed to be compatible?
 
Wouldn't App piracy possibly increase if non-stock ROMs were completely blocked off from the Android Market?

I don't like that prospect. The Android market doesn't need app piracy to increase. Let's keep giving that audience a way to pay for their apps, please.

Why not do what Dianne first suggested... just block non-stock versions of Android from rating and reviewing apps or just block their reviews from the public in the market?
 
+Cal D I'm not trying to start a flame war. I simply quoted what you wrote: "while all of the other OEM's" - which did indicate a belief that CM should be categorized as an OEM. Frankly, if you didn't relate CM to an OEM regarding the requirement to pass CTS - then, you shouldn't bring up the OEM requirement in the first place and just state that you believe that Google should require custom ROM developers, such as CM, to pass the CTS. That would clear up any confusion.

CM doesn't have to pass (nor, should it have to pass) the CTS anymore than I would have to pass the CTS if I created a ROM from source....

I AM stating that your claim that Google should somehow regulate or prevent users from installing the market or Gapps onto a custom ROM is not a "workable" idea nor is not a "good" idea.

Anyway, this is all a side argument. If you would like to continue this off-topic discussion please use Google+ to send me an email.

Back on topic - I think CM implementing Onskreen would be a great idea for tablets - I, also, agree that there should be a way to disable it. Maybe, that could be a notification window toggle switch option!
 
Blocking Custom ROMs out of the rating/reviewing would be the biggest failure Google could possibly ever do.
Why is Android so popular? Because it's Open Source and allows almost every device running Android to be able to get Apps from a centralized market. Open Source means, everyone can customize Android like he/she wants it to be and still, the core is Android.
CyanogenMOD is imho by no means a fork... It's rather a distribution, just like Kubuntu is a distribution of Linux...
CyanogenMODs goal is to tweak Android to bring the users a unique experience in terms of performance, stability and also the newest Android Updates, because the manufacturers drop the support of their devices after not even a year or sth like that. They bring us updates to our devices to ensure we have the latest bugfixes and to fix vulnerabilities which exist in older Android versions...

Please, Google, don't block CyanogenMod by any means or in any way you can think of, that would be probably the worst step you could ever do.
 
+Christopher Flügel I don't think you have anything to worry about. Google can't restrict custom ROM developers in any way (other than preventing them from packaging Gapps inside the ROM) due to Android being open source. They prevented CM from packaging Gapps in the rom. However; that there are SO many custom ROM devs out there that still package Gapps within their custom ROMs just shows how futile such a restriction would be anyway. I'm sure that Google knows that even if they attempted to restrict users from rating/reviewing apps within the market devs would just find a way around that restriction. That is why I said in my above post that the whole idea was "unworkable."
 
+Christopher Flügel - Would it be so bad to only allow full market rating/review abilities to ROMs that fully passed CTS in order to ensure compatibility? You can't have some CM9 alpha build 18 users giving apps 1 star ratings and "THIS APP SUCKS" reviews just because they don't run well on that (very very alpha) ROM which didn't even pass CTS. The line has to be drawn somewhere.

I don't agree with revoking ALL market access (a.k.a. - purchasing apps). That would cause a mess.
 
+Matt DelMastro I would be in favor of Google creating a way for a custom ROM developer to be able to run his ROM through some type of automated test to find out if it would pass the CTS! How great that would be for the developers/users!

However, that would be a HUGE undertaking on Google's part. The reason? All of the different devices with different drivers, etc... Many of the manufacturers would oppose this as well... There is a reason they stop providing support/updates... They do it to force consumers to purchase new devices to get the latest updates. Many of the carriers refuse to allow the manufacturers to allow devices to be unlocked...

Although, I think Google having some way to allow custom ROMs developers to test their ROMs for CTS compliance is a great idea! I just don't see how it would be "doable."
 
+Shane Shepherd Again, you misinterpreted what I said, but I still find it bizarre that you somehow inferred that I thought CM was an OEM (I actually flash CM nightly builds on my spare phone).

Also, the the reason why I brought up OEM's is because they do guarantee compatibility with Android because they've passed the CTS so when a user posts a review for an app they're doing so on a device that has been deemed compatible by Google. And yes, CM doesn't need to pass the CTS and perhaps that's the problem. Google should only allow stable builds of CM, and only CM, to access the market without restrictions.
Steve Kondik
+
19
20
19
 
CM does pass the CTS, but not in any official context. For that, you need to have hardware to go with your software. There is no way for CM to currently get certified.
 
Didn't Geeksphone offer that HW platform?
 
What makes you think that a cornerstone/ cm9 distro would not pass CTS ? There are at least two devices with dualscreen available right now that passed and come with android market.
I wonder if +Dianne Hackborn saw something in the code that would break it - and maybe give the community some pointers how to fix it.
 
That clears up the air: Bravo
 
+Shane Shepherd And what if the Android Market app did a signing key check each time it started? Google could easily make it very difficult for CM users to run GApps if they wanted to. I would prefer they didn't to be honest and given that +Dianne Hackborn lives and breaths the Android framework (for the last 5 years) day-in-day-out I'm inclined to trust her opinion on what would and would not cause problems for app developers much as I love CM and like the idea of onskreen framework.
 
+Dianne Hackborn I agree with and admire your desire to keep Android functional and consistent across all platforms. However, I wish that you would apply those same rules to OEMs. As a developer I've had a horrible time dealing with crappy implementations and changes by OEM. I've seen the default Android Music player removed from many devices, and now on the GN it has been replaced by Google Music, which doesn't store playlists in the standard location. This is a nightmare for apps that rely on this documented functionality. I've seen bits of standard APIs completely replaced, including core stuff, like the contacts app.

Worst of all, where you talk about negative reviews, I have a good handful of negative reviews, all from Droid X users, who's phone reboots randomly while using my app. It turns out that they reboot randomly when playing any audio, but as many users only really play audio at all when using my app, they think that I introduced the bug. I can't respond to these reviews; I can't point out that Moto just don't give a damn about fixing it. I've actually resorted to having a pop-up dialog just for Droid X users, warning them that their phone might reboot. I considered blocking it on the Droid X, were it not the second most popular handset out there. ALL of my bad reviews are from Droid X users.

So yes, please continue to encourage compatibility and consistency, but please do it consistently. I'm sick of compatibility issues with Sense/Touchwiz/Motoblur screwing up my apps.
 
Kinda like a forum.... This thread is getting off topic. +Curtis Fletcher For a the market to check for an app to have a "key" all that would happen is that key or keys would be copied and used for all apps or the official market app would be altered to circumvent...

Anyway, if someone wants to start a post about the separate issue of ROMs, app signing, compatibility... Please do so and I'll be more than happy to jump on there.. But, this post was about Onskreen! :-)
 
+Shane Shepherd that's not what I mean, the Android system itself is signed with a key, we do not have access to the official signing keys, CM uses it's own self-generated platform key, if the Market app checks the system signing key it can verify who signed the os build. Sure you could try to Smali/Baksmali it out of the Market apk, but at that point you are butting heads directly with Google proper and I could see C&D's flying left right and centre, and that would hurt everyone. +Dianne Hackborn is not one to toe the corporate line, she knows more about the platform than all of us put together and does not suffer fools if she says its harmful then it is harmful, what CM does with it is still their choice but the consequences could be huge
 
+Curtis Fletcher All I can say to that is that if Google went that route I'd start looking at the other platforms out there...

This is my last response to this post unless it is on topic!
 
I love it. Tiling window managers have come to Android.
 
i really liked that all their code is properly marked (with a comment) - made the porting job really easy
 
+Steve Kondik Love the idea of drag and drop from the scrolling recent apps list to make an app active in one of the three "app panels".
 
Hi, need to get in contact with you guys at Cyanogenmod.. Need help on a project. We are aiming to brin torchat to Android and maybe iOS also later on. Check this site: http://code.google.com/p/jtorchat/

Interested in helping out or do you know any good Android hackers? :P
 
Pretty awesome idea! I've actually run out of stuff to put on the screens of my Asus Transformer. I only have 3 screens and only my homescreen has a lot of stuff on it.
 
UI and controls of Onskreen look pretty bad...Glympse on WebOS is similar but looks a lot better
 
+Wilfred Yung I agree. But, it's been brought up several times that it needs some polish. I'm hoping it will get some with all this added attention. I'm excited to see how it looks with a theme more consistent with ICS!
 
Idea from +Cameron Wright, but simplified: if ever this is to be introduced, even unofficially, it should be a recovery-flashable update zip, that has to be applied manually, that is maintained out of CyanogenMOD code mainline, and that introduces a simple check: if CornerCM is detected, Google Apps such as the Market are to be automatically disabled, enforcing the fact that You are on your own and this is NOT true Android.

Honestly, I'm on +Dianne Hackborn's side here. It's simple, really: +CyanogenMod is the only AOSP "mod" that can be considered OEM-level as far as software and customisation are concerned, and the project was given a near-free ride because it sticks to Mainline more often than not [I'm tempted to say always, but we all know that a single modification in any part of the code can introduce a number of side-effects]. As such, quite honestly, I expect Google to be able to have a say in what the project decides, and not to be a dick, but if they want to "guide" it back to something that's on track with them, I think that, as a community, we should listen to them, 'cause they could very well flip a switch and say "Fuck this, CM's on their own".

It's their OS that we, as a community, customise, and the fact that a community as huge, awesome, flamboyant and active as the Android community, with an AOSP-MOD core OS part, is a testament to Google's awesomeness and willingness to embrace the "people's vision".

But be reminded that they don't have to let us have fun.

tl;dr: Cornerstone builds should be handled with extreme caution or be a totally separate entity.
 
+Renaud Lepage I think everyone's jumping the gun here. Rather than draw lines in the sand, we all need to take a step back and actually work the problem; look at the code, see what needs to be fixed to gain Google's approval on this, see what polishing can even be done, and then start coming to conclusions.

And, to be quite frank: Android is their OS, but CyanogenMod, the devs, and it's users are on the bleeding edge of the Android revolution. Rather than "flip a switch" and potentially alienate their most truthful followers, there needs to be an open dialog.

Also: The day that Cornerstone makes CM not true Android is the day that Google should make sure Sense, TouchWiz, Motoblur, and every third-party OEM implementation that breaks core Android functionality (I'm thinking Bluetooth stack) gets the same treatment.
 
+Sam Stuewe I am not at all saying don't add functionality. I am saying behave like a proper platform developer and do this carefully in a way that doesn't cause problems for app developers. I know it is fun to dive in and throw stuff in left and right to make all kinds of crazy things happen, but part of doing platform development is stepping back and looking at the big picture so that you make sure you dot all of your i's and cross your t's. This means in part considering how a change will impact app developers, testing changes extensively against existing apps and doing what is needed to keep them working, and generally being respectful of the ecosystem.

+Shane Shepherd It is pretty disingenuous to claim you are not an OEM so the CDD is not relevant to you. When anyone ships an update to the platform on an existing device they still need to be compatible with the CDD; it isn't about whether you are shipping hardware. Yes, the enforcement of the CDD is done by controlling licensing of Market so that CDD compatibility is a requirement to be able to ship Market. You have a work-around that allows you to do updates without having a license yourself for Market... but again, I ask for some respect of the ecosystem and consideration of some of the bigger picture.

+Ronan Schwarz The dual screen devices were done by those manufacturers in a careful way to not break apps -- existing applications are only run on one screen, so they don't break. This kind of thing is done closely with the manufacturer in order for them to be able to ship Market in a way that won't impact existing applications.

As far as what issues there are, there are two obvious things I can tell you right off that make this not compatible as per the CDD: when the side panel is displayed, the resulting aspect ratio of the main app area is outside the limits allowed by the CDD, and changes to screen size available to apps is not compatible per the CDD. These limitations are in place for very real reasons: for example, consider apps that are using Market's multi-apk feature to have different .apks for tablet vs. phone screen sizes, and what happens with them when they switch between these two states? (Handling this probably means first of all aggressively deprecating the use of multi-apk for this stuff, which is why it needs to be done as part of the core platform and the developer relationship with the platform.) Even ignoring multi-apk, I can guarantee you there are apps that will break if switched between these sizes.

Here's a basic rule of thumb when working on the platform: if you need to make changes in any of the platform apps as a result of changes you are doing in the platform, you almost certainly have introduced compatibility issues that are going to impact our third party apps. For example, what do you think the standard platform launcher is going to do when its screen size is changing like that? It isn't going to be happy, and nor will many of the third party launcher apps. With the change you are looking at here, these kinds of issues are going to come up all over the place, and solving many of them will require introducing new contracts with applications and the platform (a.k.a. APIs) for them to work with it. Plus a lot of careful compatibility code to make sure existing apps don't get into situations they don't expect.
 
+Dianne Hackborn First, I would like to clarify that I do not - in any respect - represent CyanogenMod. I am simply a user who has flashed custom roms since the G1/HTC Dream was released. I am not affiliated with nor have i ever worked on the CM team... So, please understand that my opinions are my own and no one elses.

I don't believe your comment about my being "disingenious" regarding the claim that CM is NOT an OEM is fair! I never said the CDD is not relevant! I agree a rom developer should strive to be compatible with the "CDD." However; this is very problematic when all the tools/resources to the hardware are not readily available! (Closed bootloaders/hardware drivers) So, in that respect it is about "shipping hardware." The CM team has attempted to support devices long after the "shipper" stops official support and has done the best job they can to ensure the best compatibility possible for all of their officially supported devices. From an outside observer's standpoint I have always had the impression that CM has striven very hard to ensure that their official releases comply to the absolute best of their ability with official standards. SO, in this respect I believe the CM team has displayed a LOT of respect for "the ecosystem" and has displayed significant consideration of the big picture. All of the modifications/enhancements CM has made seemed to display deliberate care NOT to "break" any aspect of Android, the market, or any applications,

Many members of the CM team have caught a lot of grief online for being unwilling to support certain devices when they weren't ready. They have a standing rule/request that users should not ask for "eta's" for releases - because, they don't want to be pressured to release their rom before it is ready. They don't support many devices because of that respect for the ecosystem. Many requests for features and enhancements were denied for the same reasons...

I agree with +Tim Tahtinen in that no one is attempting to "draw" a line in the sand and I appreciate the clarification of issues that Dianne has highlighted.

+Renaud Lepage I would disagree that CM was given a "near-free ride" - if anything, they were treated more harshly than others... How many other developers have been issued a formal cease and desist letter from Google? NOT MANY! Also, I really don't agree with disabling the Gapps if Onskreen is detected.... That would defeat the whole purpose of havong Onskreen in the first place... What use is it to have something if I can't use it?!

However! We are all, like +Tim Tahtinen said "jumping the gun." Anyone who knows how Steve and the CM team works will also know that Onskreen will NOT be placed into CM without extensive work and testing to ensure the highest level of compatibility possible within the limits that the team is constrained.
 
Im so surprised as a user about Google not leting us use (pretending) this awesome functionallity THEY should had implemented years ago!!.. Real Multitasking we have not now!
 
+Ricardo Reyero This framework has a high likelihood of making the Android app ecosystem a much harder place to be as an application developer. A completely resolution independent UI is a problem that no OS has ever solved (try and run most windows apps at QVGA/120x160) The main reason onskreen look good right now is that there are too few Android apps with good tablet layouts (Android Market and G+ I'm looking at you) making this look attractive but what happens when a honeycomb+ app expecting at least 1280*800 gets squashed into one of the side bars?
 
+Shane Shepherd I still think you are not understanding the purpose of the CDD. It is not about shipping hardware, it is about the environment an application must run in, in order for that to be a compatible Android platform and thus allow Market and all of its apps on it. Yes there are some hardware-oriented requirements in the CDD, but these are only because that hardware environment impacts apps. The CDD is very careful to only discuss things that have an impact on the environment apps run in.

Not having access to hardware or other restrictions that prevent you from being compatible with the CDD is not an excuse. For example, the ICS CDD added a new requirement that the device supports hardware accelerated rendering. Any manufacturer who has an existing device must meet this requirement to be able to ship ICS on that device. If CyanogenMod doesn't have the OpenGL drivers needed for a device to meet this requirement, what it is doing is not compatible with the CDD. And as with anything that doesn't meet the CDD requirements, this has a direct impact on app developers because the whole point of this requirement is that when targeting ICS or later they can assume all of the behavior and features of hardware accelerated drawing, and you have broken that contract.
 
Yes, in the past we were able to use older OpenGL drivers from the vendor but it's not really the case with ICS. We have some crazy workarounds to just get ICS running on older devices that will never see a vendor-supported upgrade and therefore users are going to want it. The last thing I want is broken apps though. If there were a way to designate that a device might have limited OpenGL capability that could solve it. I am not sure what to do about the situation though. I don't expect that these devices will become officially supported by CM but that isn't going to stop developers from trying to make it happen, though.
 
I am the CEO of Onskreen and felt it was about time we weighed in on the public discussion. To start off with, we have been impressed by the level of discussion on this thread on the topic of compatibility. We take it very seriously and are glad that the rest of the community do as well.

+Dianne Hackborn - Thanks for sharing specific concerns and we can appreciate their gravity and the need for a dialogue. However, outside of the implementation details perhaps some background will help. Onskreen saw an obvious need in the UX of Android on larger screen devices (that is our business after all), and we worked to address that with Cornerstone. During the process, we have invested heavily to respect Android's intentions and compatibility of the Frameworks you helped build. When you get a chance to review the code, you will see that we went out of our way to not introduce app requirements, leverage the patterns already used, and treat running Applications in a way that they are oblivious to the Cornerstone experience. We rejected many features along the way to optimize for compatibility. The result is a product that we are proud of, respects the Android project, that the user and mod communities are excited about, and OEMs love. And frankly, once you use a tablet with multi-tasking there is no going back. We are the first to admit the product is not perfect, but was at a point where we felt comfortable sharing with the community to use, help improve and polish. We see the goal of this conversation as a way to come to an agreement on some of the aspects of Compatibility and deliver multi-tasking on Android.

Now - a few of your concerns:

- Orientation - Good points, and we spent a ton of time thinking through the UX here. Cornerstone adheres to the desired orientation of the Application running in the Main Panel (and rotation of the device). Cornerstone restricts the user from opening an app that won't support all orientations in the Cornerstone panel, so there is not a case where an app running there is forced into an orientation the app developer did not intend to run in (try opening Angry Birds in the Cornerstone and you will see this). There is more here but I will leave it at that for the time being.
- Screen size changes - You point out the complexity of a changing screen size on an app. We agree and this is the reason that swapping panels (applications moving from the main area to the cornerstone or vice versa) was removed from the product. Apps at this point just aren't enforced to consider this, so Cornerstone imposing it on them would be incompatible and we don't (although we all sorely miss the feature). One area we are still considering is the Config of the main app. Logically this should change when the user minimizes/maximizes the Cornerstone, however the implementation is not doing that because of compatibility issues it would introduce. To be fully compliant we are aware that we will may have to remove the ability to minimize/maximize the Cornerstone (we will miss that feature too). Perhaps you have some suggestions here?
- ProcessRecord/ActivityThread Configurations - As you mentioned, while the ActivityStack was refactored out during your exploration, other inherent dependencies on a static Configuration do still exist. Some interesting features could be enabled by expanding this, but we didn't make these changes so that the Cornerstone codebase could more easily be used in customized Android trees of OEMs and others, as well as perhaps in upcoming Android releases.
- CDD Compliance - We take this one very seriously and you bring up good points. However, our intention is that each area (the main panel and cornerstone panels) be designed as CDD compliant sizes. That is not fully the case in the .85 release that was open sourced. As we made the switch to v4.0.3_r1 and the 1280x800 reference device (Xoom), we haven't made all these changes yet. It may require that some of the panels in certain orientations run in a pseudo compatibility mode similar to how the Android OS supports legacy apps already so that their config is CDD compliant and the UX is optimized.
- CTS - One test in CTS calls for any Activity that doesn't have the focus to be moved to the paused state. This is obviously not the case in Cornerstone as Activities do stay resumed when not having the focus and still are visible on the screen. Google could ding Cornerstone for that and in truth they would be technically correct. However this would be silly considering the nature of the test when applied to a real multi-tasked environment. That is not our call however.

In short, we think about the same problems you do and we believe in the product as well as maintaining the integrity of Android applications and devices. You of all people can appreciate the complexity in working with the Android framework in the way we have to get Cornerstone built, and to call it a fork is doing the design and engineering effort that went into it a disservice. We see the point of AOSP and contributions like Cornerstone to create a dialogue, come to agreement and add great features to the platform. To that end, we are more than happy to continue this conversation. Some of us are in the bay area and happy to drop by Google if you prefer.

hansmeet.
 
+Curtis Fletcher .its thx to the devs of android and no thx to Google that my toshiba folio 100 is an useble tablet.. Right now with an alpha cm9 that was unthinkable months ago!.. With normal issues and bugs.. I eould say lovely bugs!
 
+Dianne Hackborn You were correct in your previous response to me. I was getting CDD and CTS mixed up there for a few. Apologies. It wasn't emphasized in my previous post - but, I do appreciate your interacting with us on this post and clarifying your concerns. Interaction by official Android developers with the custom ROM enthusiasts is great. Your expressing your concerns (while our discussion may have seemed somewhat excited) is wonderful - because, it relays concerns that the official Android developers have regarding future development. Many custom ROM developers consider themselves to be on the leading edge of Android development as far as features and support for "legacy" devices... Knowing your concerns allows the custom community to have a better focus on ensuring compatibility. So, I would like to say thank you for interacting with us on this post!

+hansmeet sethi I would like to thank you as well. I have been a fan of Onskreen since your company released the first video. Your explanation of why many of the past features were removed is good to hear. I was disappointed that many of those features were not in your latest release - but, knowing those features were removed for compatibility issues removes most of the related disappointment.

I am simply an Android enthusiast/user. While I have loaded and assisted many of my friends and convinced many to use Android - I have only owned three devices. My first two devices (especially, my G1) had a much longer usage time due to custom ROM developers. My experience is that all of us are VERY interested in keeping Android (both official releases and the custom ROMs) as bug free and app compatible as possible.
 
In my experience OEMs have broken a lot more apps than CM ever has, if it all.
 
First, let me start off that this has been a very interesting and educational read. I am a Software Developer by trade, and +Android Enthusiast/Developer by hobby. When I first saw this thread on my stream, as well as a post by +Android Police, I was intrigued. Then, I saw another post that had Cornerstone built into a +CyanogenMod 9 fork for my HP TouchPad. I installed it immediately. Though, I haven't really played around with it fully, I did notice features that I would like to see added (switching apps between the center to the side-pane, closing apps in the side pane, etc), but all-in-all, it's pretty awesome. Then, reading more from +Dianne Hackborn and +hansmeet sethi, I found out that these suggestions had been implemented and removed to maintain compatibility with the existing framework. Bummer, but always the better choice.

Also reading the posts on Cornerstone's Project site, as well as the reshared thread from +Renaud Lepage, I would have to say that anything that can be done to implement a true multitasking environment on +Android would be awesome, especially with the use of Bluetooth and MHL (read Android PC).

<slight_tangent>I think webOS really hit the nail on the head with multitasking on mobile/portable devices. Cards are a great, and would love to see them integrated with Android. As they are a slightly smaller (i.e. - maybe 80% and keeping aspect ratio) version of the current app, there should be fewer potential compatibility issues (i.e. - the different APKs per DPI might not be an issue). It would be like an amalgam of the two launchers, where Cards can be overlayed on a "desktop" of widgets and shortcuts, that would allow "minimizing" and "restoring" of Cards with a click of a button (possibly next to the App launcher), and a swipe to close. But, not having looked at the framework code in Android, nor the recently Open Sourced webOS, I do not know if this is even feasible.</slight_tangent)

Any way, I really love what +Steve Kondik and his lackies team are doing, as well as +Dianne Hackborn and everyone else at Google making the best mobile OS out there! Keep up the great work!
 
+hansmeet sethi I am not intending to criticize your ability or quality of work. My point is that these kinds of fundamental platform changes do not belong in forks of Android that will be serving apps from Market. When you look at the significant amount of complaining we get from developers about "fragmentation" and dealing with differences between devices, I don't see how we can take any other position.

A lot of our effort on Android involves trying to keep the explosion of the platform under control, as it becomes pulled in a hundred different directions. The ability to be customized by people like this is a great power of the platform, and I love seeing all the things people do with it. At the same time this runs a tremendous risk of turning it into complete chaos for developers, which is why we have the control point of Market being able to apply consistency for app developers through the compatibility definitions.

Ultimately here is what we would probably tell anyone wanting to ship this modification with Market (which would need a compatibility exception because as we both agree it is not entirely compatible with the CDD/CTS): all existing apps must run on a screen that never changes in size, which is compatible with the sizes specified by the CDD. This means for you probably all existing apps running full-screen (you could probably have your panels slide out on top of them as long as they don't impact the display size seen by the app). You can have a custom API for applications to opt in to your experience (for example a meta-data tag in their manifest), but they must explicitly opt in to any such changes in behavior, and not by you assuming they might work because they support both landscape and portrait.

I realize this not what you want to hear, but it is what we need to do for our developers. Even ignoring CyanogenMod, I assume you are looking to get this software on shipping products, and will face this discussion then. It is the same kind of discussion we have had for other things like devices with multiple screens, and the same kind of approach was required in those situations as well.

Finally, generally having a "compatibility mode" like this is not acceptable outside of the core platform. At the end of the day, these types of compatibility modes are rarely perfect. I know from experience that the screen size and density compatibility modes were done to the point of "good enough," but definitely not perfect, and it is often not even clear how to get to "perfect." By their nature, compatibility modes are there just to bootstrap compatibility -- there are various downsides to them, so strong pressure on developers to update to get out of them, and I don't think these pressures coming from outside of the platform are good for our developers.
 
+Michael Lass We have been extremely considerate of CM. I am not making threats, I am pointing out the reality of working at the platform level where you are having a deep impact on third party developers and causing significant harm with things like causing them to get unwarranted negative reviews on apps they are trying to make a living on. I am just asking, if you want to deal with the platform at this level, to have respect for everyone else beyond just your own desire for features for yourself.

And bringing carriers and such in to this is nothing but a red herring. We are talking about changes that fundamentally alter the behavior of the platform, not doing builds of the platform for different devices.
 
+Michael Lass Let me put this another way: CM gets to work in a fairly privileged position, where they don't need to pass any compatibility tests for Market to install third party apps on it. This is not how most people need to operate, they need to show they pass CDD/CTS to be able to have Market. This works okay as long as CM sticks to relatively stock Android. However, if it starts significantly forking in behavior applications see, then you are putting us between a rock and a hard place, and something needs to give. Is it to let developers hang, or to treat CM more like everyone else with the associated compatibility requirements?
 
CM is the only unification of Android there is. All OEM releases of Android are FORKs. Period.

The real issue digressed from is why would there be app compatibility issues to do this, to begin with? Is this stressing the graphics framework beyond its tiny little realm of expectations?

We have RDP, multiple-desktops,etc on Windows. It broke preconceptions and poor, immature OS implementation (OEM hackery). It is a GOOD thing. It'll be even better for putting a magnifying glass on all the little demons (crap code) that's the Android UI framework.

I'm curious as to what entire apps based on Qt would handle this. A less reinventing the wheel there.
 
Cornerstone v0.85.1 is out! Check out at https://github.com/Onskreen/cornerstone or http://groups.google.com/group/cornerstone-dev/browse_thread/thread/2d488f5e5d8b5b6f.

The official ROM for Motorola xoom can be downloaded from https://github.com/downloads/Onskreen/cornerstone/onksreen_cornerstone_v0.85.1_wingray.zip

Version History : https://github.com/Onskreen/cornerstone/wiki/Cornerstone:-Version-History

Test the latest version and give us your valuable comments.

Thanks,
Sanjay Jain
Ryan Dahl
+
1
0
1
0
 
+Dianne Hackborn It's cute that you don't have a problem with carriers and OEMs raping your product, but private developers that are adding useful functionality instead of VERIZON-VCAST-HTC-TOUCHWIZ-ULTRA-SEMC-LOGGING-SERVICE is somehow a major compatibility issue that warrants threats of banning users of the distro from the market -- somehow I doubt HTC received the same warning.

People using modifications like this are well aware that applications direct from the market will not be 100% compatible 100% of the time. You're inventing a non-existent crisis, here.
 
Seriously I think this is getting blown way out of proportion. Diane I understand your need to maintain a uniform experience and prevent fragmentation of the Android platform but Cornerstone NOR CyanogenMOD are doing any of these. If anything these two should be shining examples of what Android SHOULD be and how applications as well as ROMs should be created for devices. Since my G1, Droid, LG G2X, Transformer and Transformer Prime I can say that CyanogenMOD has ALWAYS been the goto ROM for these devices. Simply because they are far more stable and perform better than any factory load from Motorola with Blur, HTC with Sense or Samsung with Touchwiz. Not to mention that Cornerstone does not have to be used and can be disabled. These are things that cannot be said of the Android OEMs and their overlays and what their overlays break as far as function and compatibility. These are not forced upon us in any way and those of us that choose to run CyanogenMOD and Cornerstone do so willingly. Unlike the masses that are forced to use an Android device with overlays, Sense, Blur, Touchwiz, that cannot be removed or disabled. If anything your ire should be directed at the OEMs creating these overlays and forcing them on the consumer and taking away from the stock vanilla Android experience.
 
Just thought I would res a dead discussion. Dianne is all about keeping things uniform and nice nice saying that OEMs go through all sorts of certifications. Chew on this... ooh and it's Moto you know,.. the company that Google bought.

http://www.droid-life.com/2012/03/07/own-a-motorola-device-google-play-store-update-probably-just-broke-your-market-links/#disqus_thread

Turns out that Google play breaks the Market link on Blur devices. Imagine that? All that testing and Blur doesn't like play. So much for uniform. Oooh CyanogenMOD w/ and without Corenerstone work just fine with the Google Play update. Whatever.
 
erm +Dianne Hackborn just to let you know the galaxy note 10.1 has this exact same system... and the android market is available.. not sure what your problem is...
 
+Dianne Hackborn As Onskreen does also contribute apps to Android, we do very much appreciate the stated concern for pixel perfection. However our concern is not actually technical, there are clear ways to appease the various critiques that you and others on the Android team have made. The concern unfortunately is with the process and how the rules are applied to various Android ecosystem participants, perhaps you can contribute to alleviate these concerns.

As +james bricknell and others have pointed out the Galaxy note has a similarly modified Android framework to enable multi-tasking. While the experiences are different, the intent is the same and the modifications to the display apps run in are similar. It would interesting to hear your take to shed some light on how one (Galaxy note from Samsung) is acceptable and seemingly approved by Google while the other (Cornerstone in the open source community) raises red flags.
 
I am using Cornerstone on Xoom. It is really good. Yes you have to understand it is a work in progress using custom roms with modifications to stock android. But stock android is a work inprogress. Only slower. Thank you developers.
 
Can't wait til its officially supported the the CM Team
 
+Steve Kondik +Dianne Hackborn +hansmeet sethi Would love to hear your thoughts now that Samsung has included something similar (video in a separate window) in Galaxy S3. I guess they would have definitely had to pass CTS. So, is there a change in the stance from google?
PS: Anyone knows if samsung is actually using the same (or derived) work from cornerstone for this feature but just limiting the application?
 
I'm curious, +Steve Kondik whether this could possibly make it into CM10 in some form or has it been taken off the table completely?
 
+Dianne Hackborn Why is Samsung allowed multi-windows and not #cyanogenmod ?? If Android team was in no contact with Samsung, why don't you ban Samsung devices running multi-window from Play Store? At least not allow commenting?

#Android  being open source should support custom ROM makers like CM! Most OEM releases the phones and no updates at all. But CM brings the latest updates to every phone possible. So actually CM supports #AOSP  much more than phone makers!! And also brings the Original AOSP to the phones, rather than slow and buggy and feature less modifications! Reasons why I say so:

1. I have used HTC with sense (HTC Desire/Desire HD), Samsung TouchWiz (Galaxy S2/S3/Note II), Motorola (before google) with MotoBlur (Atrix 4G/Defy), Original Android (Galaxy Nexus/Nexus 7/T-Mobile G1)

2. I had to root every one of them and install CM because there were no or very delayed updates. They don't bring new AOSP features to old model though they are more than powerful enough to run! (Everyone, other than Original Android, but I did root to get extra features)

3. Though S3/Note II is updated to 4.1.1, it probably uses an old Camera app. Just try taking a Panorama! It takes pictures at ending lines and join up (not true panorama feature in AOSP). I took a photo of an island and it was broken in half!! They tend to keep their old modified apps even with newer builds. IS THIS REALLY UPDATING TO NEW ANDROID VERSION??

4. OEM customised OSs are slow and laggy. Just try ending all apps and opening contacts/dialer on S3 or Note II.

5. OEM adds useless features that we can't even end even if we want to. Samsung is running their own push service though AOSP has a great push support.

So, why is Samsung allowed and not CM? As far as I know, CM supports AOSP much more than Samsung. CM brings latest features to any supported phone. Not just an update saying 4.1.1. They do actually bring the features on 4.1.1 (like camera app)!!! So if at all, you should allow CM to do things like that, not Samsung who is not truely supporting AOSP.
 
+Dianne Hackborn 
Considering not only the developer's app  but also the final user,
that would make android live longer
 
Pardon if I may post something that's already discussed since I haven't read the whole conversation. I just encountered this issue when I was researching about samsung's multi window feature.

I would suggest why not enable this feature and just filter the apps that would be allowed to have multi window compatibility by adding some permissions through the apps manifest file?

It would be adding something like 

<uses-permission android:name="android.permission.MULTI_WINDOW" />

or something like 

<manifest android:multiWindow="true">

that way developers have the decision to implement multi window feature on their apps without breaking compatibility on all apps on playstore whether the feature is on or off. I don't see any drawbacks if this type of filtering is implemented. In fact this type of implementation would give 100% compatibility on CM's end and also on any app developer's end.
 
That's also what Samsung does, right? And presumably their Google apps access has not been revoked, so...
 
@Ibrahim Awwal
No I don't think that's how samsung implement theirs
 
I thought the app had to opt in somehow to the multiwindow system, was not sure of the exact mechanism. Although it may have changed from the first implementation on the Note 10.1 and the subsequent one on the Note 2/ Note 10.1 JB update. I switched to CyanogenMod a week after getting my Note 10.1 (basically as soon as it was available) so I dunno what the Samsung experience is really like.
 
+Ibrahim Awwal Samsung uses a hardcoded whitelist in the framework.  Last I was aware, there was a specific list of 17 or 18 "allowed" apps.  Anything not on that list = not compatible with multiwindow (except potentially with some of the exceptions Dianne mentioned above, e.g. a compatible app "on top of" a non-compatible app, so the non-compatible app doesn't ever have its perceived screen size changed.)
 
It seems like double standards, but I'm sure +Dianne Hackborn  and the team were against Samsung doing this too. Commercially it would be crazy to deny Samsung (the biggest seller of Android handsets) access to Google Play. Essentially, Samsung can do what they like with Android, because they have a great deal of power. 
 
+Martin Long I think you should read the comments before commenting yourself.  Dianne DID say what someone would need to do if they were to implement such a feature (make it "opt-in" for verified apps) and that's what Samsung did with their multiwindow whitelist.  Samsung's approach won't break random market apps because it disables multiwindow for non-whitelisted apps.

Could CM have implemented such a whitelist or opt-in function?  Yes.  Would it have made the Cornerstone feature worth the effort to include if it only worked with "whitelisted" apps?  Probably not.  The big difference here is - Samsung can go to Twitter, Facebook, etc, ask them to do something special, and have them say yes.  If we went to app developers like that, they'd probably ignore us.  While CM is big in terms of the custom firmware community, in the grand scheme of things we're still pretty small.

Now if Samsung themselves disable the whitelist check and allow multiwindow for ALL apps somewhere down the line - then that's going to be a big "WTF?" moment in regards to CM and Cornerstone.
 
hi,are there somebody trying to build the corner-stone source?
the surface view seems strange in  window-panel mode
 
I'm unaware of anyone who has touched it in months.  (Actually I think one person commented on lightly poking at it...  but for the most part it's been dead...)
 
my sister tried guessing boot-up pattern im locked out. how do i get back in?
 
+all:
I think I've got a solution:
1. Cornerstone should only list certain apps
2. To add an app to this list, the app itself has to make a call to cornerstone
3. The app will be added to cornerstones app-list on the device until the app sends a deactivating intent.
If we would do it this way, it wouldn't break apps, because devs would have to implement cornerstone functionality theirself -- and if you look at DashClock, you see, how fast this can be -- and you would also bring us all major steps forward while staying compatible with googles rules.
 
is cornerstone souce  free  in  comercial  use?
 
update: removed   video
 
+Gurkirat Sidhu Not gonna happen.  Too much effort to implement when combined with the limitations of +Philipp Koschinski 's suggestion.  (Phillip, that WOULD work, but then you get into the realm of "feature with LOTS of code to maintain and minimal benefit" since very few app developers would actually opt in.)
 
+Andrew Dodd If you would use the implementation from the Paranoid Android Team as something to start with you would have to change only a small part of the code and you coulod make this possible -- and look at DashClock, there was said nobody would use such an API, and now almost every app is  integrated into it.

TL;DR: There is some existing code to start with.
 
I'm not sure how I can view the original post, but... (I'm sure this has been said before).  Samsung has implemented this in a very limited way... I'm not saying adopt a limited app support model, but... I'm surprised that not even offering the option of turning this feature on when a user want's too, is pretty hard core when you can leave it off by default (maybe Google want's a completely stable enviro I'm guessing?  Why not make this an unsigned package then?)
 
It seems inevitable that the Samsung 'white list' approach is the only way to safely integrate this much-requested capability. It could be a part of the stock Android launcher, just as it is with Touchwiz, and the ubiquity of it would give developers more incentive to work on ways of supporting it - and if they can't, then they can just choose not to opt-in. As Diane suggested, a simple meta tag would suffice. Enforcing this at a system-level on all apps is a blunt instrument, but bringing it in as something app developers can choose to use is good for Android and good for developers (just another feature to tempt buyers with!).
Add a comment...