This guide tries to explain very briefly the different types of CyanogenMod builds, particularly for the Sony Xperia devices, and what usage each type may be suitable for. The guide is oriented towards newcomers, who often find themselves wondering what are the differences between these various builds (don't worry, I used to be perplexed myself) and which one would serve them better. Anyone seeking further information is well advised to check the CyanogenMod wiki or search around the forums here.
The nightlies are regular automatic builds* of the CM source. Because changes get constantly pushed to the CM source from various developers, these builds reflect a more or less random state of the code, and because there's no human intervention in deciding whether to build or not, the nightlies can contain random bugs. Actually, the larger and most severe bugs are typically filtered out by the preliminary testing and review process before they even get committed, but it's impossible to catch everything that way. Indeed, the nightlies' primary purpose is just to make sure that the code still builds correctly. Nevertheless, they are also a rather useful tool for large-scale testing -- and that's how these not-so-huge bugs get caught as well.
The more substantial changes or the ones that could possibly break a lot of things (or few things really bad) get tested separately, with the experimental builds, before they are committed to the CM source.
The stable builds are based on a snapshot of the source code that is deemed suitable enough for everyday use. They are expected to be free of any serious bugs. By the way, a "snapshot" is just what it sounds like: a momentary picture of the code at some specific point of time, as decided by of the developer(s) who oversee the project development. In technical terms, the snapshot is a Git tag.
When a stable release is planned, the commits are gradually restricted to only the ones that fix things; the ones that "merely" introduce new functionality (which potentially means new bugs) are postponed until after the release (in developer terms, the code is "frozen"). In this process, the code gets several preliminary snapshots, namely, the release candidates (or RC), which reflect the advancements in the code stabilization and bug fixing. In other words, each new RC should have more and more of the identified issues ironed out, until all of them eventually get fixed, at which point the stable version is finally released (hence why an RC is just a "candidate").
The FXP builds are manual builds of the CM code with patches by the FreeXperia project. FreeXperia is the core group of developers who, with the help from other skilled developers from XDA and CM, maintain the Sony Xperia line of devices for CyanogenMod. This means that (an often asked question) most of these patches get promptly committed to the general CM source. The only exception might be changes that turned out to behave badly. In other words, any fixes or new features in the FXP builds very soon get included in the CM nightlies as well. Unlike the CM nightlies, however, the FXP builds are manual, so they are expected to be more stable: whether because the current code has been confirmed as stable enough, or because particularly problematic one has been patched. Thus, they might be considered the equivalent of the CM milestone (or M) releases.
IMPORTANT: Whichever type of build you choose, always keep current enough backups, preferably of different types (e.g. a nandroid/CWM/TWRP and a Titanium/etc. one) and in different physical locations (in particular, keeping your backups only on your SD card is asking for trouble). Keeping several chronological versions is a wise practice as well (you might, for instance, find your last and only backup to be corrupt). Remember that you can never have too many backups!
Which version should I use if I...
TBA
This guide started as a post in another thread, and I'd like to thank @tilal6991 for confirming what had been only assumptions then. All your recommendations, whether to fix mistakes or to enhance the guide, or even just comments, will of course be very welcome.
----
*) The current list of the automatically built targets, together with the frequency of the builds, is here.
Changelog
----------------
12 Sep 2013 - Initial version.
Note to the mods: I'm afraid I couldn't think of better forum for this short guide. It is relevant to more than just the Xperia T, yet perhaps not that helpful beyond the Sony devices, as the major source of confusion seems to be the FXP builds (and these, of course, are Sony specific). If you do have a better idea, please don't hesitate to move the thread -- and thanks a lot in advance.
Note about "Which version should I use if I...": I'll try to fill that one in as soon as possible, but I got some serious problems at home, so it may actually take a while. Sorry about that.
Guide moved to general...
Nice guide Btw
Sent from mALL GLORY TO THE HYPNOTOAD!!
Related
Not trying to be a troll - I'm looking for some insight.
It appears to me that there is a degree of inefficiency with the progress of the Camera updates being made on the HP TouchPad. Those updates are on a static and aged build of CM9.
What does it take to have the code/ROM updates for the working camera ported over to the more recent builds of CM9 and CM10?
I know the inside joke/anti-troll repellant response of "two weeks" or "soon" are out there. That's not what I'm looking for. I'm really trying to understand why devs would continue to leave these advancements off of the more recent/enhanced builds?
Is the answer really just that the single dev (or team) wants a static version to perfect the driver so it doesn't have to keep "changing the wheel on a moving car"?
--McBean
McBeanTIO said:
Not trying to be a troll - I'm looking for some insight.
It appears to me that there is a degree of inefficiency with the progress of the Camera updates being made on the HP TouchPad. Those updates are on a static and aged build of CM9.
What does it take to have the code/ROM updates for the working camera ported over to the more recent builds of CM9 and CM10?
I know the inside joke/anti-troll repellant response of "two weeks" or "soon" are out there. That's not what I'm looking for. I'm really trying to understand why devs would continue to leave these advancements off of the more recent/enhanced builds?
Is the answer really just that the single dev (or team) wants a static version to perfect the driver so it doesn't have to keep "changing the wheel on a moving car"?
--McBean
Click to expand...
Click to collapse
Dorregaray explained it in a RootzWiki post: http://rootzwiki.com/topic/16347-de...hw-acceleration-fix/page__st__170#entry965452. I think changes have been made to upstream CM9 that make inclusion of the camera fixes more complicated.
bananagranola said:
Dorregaray explained it in a RootzWiki post: http://rootzwiki.com/topic/16347-de...hw-acceleration-fix/page__st__170#entry965452. I think changes have been made to upstream CM9 that make inclusion of the camera fixes more complicated.
Click to expand...
Click to collapse
the new code for the camera is simply not commited to the CM9 repo at the moment. It is awaiting approval by someone who can review the code. However, it is possible to "Cherry Pick" the code updates into a new build. I was doing exactly that this morning, with some difficulty, and did not end up with a better product than what is currently available, ie. blue screen on boot sometimes...
-SGA- said:
the new code for the camera is simply not commited to the CM9 repo at the moment. It is awaiting approval by someone who can review the code. However, it is possible to "Cherry Pick" the code updates into a new build. I was doing exactly that this morning, with some difficulty, and did not end up with a better product than what is currently available, ie. blue screen on boot sometimes...
Click to expand...
Click to collapse
Ooh. Good to know. I had thought that there were changes that needed to be made to existing CM before the camera stuff would be compatible with it. The fact that it's all ready to go is excellent news!
bananagranola said:
Ooh. Good to know. I had thought that there were changes that needed to be made to existing CM before the camera stuff would be compatible with it. The fact that it's all ready to go is excellent news!
Click to expand...
Click to collapse
Yes, it seems like most of the fixes that needed to be made for the memory split have been implemented in theory. However, I imagine the blue screen issue would need to be solved before the code is merged into CM9, as it makes it less than stable. Be it as it might, I think we would still do fine with unofficial CM9 camera builds if the code is never merged at all.
In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
nicholaschw said:
In due for our major rollout event, ARM. Project will be coming to your mako. We are an non-profit organisation alike cyanogenmod, but only focusing on creating a global aftermarket kernel for the Android OS, specifically to remove the major setbacks of linux.
What's so awesome about the kernel apart from stock manufactured vanilla kernels?
- this includes custom codes which are open-sourced, which aims to tweak the linux kernel to the peak for Android. This gives you a feeling like having Android and, at the same time, feel like you have the smoothness like ChromeOS.
What's in the codes you add?
- they are just codes ported over from other lightweight open-source OS, but, will also include our own various inspirations.
Currently, we are in closed development for mako. We are in need of 2 Maintainers for source building and basic bugfixes and 2 testers for alpha testing. Please PM me to discuss on.
We hope to help shape your phone's future!
Click to expand...
Click to collapse
Can't wait to see how this turns out
Let's just say the release is near!
First few versions will not include features as it will be more of a build clean fix.
Features will come in time by time.
DO NOT report bugs in the development thread. Report it here with the following info:
- Logcat
- dmesg
- A brief description of what happened.
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
SecUpwN said:
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
Click to expand...
Click to collapse
A few of us are interested in this and we'll see what can be done
BytecodeMe said:
A few of us are interested in this and we'll see what can be done
Click to expand...
Click to collapse
Awesome! What are you planning to do?
SecUpwN said:
Dear Developers of AOKP,
first of all: Thank you so much for this awesome ROM which I am using since 3 years by now! Since security has been in the media periodically for quite some time now, I feel like this is the right time to ask: Would you please harden AOKP to include the very latest security enhancements? What bothers me in particular is that it seems even though so much development is being done, vulnerabilities like Mempodroid still seem to be present in the latest builds (using AOKP 4.4.2 for M7UL). A good way to check this is to use the X-RAY Security Scanner. Please fix these vulnerabilities.
Furthermore, would you please implement a feature to toggle hardening like triggered with the app SecDroid? This neat little project unfortunately has been abandoned, but yet the idea should be clear. The developer of SecDroid also released a Guide on how to harden Android. Maybe AOKP can use the Source of SecDroid somehow?
For me, AOKP always will be the best ROM out there. I can proudly say that having donated to the project makes me feel great and I'm looking foward to see AOKP implementing the latest and greatest security enhancements out there. Thank you ahead!
Click to expand...
Click to collapse
Even if every vulnerability fix was included in source, (for now) it will still not be secured. Unless you compile your own builds with a different platform key, your builds will not be secure. This applies to nearly every AOSP-based custom ROM.
We've talked about it, and we might implement something for milestone releases. But security is a huge huge problem to take on with custom ROMs and there are a lot of heads to the dragon to take down
Sent from my HTC One using Tapatalk
Romanbb said:
We've talked about it, and we might implement something for milestone releases. But security is a huge huge problem to take on with custom ROMs and there are a lot of heads to the dragon to take down.
Click to expand...
Click to collapse
True point. But I'm sure that folks who can add unicorn sparkles to a ROM will even discover and implement some really cool security enhancements & fixes for the already known vulnerabilities. After all, this is a suggestion and to be seen without pressure. Waiting for your next awesome release for M7UL, @Romanbb! You're doing a great job!
SecUpwN said:
True point. But I'm sure that folks who can add unicorn sparkles to a ROM will even discover and implement some really cool security enhancements & fixes for vulnerabilities. After all, this is a suggestion and to be seen without pressure. Waiting for your next awesome release for M7UL, @Romanbb!
Click to expand...
Click to collapse
For sure. I'm definitely not against security enhancements by any measure.
Why isn't it possible to create a tool that can repackage ROMs with custom keys, say, using a Windows computer or Xposed Framework?
Also, isn't Mempodroid what allows us to give apps SU permission?
pan.droid said:
Also, isn't Mempodroid what allows us to give apps SU permission?
Click to expand...
Click to collapse
No. Mempodroid is an EXPLOIT and a vulnerability, please don't mistaken it with SuperSU.
SecUpwN said:
please don't mistaken it with SuperSU.
Click to expand...
Click to collapse
Okay. Just so long as you don't *mistake* 'SU' with SuperSU=)
AOKP Kitkat Rom
The Android Open Kang Project (AOKP) team has released nightly builds for a number of Android running device which bring Android 4.4.2 KitKat update for these devices. One such build is also available for Sony Xperia Z, which runs Android 4.3 Jelly Bean.
gteknet said:
The Android Open Kang Project (AOKP) team has released nightly builds for a number of Android running device which bring Android 4.4.2 KitKat update for these devices.
Click to expand...
Click to collapse
As you might have guessed, AOKP runs through all my veins. I'd probebly never use anything else, if not forced to. As soon as a new nightly is out, I'm using it. But what exactly is the AOKP team doing to make their build more secure?
One of the features that I'd LOVE to have would be encrypted calls between AOKP builds without having to be online or installing additional software. Would such be possible somehow?
Thread cleaned
I suggest several members use the ignore user option if they want to remain members on XDA
I will be keeping an eye on posting. Cut out the infantile crap or you will be removed
This is a development site, take your garbage to a social media site
Senior Moderator
@kennyglass123, thanks for cleaning it up. I really appreciate your effort. Unfortunately though, no member of the AOKP team has answered my initial question yet. Could someone please do so?
SecUpwN said:
As you might have guessed, AOKP runs through all my veins. I'd probebly never use anything else, if not forced to. As soon as a new nightly is out, I'm using it. But what exactly is the AOKP team doing to make their build more secure?
Click to expand...
Click to collapse
Sadly, this question is still open. Since I'm using M7 (Gerneric GSM), maybe @Whitehawkx can answer this?
In particular, I want to port Omnirom 4.4 to a device which has sources for that particular device available from it's manufacturer's website. Note: the documentation available from the github repo is very sparse and underwritten, particularly in the area of porting and building that port.
4.4 dates back to when I was still active (FYI I have not been active in the development community for 3+ years, kind if just popped in to check things out)
In general, a branch THAT old will not have any support and you likely won't find anyone bothering to code review any submissions. I'm not sure what the current state of the instructions for building for supported devices is.
No project has EVER had significant documentation on porting, because every device is different and the barriers you run into are different every time... It's something that is incredibly time consuming and you learn by doing. It requires general analysis and diagnostics/troubleshooting/problem solving skills. If there were a way to write a step-by-step porting guide - you would see far more devices supported at far higher levels of quality than what you actually see.
What device is this? I'm really surprised that you've found complete AOSP sources from the manufacturer. That's basically unheard of for anything other than Google devices and Sony's AOSP project. If you've merely found a kernel source code drop - congratulations, you've got around 1% of what you need.
Hey I just got this phone a couple of weeks back and while its been awhile I used to be a recognized developer on XDA years ago and was wondering if there are any active developers (still) for this device as I notice the list of active development is basically 0. I am planning on building for the device but would like to know who if anyone is developing currently and what the goals are as it seems without anything outside of stock deodexed and (really the biggest one being the kernel with twrp) we have nothing for this phone even now. This makes it seem like either the proprietary information is extremely difficult (although I see the tree is working for the most part) or we just lack developers. Which is it? Thank you and I apologize if this is in the wrong place. I'd like to see what is the current state of things and see if any developers want to work together on this and at least get a clean aosp build or lineage os build. Stepping stones. Certainly with the Note being as similar as it is this shouldn't be lacking to the state it is today.
Hello jcole20
That would be awesome if some devs started doing something with the RP2! If I had the knowledge, I would!! I've had the RP2 since June of this year. I had some issues with it at first but they have been worked out. I really like the phone and it would be cool to see some devs show the RP2 some love lol. Hopefully you can get something started! Take care!
Dennis
jcole20 said:
Hey I just got this phone a couple of weeks back and while its been awhile I used to be a recognized developer on XDA years ago and was wondering if there are any active developers (still) for this device as I notice the list of active development is basically 0. I am planning on building for the device but would like to know who if anyone is developing currently and what the goals are as it seems without anything outside of stock deodexed and (really the biggest one being the kernel with twrp) we have nothing for this phone even now. This makes it seem like either the proprietary information is extremely difficult (although I see the tree is working for the most part) or we just lack developers. Which is it? Thank you and I apologize if this is in the wrong place. I'd like to see what is the current state of things and see if any developers want to work together on this and at least get a clean aosp build or lineage os build. Stepping stones. Certainly with the Note being as similar as it is this shouldn't be lacking to the state it is today.
Click to expand...
Click to collapse
I am sure people would love to see some device specific development. I have read that since the release of project treble most people just flash the system image from other roms. I specifically would love to see a stockish rom so I don't loose chroma but still get updated security patches.
I ordered this phone from amazon to try out. I am checking out the community and stuff in the 10 day trial period they give you. I really like the phone... i just hate the software side of things. I feel like its super premium hardware with outdated software... that probably isnt even going to get security patches. Anyway... off to see whats available.
Krazy_Calvin said:
I ordered this phone from amazon to try out. I am checking out the community and stuff in the 10 day trial period they give you. I really like the phone... i just hate the software side of things. I feel like its super premium hardware with outdated software... that probably isnt even going to get security patches. Anyway... off to see whats available.
Click to expand...
Click to collapse
Most functionalities work on Pie GSIs out-of-box (you need to manually install ims.apk in order to receive SMS while on LTE, see relevant threads here, or look for it on some GSI threads such as Havoc 2.9). exFAT also works on supported GSI (with arter97's kernel), while it's not supported on stock. The only problems I have so far are bluetooth-related, and also the inability to set SELinux to permissive (not sure which might be the real cause as arter97 stated the SELinux could be permissive).
Bluetooth media audio doesn't work at all on GSI, partly due to the crippling overlays (which prevents aptX from working, and probably some other limitations). Phone calls work with a bluetooth headset, but for some reasons I couldn't properly route phone calls to my Huawei Watch 2 (which means I always have to take the call from my phone directly).
Given the mostly positive result with numerous GSIs (and that some users are happy with stock ROM, or stock-based ROM modifications), active ROM developments for the device itself doesn't seem to be at a high priority (as some might be able to contribute patches for this device to their favorite GSI instead)...
I'm currently working on my own build of LOS. I haven't seen to much active development either I'm new to rom building but looks like we could use all the help we can get!
I think the only active dev we have for this phone is Arter97's kernel and people tinkering with GSIs to get them working as they should. I wish there was more being done with the stock ROM because I like a lot of it's features, but am having a hard time dealing with it's overall instability. I'd be happy to help develop or test in whatever way I can, though.
jcole20 said:
Hey I just got this phone a couple of weeks back and while its been awhile I used to be a recognized developer on XDA years ago and was wondering if there are any active developers (still) for this device as I notice the list of active development is basically 0. I am planning on building for the device but would like to know who if anyone is developing currently and what the goals are as it seems without anything outside of stock deodexed and (really the biggest one being the kernel with twrp) we have nothing for this phone even now. This makes it seem like either the proprietary information is extremely difficult (although I see the tree is working for the most part) or we just lack developers. Which is it? Thank you and I apologize if this is in the wrong place. I'd like to see what is the current state of things and see if any developers want to work together on this and at least get a clean aosp build or lineage os build. Stepping stones. Certainly with the Note being as similar as it is this shouldn't be lacking to the state it is today.
Click to expand...
Click to collapse
Yeah, it’s definitely just total lack of interest from other devs. We even have a guy with a prototype Razer Phone 2 with an intact DRM partition and unlocked bootloader (Allowing Netflix HD and Vudu HDX) but we couldn’t even pay anyone to try to port it.
I think if we had a fully working AOSP tree that it would possibly bring other devs into the scene. Who knows though, it has never been a popular device despite how great it is.
LSS4181 said:
Most functionalities work on Pie GSIs out-of-box.
Click to expand...
Click to collapse
Noob question:
Do we have to wait for a stock Android 10 for the device to be able to flash Android 10 GSIs?
EMJI79 said:
Noob question:
Do we have to wait for a stock Android 10 for the device to be able to flash Android 10 GSIs?
Click to expand...
Click to collapse
A stock Android 10 (which means a stock vendor image for Android 10) is not necessarily required to have a usable Android 10 ROM (though it may speed up the development to some extent, if it does have one), but for GSI, having a stock Android 10 vendor image can be better (currently it's a hit-or-miss on existing Android 10 GSIs).
Another device that I have, Google Pixel C, never had stock Android 9 (so never had stock vendor images for Android 9, only for up to Android 8.1), but custom Android 9 ROMs are already available (thanks to followmsi's efforts) and are working well. For Android 9 ROMs, the build system builds new vendor images along with system image.
It's just whether we're going to see our device's trees being made possible, so we can start from there to develop our own custom ROMs. The existing materials might be a good starting point in making trees.
- Working with proprietary blobs (from Lineage)
- arter97's kernel (can be useful for making a kernel tree, though one can also consider using stock kernel source as a base)
- Razer factory images and kernel sources (for studying stock ROM/kernel details, and extracting necessary system and vendor blobs)
If you can port LineageOS to this device, great!
I don't understand why people aren't flocking to this device. I came from the LG G6 that probably will be stuck on Oreo forever that is way more popular. The RP2 is cheap, has killer specs + a micro SD card slot + a newer version of Android. Should be a developers dream, you would think. *shrug*
Not sure if anyone's active on this device at present. With RP2's 9.0 MR2 available on the official factory images page the latest proprietary blobs (as well as stock kernel source) are now publicly accessible.
Actually arter97 once mentioned that his RP2 kernel is almost inline with his OP6 kernel (which is also sdm845 and shares some similarities), so it's possible that OP6 (enchilada) trees may be a good starting point, but I'm not sure if any configurations are needed to keep 120Hz working as high refresh rate is relatively uncommon.
My time is very limited so I won't be able to dedicate too much time to experiment on this. At present most functionalities work fine with GSI (including Bluetooth, although tricky and aptX still not working).
IDK how relevant this is anymore but as a new razor phone 2 user to be soon I have been keeping up and it seems that @f(x)THaxxorX could be a possible candidate of what you're looking for I've been keeping up with development on the phone seems like he is doing pretty well even if we get patched gsi which properly work is better than nothing.