Originally Posted by CYANOGENMOD
in facebook
CM 10.1 Status Update
So we continue to work through the merger of 4.2 code and our CM enhancements. A branch in our github repos called mr1-staging has been created to facilitate the merger and is the target for core CM items (not features).
mr1-staging is not meant to be compile-able, its only purpose is to be a staging grounds for our core work. Chances are, it is useless for independent builders.
CM 10.0 (4.1.2) code is in jellybean-stable, if you are working on a bug-fix for the last stable release, patches should be submitted against that branch. If/when we do another 4.1.2 release (ie CM 10.0.x), it will originate from code in this branch.
Once staging is done in mr1-staging, we will push all that code to a 'CM10.1' branch, and eventually back to our primary 'jellybean' branch. This process is in place to make sure that we effectively move forward from CM 10.0 code, instead of starting over as was seen with the jump from Gingerbread to ICS. Patches from gerrit will be accepted towards CM 10.1, but for now, please have patience while we work through mr1-staging.
While the 4.2 updates are on a smaller scale, they do present some changes that will need to be considered and will effect our implementation of features. Just to name them briefly: Telephony Split, Multi-User, Quick Settings, and Lock-Screen Widgets. These items will be a strong focus when the initial CM10.1 branch is created.
On the feature front, David van Tonder (dvtonder) decided to make his weekend productive, and has already worked on the code for the majority of our MMS enhancements: Emoji support, sms split, gestures and templates, quick messaging. Notably MMS auto retrieve is not being forward ported as Google fixed that themselves. As stated above, patches will hit gerrit review after this staging process is completed.
As always, a timeline isn't and won't be available. We will continue to provide updates as we have them.
Click to expand...
Click to collapse
Let's wait for further announcements
FXP has already stated that they won't be brining 4.2 (CM10.1) to any of the 2011 devices because of RAM limitations.. which makes this news pretty pointless.
Edit: FXP post here: http://forum.xda-developers.com/showpost.php?p=34344841&postcount=3896
Related
This is a preemptive note about posting any new threads asking "when will honeycomb come to the gTablet?" or "why can't we do this because the Nook has it?" or "why isn't the sky blue today?"
Honeycomb is not available for the gTablet yet for the following reasons:
1. source hasn't even been released by Google yet
2. any port based on the SDK doth not a Honeycomb ROM make
3. we do not even have libraries (or source) from nVidia for Gingerbread yet
Until we have source from Google and nVidia, we won't have workable Honeycomb. There will be some ports, but until one of the above happens, we are not going to be getting Honeycomb. Best case is 30 days from now (roughly the end of March).
Any post asking about Honeycomb will be promptly closed and/or deleted.
This isn't about discouraging discussion about Honeycomb on the gTablet - it's about stopping the endless flaming and abuse and posting and complaining about something that has been answered multiple times - thus taking away from other progress and endeavors.
UPDATE 3/18/11 - We now have access to the Gingerbread libs needed for hardware acceleration, but in order to use them a complete rework of the github repo is required and a year's worth of merges and cleanups would need to be done. Slow going and no ETA.
UPDATE 4/12/11 - http://www.androidcentral.com/nvidia-stop-supporting-harmony-platform-past-froyo
UPDATE 4/13/11 - http://developer.nvidia.com/tegra/forum/honeycomb-harmony#comment-6191
UPDATE 13 APRIL 2011
A lot has been read into a very short post about a Tegra development kit. I'd like to clear up a few points.
First, nothing changes in what we’re delivering to the open source community or customers. NVIDIA will continue to post the Tegra kernel to kernel.org and publish our Android code to our public git servers. Additionally, we will continue to make our BSP (codecs, GPU driver etc) available to all our hardware partners. We will continue to do this and nothing about these processes has changed.
For our partners' Android devices, NVIDIA provides support until the hardware partner chooses to no longer support the device. So, for instance, NVIDIA will support the Xoom on all versions of Android Motorola requests until Motorola ceases to support the Xoom. The same goes for ViewSonic with the G-Tablet, Notion Ink with the Adam, Acer with the Iconia, LG with the Optimus 2X and so on.
In relation to my original reply, that was a response to a specific question about a Tegra 250 Development Kit. Given the confusion, we will work with owners of Tegra 250 Development Kits individually to determine their needs. The term "Harmony" is an internal codename for the Tegra 250 Development Kit. It is not a tablet reference design. Each shipping tablet is a custom design with varying hardware components and requires a custom OS image from the OEM who made the tablet.
Finally, while we cannot support or give out third party peripheral drivers or provide the Android 3.0 source before Google does, we do want to explore whether we can assist the open source ROM makers. We will be reaching out to them today.
UPDATE 5/10/11 - There is now a pretty hacked together port of HC that has been ported to the gTablet - it is a mashup of other, authorized by Google tablets which have stock HC on them, and thrown together for Vega, Adam and gTablet. A lot doesn't work; it is not feature perfect..... it is only recommended for testing type users who are familiar with nvflash etc. and it is not built from source specifically for our devices. It is by no means official, nor is it what would probably be called "stable" - but it is as close as we've come to HC on the gTablet. Here is the post that has more information: http://forum.xda-developers.com/showthread.php?t=1065220
UPDATE 5/10/11 - Per Google I/O's Fireside chat today there will be no Honeycomb source released. Ever. You'll have to wait for Ice Cream Sandwich which will be out in Q4 2011.
UPDATE 5/14/11 - The ADAM/VEGA/ZPAD/GTAB port of the mashup Transformer/Iconia/Xoom Honeycomb systems is coming along nicely. See the above thread for more information. Good work to the devs involved in that project.
Quoted from Engadget:
The latest refresh of the Linux kernel, 3.3, is now available, and the second release of 2012 brings with it the long-awaited merging of code from Google's little side project. While that is particularly interesting to developers looking to boot Android or run apps on the stock Linux kernel (FYI: optimized power management and other infrastructure that didn't make it this time will arrive in the next release, 3.4) and represents a resolution to the issues that kept the two apart for so long it's not the only new feature included. There are improvements to file systems like Btrfs, memory management, networking, security and much, much more. Hit the source link below for the full changelog or grab the code and from the usual locations and get your compile on directly.
Source: Engadget, Kernel Newbies, LKML.org
Any devs interested in developing a kernel based on this?
Based on what I read, this release would make it easier for us to compile the kernel as it brings merged Android code.
To me I'm thinking Google will Roll this out to the Nexus Line Up on the Next OTA... Perhaps the delay for the Nexus S if Due To This?
- Google
nice I hope so
iGoogleNexus said:
To me I'm thinking Google will Roll this out to the Nexus Line Up on the Next OTA... Perhaps the delay for the Nexus S if Due To This?
- Google
Click to expand...
Click to collapse
I doubt this is due to any delays regarding ota update, AFAIK, the Android devs at Google have all their own modules etc that they roll in to an update etc. This should however make projects like Ubuntu on Android etc easier.
Sent from my A500 using xda premium
glennkaonang said:
Quoted from Engadget:
The latest refresh of the Linux kernel, 3.3, is now available, and the second release of 2012 brings with it the long-awaited merging of code from Google's little side project. While that is particularly interesting to developers looking to boot Android or run apps on the stock Linux kernel (FYI: optimized power management and other infrastructure that didn't make it this time will arrive in the next release, 3.4) and represents a resolution to the issues that kept the two apart for so long it's not the only new feature included. There are improvements to file systems like Btrfs, memory management, networking, security and much, much more. Hit the source link below for the full changelog or grab the code and from the usual locations and get your compile on directly.
Source: Engadget, Kernel Newbies, LKML.org
Any devs interested in developing a kernel based on this?
Based on what I read, this release would make it easier for us to compile the kernel as it brings merged Android code.
Click to expand...
Click to collapse
I have been porting Samsung drivers for Nexus S for some time till Linux 3.3 RC3..
Sorry, no fully working results yet due to many code improvements..
But the work is in progress.. I'll also try to write so Samsung to get the info about their plans and/or the results of porting this code to 3.3
novic_dev said:
I have been porting Samsung drivers for Nexus S for some time till Linux 3.3 RC3..
Sorry, no fully working results yet due to many code improvements..
But the work is in progress.. I'll also try to write so Samsung to get the info about their plans and/or the results of porting this code to 3.3
Click to expand...
Click to collapse
Thanks for your hard work, man.
Anyway, after some readings, I think it's better for us to wait until 3.4 is released.
It is said that 3.4 will finish all the Android code merging process, with many fixes of course.
I'm no dev at all, so this is just a plain opinion from somewhat avid Android user
Sent from my Nexus S using xda premium
Cool
"Today we are excited to announce Tizen 1.0 Larkspur, including the addition of new complimentary components, as well as source code that focuses on enhancing stability and performance. We believe that these updates and new offerings improve the experience for developers. We are also continuing to work on improvements and additions, and we will be doing frequent updates to the SDK and source code. There are a few additional components that we plan to add in the coming weeks, and we will continue to fix bugs and add additional features."
https://www.tizen.org/blogs/tsg/2012/tizen-1.0-larkspur
hi devs, start tizen os porting android device example galaxy s
https://www.youtube.com/watch?v=cg9gaGKrJyk
Just noticed this in my Youtube suggestion box.
And more info is obtained here: http://developer.sonymobile.com/201...-xperia-devices-in-sonys-open-device-program/
the modem and camera are not implemented.
no modem is kind of a deal breaker for actual use.. but it's cool to see them do this.
It's also, I believe, missing a number of features in the official M developer preview.
The issue is that Google does NOT publish full source to AOSP for developer previews. For L, the dev preview source release consisted of GPL components only - the L-preview tags/branches for all other repos were just the current state of AOSP Master at the time or identical to the latest KK tag.
Apparently Google released more for M dev preview, but it's still not complete. (IMO Sony probably was too aggressive with releasing these previews because they're half-baked for the reasons stated above...)
GrapheneOS has this nice new feature called Sandboxed Play services which basically allows to run google play services as unprivileged apps. To make this possible, they built a compatibility layer.
For testing purposes I already merged necessary commits and created patches for LOS. As I'm not going to publicly release any builds, I've already posted a guide so that any rom builder can easily integrate the gms compatibility layer in their rom (not necessarily lineageos).
But, I'd love to see this in LineageOS officially. In a comment on reddit it sounds like the main problem is that the feature violates the Android Compatible Device Document. However, after looking at the source code of the compatibility layer, it seems like the layer could easily be implemented without violating anything. In fact, the gmscompat layer was implemented as a compatibility change to reuse the existing compatibility change infrastructure. It is a special implementation though, and automatically get's activated for GMS apps only (see these two patches).
My thinking is, if the compat change isn't activated on its own for GMS apps, but additionally relies on a checkbox (disabled by default) in the system menu, that wouldn't violate anything, because the default behaviour isn't tampered with at all. And as soon as the user enables the compatibility layer with the help of the aforementioned system menu setting, Google play services can be run in a sandbox.
What do you think?
I had inquired with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago
> I had a with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago
You can check the commits here: https://gist.github.com/thestinger/ee536cbd1ca674b94dde05831192c348#comments
Wait, that's all the commits needed?
PiXinCreate said:
> I had inquired with the graphene devs about 2 or 3 weeks ago and they couldn't even tell me all of the repos I had to cherry pick the 100+ commits from....thanks for this. I've been putting off integrating this into my LOS ROM since I started developing it almost a month ago
You can check the commits here: https://gist.github.com/thestinger/ee536cbd1ca674b94dde05831192c348#comments
Click to expand...
Click to collapse
Thanks so much for that. Seriously. I FINALLY have Sandboxed Play Services working.
It's a Lineage 19.1 rom
Glad to know about that!
I'm new to all these ROM development stuffs. I'd be helpful if you publish your work on GitHub with a build documentation.. (optional, you can decline my request).
As the dev already has confirmed that former (GMS_Sandbox) is ROM independent, I personally feel like making a Magisk Module for that, which will be systemless and optimal.
Yeah, I surely will upload my sources. It's just so monotonous creating each repo one by one and adding remotes lol I've been putting it off.
Getting it working with that gist was very easy though, most every commit auto-merged.
But yeah, I'll upload those sources and post back here when they are up.
( I am new as well btw, I just got started about a month ago)
EDIT: SOURCES
From what I read the Lineage OS developers don't seem very cooperative, at least on this front (see LineageOS for microG).
A Magisk module would be amazing. It would also make the work I just did to compile Lineage obsolete
Do you already have a technical approach for such a module? Would you just replace the files that have been changed? How concrete are your plans to make it?
Sewdohe said:
Thanks so much for that. Seriously. I FINALLY have Sandboxed Play Services working.
It's a Lineage 19.1 rom
Click to expand...
Click to collapse
u have sandboxed Google's for lineageos 19.1?
can u explain how u got it done?
Thanks