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.