Database Develop

[Q] Is gingerbread(Android 2.3) coming to the Galaxy S I9000?

Roms based on froyo or gingerbread?
The discussion in the thread "30/Jun r1 (JFB) - MoDaCo Custom ROM for Samsung Galaxy S with Online Kitchen" is a bit confusing so I thought it best to make it a new topic to get it straight.
Will it be possible to make roms based on froyo, gingerbread or any other coming android version, before Samsung makes an update? As I understand psychoace it will be ”near impossible to get roms from other sources like Sense roms or Froyo”. Others are not so sure.
This is important as Samsung is known for its lack of interest in OS updates. Who knows if they will take gingerbread to GS? If they won't can it be done by the really smart guys?

I don't think even HTC will update there top line to V3 (ginger bread). Froyo is coming any way to GS in near future. Now ginger bread should be possible too as GS is power full enough to run. When? we should wait and see. Nexus just got updated to 2.2.
Will see how things go in future.

Samsung has released there kernel sources and there software sources. I haven't had a chance to look in to it deeply but if it has the code of the drivers etc.. it should be possible to merge (with some work obviously) sources and to compile froyo.

kimatrix said:
Samsung has released there kernel sources and there software sources. I haven't had a chance to look in to it deeply but if it has the code of the drivers etc.. it should be possible to merge (with some work obviously) sources and to compile froyo.
Click to expand...
Click to collapse
But don't those drivers only work with 2.1 and just simply won't with any version higher unless samsung releases new source and drivers for 2.2 and then 3.0. So if say samsung never releases anything any source/drivers that work with 3.0 then you would be out of luck to actually get everything to work.

MrDSL said:
But don't those drivers only work with 2.1 and just simply won't with any version higher unless samsung releases new source and drivers for 2.2 and then 3.0. So if say samsung never releases anything any source/drivers that work with 3.0 then you would be out of luck to actually get everything to work.
Click to expand...
Click to collapse
That is true but if you have the full sources you are able to look what the differences are and maybe patch those by your self. Assume a wlan driver is using an function that has changed or is gone in 2.2, then you can try to patch that by finding the new one for it to work with. If you don't have the sources it's much harder to do those kind of things.
As I sad you have the sources so you can play by your self even if samsung does not do anything. It does not mean it's easy and it does not mean it can be done fast. But it does mean it could be done.

kimatrix said:
That is true but if you have the full sources you are able to look what the differences are and maybe patch those by your self. Assume a wlan driver is using an function that has changed or is gone in 2.2, then you can try to patch that by finding the new one for it to work with. If you don't have the sources it's much harder to do those kind of things.
As I sad you have the sources so you can play by your self even if samsung does not do anything. It does not mean it's easy and it does not mean it can be done fast. But it does mean it could be done.
Click to expand...
Click to collapse
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.

psychoace said:
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.
Click to expand...
Click to collapse
Can they be decompiled and made to work? Of course!
Will someone be motivated to do all this work? Unknown.
Besides drivers arent the only issue to getting a new version of Android on a phone. If you dont have source for any proprietary userland daemons/apps (like radio?) that communicate with the hardware you will be SOL on that as well.

MMMMMMMMM if we can do it for the G1 we can do it SGS...the question is when and how much work. The Galaxy S will be Samsung's flagship device for A YEAR so I'd hope to get Gingerbread...unless Samsung are really stupid. Especially with a lot of US launches, they'll be able to relaunch with Gingerbread as it comes is my hope.

psychoace said:
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.
Click to expand...
Click to collapse
Who told you that??? The source code of the GPU as well as every other coprocessor is there.
The two .o file that started this all fiasco are ok and you as long as the make file include them in the build they would work perfectly.
All they have inside is a simple elf code to tell the s3c*** to do whatever it needs to do. A source code wouldn't have been beneficial as it would have to be compiled differently for a different ARM instruction set .

kitsune223 said:
Who told you that??? The source code of the GPU as well as every other coprocessor is there.
The two .o file that started this all fiasco are ok and you as long as the make file include them in the build they would work perfectly.
All they have inside is a simple elf code to tell the s3c*** to do whatever it needs to do. A source code wouldn't have been beneficial as it would have to be compiled differently for a different ARM instruction set .
Click to expand...
Click to collapse
But when you need drivers for 2.2 the source code would be optimal because these drivers are not going to work without some hacking.

They are going to work as they are non kernel bound ELF files.
Guys this isn't a driver ,if it was a kernel module ( or "driver" s you call it) it would have been a .ko file and had a slightly different structure ( use readelf on a kernel module and then on this to see the difference). So no matter what it is when can use the compiled version as it not kernel bound
From quick inspection it seems like the injection code for the s3c*** . so basically its there so the kernel could reference to it when the code tells it to do so . So Basicly all we have to do is put it in the proper place when building the kerne.
So please DON'T PANIC

well the TP2 just got 2.2 FroYo (2.1 has more working drivers ATM).. but if we have it, how would it be different for the SGS to get FroYo?

You need to remember that while other companies can update kernel quite easily ( all the work is done for them by the chip manufacturer and some member of the community ) this isn't possible here as this is a chip only used in one android/other linux platform device and the company making the device also make the chip.
So give them a few weeks to work on it

J-Hop2o6 said:
well the TP2 just got 2.2 FroYo (2.1 has more working drivers ATM).. but if we have it, how would it be different for the SGS to get FroYo?
Click to expand...
Click to collapse
let's just say it will be the first time a non Samsung Rom has worked on a Samsung Android phone.

psychoace said:
let's just say it will be the first time a non Samsung Rom has worked on a Samsung Android phone.
Click to expand...
Click to collapse
Not true.
Look here: http://forum.samdroid.net/f28/lkmod-v-2-5-1-based-jce-en-upd-03-30-a-336/
I see a custom ROM made for the i5700
Everything is possible.

clubtech said:
Not true.
Look here: http://forum.samdroid.net/f28/lkmod-v-2-5-1-based-jce-en-upd-03-30-a-336/
I see a custom ROM made for the i5700
Everything is possible.
Click to expand...
Click to collapse
Did I say custom rom? No i said specifically non samsung based roms on a samsung device. That custom rom is based off of a Samsung rom.

This is the closest we have got to a Hero rom on a Samsung device.
http://androidforums.com/all-things-root-behold-2/60408-port-htc-hero-behold-2-wip.html
He couldn't get Rosie to boot so who knows what other problems he would of had after that (from the picture you can see he never got any network connection)
So there don't say I didn't give you any hope.

Froyo is offical. That's good, but we need to be looking past it to Gingerbread.
Froyo is announcedm confirmed, and now dated for the end of September, and that's great. But to me, that's not the question we need to be asking Samsung anymore, we need to be thinking past that.
The question people need to be asking Samsung, so we can get them on the record committed to it now, is will you release a Gingerbread update for the phone as long as the hardware is capable of supporting it. The OS is only 2-3 months from being unveiled if Google sticks to their time table, and if the rumors are true it'll be a much bigger overhaul than 2.1-2.2 is.
So unless we want our phones to be outdated before the end of the year, we need to start making a push as a community to get a commitment from Samsung to support not just the OS that was released 4 months ago, but also the much bigger one that's right around the corner.

2.2 is good.. proves everyone wrong who said "ooh its Samsung, of course they won't release Froyo."
but somehow, I doubt that samsung will somehow not upgrade SGS to 3.0. If they do, it might be a few months (at least) after everyone else gets it. The reason is, they could have new flagship devices out that they wanna push to the mass-markets, so putting gingerbread on that will boost the sales.
However, considering that they marketed the SGS so well, and have it well on its way, they might just put gingerbread on it
seriously, i see ads for SGS EVERYWHERE online.

mjgunn said:
[....]
So unless we want our phones to be outdated before the end of the year
[....]
Click to expand...
Click to collapse
I totally expect that my phone will be outdated by then. That's a consequence of the world we live in But then again, i'm a nihilist

[INFO] Android 4.3 JSS15J&JSS15Q vs. JWR66V&JWR66Y, Custom Kernels and Graphic Issues

[INFO] Android 4.3 JSS15J&JSS15Q vs. JWR66V&JWR66Y, Custom Kernels and Graphic Issues
So, since this issue pops up often in various threads ever since 4.3 was released, I thought I'd make a thread I could point people to instead of repeating the same explanation over and over.
This has been discussed greatly in various Kernel/ROM development threads and I've been even getting PM's about it so I'll try explaining everything here. Most info is taken from discussions made on CyanogenMod-related threads, Franco kernel thread, thracemerin's WiFi-fix thread, and Google-related sources, so thanks also goes to everyone who participated.
On to business...
Background:
When Google released Android 4.3, it came in a few forms. One is the familiar OTA update zip and factory images. This is what people refer to as 'stock'. The build number for that stock release is JWR66V, also known as Android 4.3r1. This was later updated to JWR66Y (Android 4.3r1.1).
As you all know, Android is open source, which leads us to the Android Open Source Project (AOSP). This is where the source for Android located, and one could build the operating system/kernel (with provided drivers) from scratch and make a working flashable operating system. This is also the 'base' for custom ROMs.
AOSP has newer android revisions - Android 4.3r2.1, build number JSS15J, and Android 4.3r2.2, build number JSS15Q. These builds are newer than 'stock' JWR66V/JWR66Y, but they are official, are made by Google, and are available for anyone to build from scratch, just like JWR66V/JWR66Y. The differences are Google Apps, such as Google+, YouTube, Gmail, etc, which will not be included in an AOSP build, but could be downloaded from the store (or available as a flashable zip) anyway. AOSP also has a different browser while 'stock' comes with Google Chrome (which you could manually download if you wanted to). The system itself is still the same Android. If one decides to build Android from the older JWR66V/JWR66Y revisions, they will have the same system as someone else who flashed stock.
Why didn't Google release JSS15J as stock?
A Google employee mistakenly thought that JSS15J only has changes related exclusively to the new Nexus 7 device. He later apologized and acknowledged his mistake. JSS15J has an updated Nexus 4 kernel with dozens of GPU commits/improvements.
Which build is better?
Depending on who you ask. If newer is better, JSS15Q is better. If factory images are better, JWR66Y is better.
Which build should I use?
People who like factory images will stay with factory images. People who like the stock experience but care less about "factory images" could use a clean non-customized JSS15Q build. In a way, JSS15Q could be considered 'stock AOSP' if it's not customized. It's even more minimalistic than what comes with the factory images, because applications such as Google Keep/Earth/Maps and so on are not forced as system apps, and can be optionally installed from the store only if you want them.
Any other differences besides the updated kernel/GPU commits?
Most changes are under-the-hood. There was an updated network setting found in JSS15J/Q that doesn't exist in JWR66V/Y.
I heard something about a Wi-Fi change though?
There is indeed a major difference related to Wi-Fi. I won't get into many details here as there is a dedicated thread with months of discussions, but in short, JWR66V & JWR66Y still have the Wi-Fi notification delay issue that 4.2.2 had. This is because Google turned off ARP offloading for those builds, but later turned it on in JSS15J & JSS15Q. It was also on in JWR66N, the leaked unofficial build that we got prior to the official release.
If Google were to build a new factory images now from JSS15Q, it would have ARP offloading on, and Wi-Fi notification delays fixed. The change is only to an .ini file and the drivers are the same, so while a fix is needed for JWR66V/JWR66Y, it's a simpler fix. If you use JSS15Q you don't have to flash any Wi-Fi fixes at all.
What does this mean for Custom ROMs?
Custom ROMs are usually synced with the latest AOSP revisions and changes. CyanogenMod's Android build is JSS15Q, and the same goes for rasbeanjelly, Carbon, and most custom ROMs. Clean or clean-ish JSS15Q AOSP builds are also available for those who still want both the newest revision and the stock experience, just check the development threads.
HELP! My screen is stuttering and/or has weird green colors and/or doesn't respond properly to touch and/or is yelling at me!
That is mostly why this thread was needed. As mentioned before, JSS15J&JSS15Q have an updated kernel with some GPU fixes. This means that your kernel MUST match your ROM for the issue to go away. There are workarounds, such as disabling hardware overlays, but that is not really a solution. No hardware overlays = reduced performance and possibly other issues.
The basic rule is this:
If you use JWR66V/JWR66Y, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JWR sources.
If you use JSS15J/JSS15Q, either stay with its stock kernel, or MAKE SURE the custom kernel you flash was based on JSS sources.
This is of course a headache for kernel developers, as they need to either drop support for one version, or release two versions each time. Many kernel developers are already offering two version of their kernels - one for JWR-based builds and one for JSS-builds.
This means that if you use the AOSP build or most custom ROMs, you will have the screen issues if you use JWR-based kernels.
So there you have it. Unless some other solution is found, there will have to be 2 kernels - one for each build.

Well done
Wayne Tech Nexus

Anyone have links to a pure AOSP build with literally no alterations?
Sent from my Nexus 4 using Tapatalk 4 Beta

jaju123 said:
Anyone have links to a pure AOSP build with literally no alterations?
Click to expand...
Click to collapse
There are two I know of, they do have some very slight changes you could read about in their threads, I don't know of one with literally zero alterations whatsoever, but again the changes are very minor:
[ROM][JSS15J] aosp 4.3 for Nexus 4
[ROM][28/07/2013] AOSP JSS15J KALO v3.0

Cheers for the clear up, was doing my head in with all the weird builds
Sent from my Nexus 4 using Tapatalk 4 Beta

Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.

redsmith said:
Is there any way we can (nicely) ask Google to release a factory image from the JSS build? I think that would be the perfect solution, and I don't think it is really too hard for them to push it.
Click to expand...
Click to collapse
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.

They won't release new factory images...
Jean-Baptiste Queru said so...
He said both branchs are the same with the only difference in JSS15J being the new stuff for Nexus 7...
The new GPU commits are from the other branch... So that both matchs and don't give tearing effects or other problems...
Enviado do meu Nexus 4

He had some update statements since. Here they are:
In theory, JSS15J should work just as well as JWR66V for the existing devices. In practice, I expect that there could be minor differences (except for the new Nexus 7 where there are big differences), so if you're targeting a single device you might as well use the source code that matches the retail version the most. Personally, I like to live more on the bleeding edge, so when I carry an AOSP device I'm more likely to be running the master branch.
Click to expand...
Click to collapse
Here's an long-ish explanation of what happened:
-For a number of reasons, the kernel is built separately from the Android tree. We submit binaries of the kernel in the Android tree.
-Those binaries are large. In Google's internal tree, there are 1.5GB of Nexus 4 kernel binaries. With the way our tools work, that's 1.5GB of data that needs to be downloaded and stored by each user in each source tree. At the same time, the binaries don't have any significant value, since the value is in the source history, which is stored separately.
-To avoid making every AOSP user download gigabytes of unnecessary kernel binaries, starting with Nexus 4 (and now also in the new Nexus 7), we've been storing kernel binaries in dedicated projects, and I maintain a parallel history for AOSP that only contains the binaries that are necessary. Right now for Nexus 4, that tree is 31MB (to compare to 1.5GB).
-The retail release process of a new version is actually different for existing devices and for the new Nexus 7. To better reflect that, they each got their release branch, with existing devices in the JW branch (jb-mr2-release) and the new Nexus 7 in the JS branch (jb-mr2.0-release). JW entered final stabilization earlier than JS, which means that the jb-mr2-dev branch and the master branch in AOSP are closer to JS than to JW.
-To save space in the AOSP kernel projects, I try to have as few kernel binaries as possible in there, which means that I prepare those branches at the last minute (in this case I did that on Monday). During testing, I don't stage those projects and I manually use kernels directly from the development branches. For Nexus 4, when I did the final staging on Monday, I only included into the AOSP what ships to end users, i.e. from the JW branch, so I explicitly didn't include the kernel from the JS branch and I used the kernel from JW everywhere instead.
-Since the only changes in JS (compared to JW) were supposed to be related to the new devices, I assumed that the N4 kernel would be the same between the two (without actually checking), and I did all my testing of jb-mr2.0-release, jb-mr2-dev and master with the JS kernel (which was easier as it allowed me to use the same process for Nexus 4 and for the new Nexus 7). One of the changes done for the new devices was in the GPU code, in a way that required a new kernel for Nexus 4.
-The fix was to add the JS kernel to the relevant branches in AOSP.
So, there you have it: I mistakenly assumed there there'd be no kernel changes for N4 between JW and JS, and from there I did all my testing with the wrong kernel.
Sorry about that.
JBQ
Click to expand...
Click to collapse

markd0wn said:
He had some update statements since. Here they are:
Click to expand...
Click to collapse
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).

C4SCA said:
So peolple who are on stock are outdated and still not enjoying all the gpu optizations?
Correct me if im wrong
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.

markd0wn said:
Technically you are not wrong. It's a fact that JSS15J and its kernel has GPU optimizations/commits that are not included in the JWR66V build.
Click to expand...
Click to collapse
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).

C4SCA said:
So this 4.3 update is a huge fail for nexus 4 owners... And i was thinking that i wasnt going root it again...
Google messed up this time
4.3 is almost all about the gpu opt. and now people dont have it all on stock? ? ?
typed from my NeXuS 4 tasting some revamped Jellybeans (stock 4.3).
Click to expand...
Click to collapse
I don't know how huge those optimizations are. I'm sure someone will do some GPU-specific benchmark comparison between the builds at some point and see. But yes, a mistake did occur. The average person will be updated to JWR66V (at least at this point) only. Others could install JSS15J manually from one of the threads mentioned in the previous page.

Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?

markd0wn said:
They could definitely do it if they wanted to, probably somewhat easily too. The OTA is being pushed slowly for a reason - not just for bandwidth purposes, but so that if some mistake happened, not all devices would be affected. It's probably not a very high priority for them like what happened previously with the December bug, but they could release a JSS15J-from-JDQ39 OTA to devices that haven't been updated yet, and JSS15J-from-JWR6V for those who did update. Posting factory images is easier, and the binaries are already good for both JWR6V and JSS15J. If they chose to release it, we'd forget about this whole thing 1-2 weeks later. But it's hard to say if they'll listen. Might be worth a try as long as it's done in nice/acceptable ways and not by spamming/yelling/threatening and so on.
Click to expand...
Click to collapse
Agreed. Any way we can contact them? Maybe in their support pages? I'm kind of lost here =D
We should definitely give it a try, we've got nothing to lose.

Why I can't boot into recovery?
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?

Wonderful! I've been looking for somerthing since 25/07!
Thanks!!

simorangkir_dcs said:
I flashed factory image JWR few days ago, everything was good until today I just realized that I cannot boot into stock recovery. Everytime I enter bootloader and select recovery I only get dead android image with red exclamation mark.
Anybody experience this too?
Click to expand...
Click to collapse
Hold volume up + down and press the power button (may have to do it a few times). The stock recovery has its options hidden unless you press that combination once you get to the screen you are seeing.
Sent from my Nexus 4 using Tapatalk 4 Beta

mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Can someone confirm this?

mattkroeder said:
Thanks for the info. I flashed the factory images last night thinking I would much rather go with official images from now on. This thread tempted me to give the AOSP builds another try.
Honestly though, I don't know important the optimizations are. Maybe it's just me. Maybe it's just my own device...... but I find the stock build smoother than the AOSP builds. I get stutters while scrolling through my mms messages, for instance. And transitions on the stock feel smoother so far.
How does one know if we have delays in our wifi notifications though?
Click to expand...
Click to collapse
Same too ,i feel stock smoother than AOSP .
Sent from my Nexus 4 using Tapatalk 4 Beta

[Q] Any other ROMS for the S4 Active?

Has anybody been able to find any ROMs for the S4 Active? Preferably, the i537, but I'm willing to try anything for the GT-I9295. I know it's early, as the Safestrap method is fairly new, and the kernel can't be touched right now, so a 4.3 ROM is out of the question. I'm using the ROM listed here:
http://forum.xda-developers.com/showthread.php?t=2406177
I'm loving stock, but I have Cyanogenmod on my Nexus and love the customization. Does anybody know of anything close to that available for the Active?

Yea I believe its ported from the International version...they call it google edition I think! If I helped ya..it dosent hurt to hit the thanks button! :good:

Actually there is a pre-release 4.3 ROM available, it's the MI2 build for the I537 and yes it's a leak from AT&T (thanks to designgears and you can find it here). Two issues with that one if you choose to use it:
1) You may not be able to update to the official OTA 4.3 expected sometime later this month (according to rumors, that is)
2) There's no working root so if you must have that, don't bother with this build just yet
There is a third issue that appears to be the most common problem with the MI2 build and that's the screenshot feature which isn't working, it's covered in the thread for the MI2 build.
Because it's a pre-release similar to the MF1 pre-release leak, it appears to not allow an OTA but since there hasn't been any 4.3 OTA updates from AT&T as of yet nobody really knows what's going to happen.
Also, if you flash that MI2 build, your only alternative will be to fall all the way back to the MF1 build since no ODIN One-click exists for the MF2 or MF3 builds, but you can switch between the MF1 and MI2 builds (confirmed by others and I've done it several times in the past week myself).
Aside from that "official" ROM leak, the only other current working option is using Safestrap on MF1/MF2/MF3 (with the appropriate kernel modules) along with the AOSP ROM provided by LeJay which you can find here.
That's pretty much it. I have the I537 as noted so I don't muck with the I9295 ROMs but I think there's at least the one CM10.2 build for it, and no, it doesn't work on the I537 even with Safestrap.
EDIT: DOH, forgot about the ROM from d8389 he just released yesterday, also made from the MI2 build and you can find that one here - that's for the I9295, btw.

br0adband said:
Actually there is a pre-release 4.3 ROM available, it's the MI2 build for the I537 and yes it's a leak from AT&T (thanks to designgears and you can find it here). Two issues with that one if you choose to use it:
1) You may not be able to update to the official OTA 4.3 expected sometime later this month (according to rumors, that is)
2) There's no working root so if you must have that, don't bother with this build just yet
There is a third issue that appears to be the most common problem with the MI2 build and that's the screenshot feature which isn't working, it's covered in the thread for the MI2 build.
Because it's a pre-release similar to the MF1 pre-release leak, it appears to not allow an OTA but since there hasn't been any 4.3 OTA updates from AT&T as of yet nobody really knows what's going to happen.
Also, if you flash that MI2 build, your only alternative will be to fall all the way back to the MF1 build since no ODIN One-click exists for the MF2 or MF3 builds, but you can switch between the MF1 and MI2 builds (confirmed by others and I've done it several times in the past week myself).
Aside from that "official" ROM leak, the only other current working option is using Safestrap on MF1/MF2/MF3 (with the appropriate kernel modules) along with the AOSP ROM provided by LeJay which you can find here.
That's pretty much it. I have the I537 as noted so I don't muck with the I9295 ROMs but I think there's at least the one CM10.2 build for it, and no, it doesn't work on the I537 even with Safestrap.
EDIT: DOH, forgot about the ROM from d8389 he just released yesterday, also made from the MI2 build and you can find that one here - that's for the I9295, btw.
Click to expand...
Click to collapse
I'll keep playing the waiting game then... Maybe I can submit a request for Cyanogenmod to be made for this device.

Until the bootloader is unlocked, it's most likely not going to happen at all. It's possible that someone with enough talent can put together a CM10.1 ROM which uses the current kernels (I think, I'm not 100% sure on that), but the MI2 4.3 build now is pretty locked down as it is (no known root at the moment and it looks like Safestrap may be a no-go as well for that or future builds).
The honest truth is the GS4A is simply not popular enough to get any reaction from the CM crowd at all, unfortunately, and it's entirely possible it may not even be available for much longer given that unpopularity. It's not selling well, and the few of us that do have them are just that: few and far between.
It's sad because it's a great device; it IS an S4 with a lower resolution camera and the water-resistant aspect as well as the LCD panel (not AMOLED like the S4) which is just fine by me, I can see it better in daylight than an AMOLED anyway. But the locked bootloader basically ensures the level of interest is negligible at best, not much can be done about it unless a miracle comes along at this point.
I'm very happy with mine for many reasons, not just 'cause I got it so cheap.

br0adband said:
Until the bootloader is unlocked, it's most likely not going to happen at all. It's possible that someone with enough talent can put together a CM10.1 ROM which uses the current kernels (I think, I'm not 100% sure on that), but the MI2 4.3 build now is pretty locked down as it is (no known root at the moment and it looks like Safestrap may be a no-go as well for that or future builds).
The honest truth is the GS4A is simply not popular enough to get any reaction from the CM crowd at all, unfortunately, and it's entirely possible it may not even be available for much longer given that unpopularity. It's not selling well, and the few of us that do have them are just that: few and far between.
It's sad because it's a great device; it IS an S4 with a lower resolution camera and the water-resistant aspect as well as the LCD panel (not AMOLED like the S4) which is just fine by me, I can see it better in daylight than an AMOLED anyway. But the locked bootloader basically ensures the level of interest is negligible at best, not much can be done about it unless a miracle comes along at this point.
I'm very happy with mine for many reasons, not just 'cause I got it so cheap.
Click to expand...
Click to collapse
I think our best hope is for @Hashcode to get kexec working with SafeStrap. Then we will be able to use ROMs with any kernel. Until then we're stuck with GPE 4.2.2.

Hashcode made a post or two at his blog/site stating that things are becoming incredibly tough to make such workarounds viable anymore, even to the point where it's not even worth the time and trouble to make the effort at all in some situations. I think with the GS4A, more specifically the AT&T I537 model, we could just have a device that simply isn't going to get itself cracked wide open without some small miracle happening.
Come on, someone working at Samsung... have some pity on us and drop us something to help out, will ya?

I've started a request forum here:
http://forum.cyanogenmod.com/topic/80004-cyanogenmod-for-the-s4-active/
If anyone would like to back me up, it'd be much appreciated.

Decided it wasn't worth the BS of heading back to Best Buy so I'll stick with MF1 for now. I did make a reply at the CM forum about the potential of someone building CM10.1 as a flashable zip for us and provided the link to the kernel source for the I537, maybe someone with some spare time might be able to create something.
I really wish I'd spent more time learning how to do that; if I had the necessary skill set I'd build it myself I suppose but I've never been into that side of the device firmware/ROM stuff.
But who knows...

I'm running Shostock v2.3 on my I537 with one of my rom slots in safestrap. i'm on MF2. of the S4 ROMs, i've only tried Shostock and Goldeneye, but i'm sure other S4 ROMs will work too. when you install one, you also have to install the modules pack and camera fix from the ported google edition thread. the only other problem is the menu and back buttons don't work out of the box with an S4 ROM because our buttons aren't capacitive. thankfully, Darkman was kind enough to show me how to fix those so they work like normal.

hokeymcf said:
I'm running Shostock v2.3 on my I537 with one of my rom slots in safestrap. i'm on MF2. of the S4 ROMs, i've only tried Shostock and Goldeneye, but i'm sure other S4 ROMs will work too. when you install one, you also have to install the modules pack and camera fix from the ported google edition thread. the only other problem is the menu and back buttons don't work out of the box with an S4 ROM because our buttons aren't capacitive. thankfully, Darkman was kind enough to show me how to fix those so they work like normal.
Click to expand...
Click to collapse
Can you share how to edit ROMs to add the physical back and menu buttons? Thanks
GT-i9295(i537) running SafeStrap

yankeesfan714 said:
Can you share how to edit ROMs to add the physical back and menu buttons? Thanks
GT-i9295(i537) running SafeStrap
Click to expand...
Click to collapse
well, i don't edit the ROM before flashing it. after flashing the ROM, any updates for it, the modules pack, and the camera patch, i go into /system/usr/keylayout using a file explorer, and add:
key 139 MENU
key 158 BACK
to gpio-keys.kl with a text editor. after that, reboot and they work like they should.

hokeymcf said:
well, i don't edit the ROM before flashing it. after flashing the ROM, any updates for it, the modules pack, and the camera patch, i go into /system/usr/keylayout using a file explorer, and add:
key 139 MENU
key 158 BACK
to gpio-keys.kl with a text editor. after that, reboot and they work like they should.
Click to expand...
Click to collapse
Is it possible to add this to either the modules zip or the camera fix to make it easier for users? Ideally this would be added to the camera fix since I think @Hashcode is going to automate the modules in SafeStrap eventually.
On another note, I had no idea we could flash regular GS4 ROMs, this opens up a world of possibilities. I assume we can only flash 4.2.2 ROMs though?

Devo7v said:
Is it possible to add this to either the modules zip or the camera fix to make it easier for users? Ideally this would be added to the camera fix since I think @Hashcode is going to automate the modules in SafeStrap eventually.
On another note, I had no idea we could flash regular GS4 ROMs, this opens up a world of possibilities. I assume we can only flash 4.2.2 ROMs though?
Click to expand...
Click to collapse
i have no idea. i could try, but it's probably a job better suited to someone who really knows what they're doing, since i'm only as good as the tutorials i find on the internet.
once again, i dunno. i'm on MF2, but shostock is MF3. so since that's different but still works, it might be possible to flash a 4.3 ROM, but the fact that i read that there's no going back once you do flash it, i haven't tried it.
i agree that it's awesome we can actually use regular s4 ROMs.

yankeesfan714 said:
Can you share how to edit ROMs to add the physical back and menu buttons? Thanks
GT-i9295(i537) running SafeStrap
Click to expand...
Click to collapse
So in theory any stock based s4 4.2.2 ROM will run with this buildprop modification?
GT-i9295(i537) running SafeStrap

It's not a build.prop edit, but yeah, I think any S4 4.2.2 ROM would work.

S-Beam
Set them next to each other and use S-Beam, it's what it was designed for. Or even Bluetooth would work.

Just so everybody is aware @my-blue-snog-box has created a flashable zip file that will edit the keyboard file and get the hard keys working. It can be found here. If you try any S4 ROMs please post the functionality of them so we can create an index of ROMs working with SafeStrap.
I've posted over there that I got Hyperdrive ROM working, you just need to be careful during setup.

CM Unofficial 2013 10 10 fkosa's reply
I am running CM 20131010 Unoffical - jactiveltxxx from, ofcourse it is 4.3 and it is running smothly.
Havn't found any anoying errors yet.
http://forum.xda-developers.com/showthread.php?t=2395242&page=11
I tried to make some roms for myself and found out the following:
from: CM 20131017 Nightly - jltxxx - was a bit slow, and it felt like the touch was a bit delayed verry anoying
from: CM 20131021 Nightly - jltxxx - here there was something wrong with the screen.
But then again the nightly builds tends to a bit unstable from time to time.

Any Galaxy S4 Rom
I just recently got the galaxy note 2 and loving everything about it inside and out. But I was just wondering if there are or will be any rom or ports of a galaxy s4 rom to our galaxy note 2? Ive look in the android forums but did not see anything besides the hawkish rom which I am now currently using...

[Q] Building / porting for a "unusual" device

Good Afternoon, people.
I am brazilian and I have a smartphone that did not get into US and European market. It's name is "Motorola D3" and the number associate to it is "XT920".
Motorola Brazil were suposed to provide de newest rom for this device (marketing promissess). It took they almost 1 year to launch the Android Kitkat version 4.4.2.
The problem is: We want the Cyanogenmod in our device and all the newest ROM's.
That been said, I start to study to try yo port or Build a AOSP ROM to XT920 and, therefore, a CM11.
No threads on "how to port / build" a rom for a New device went trhough this problem. This device runs as a Mediatek MTK6577. I've seen that the kernel for this processor was released, but I don't know how to handle the kernel with the device and ROM properly.
Another doubt is: what is the difference between port and build a ROM? I've seen videos of porting and building and it is not clear to me.
I have reached the point where I have to download the drivers, but, in the tutorial the person was dealing with a NEXUS, wich is much easier to build, since it have a native android support.
Anyway, I want to keep this project going, and I really need some help with this questions.
Thankyou

digo_santista said:
This device runs as a Mediatek MTK6577.
Click to expand...
Click to collapse
You're screwed. MTK devices are extremely nightmarish to work with. Their kernel source is a mess and the platform source is an even bigger mess.
Even people who have had access to a complete OEM source code tree for an MT6589 device didn't succeed in getting the hacks to play nice with an AOSP source tree.
Android One has helped somewhat with devices that are released as part of the One program, but non-One MTK devices are still a nightmare.
The process of doing an AOSP bringup for a new device isn't particularly well defined because it is different for every device in existence. The only way to learn is by doing.
It helps a lot if a device with a similar chipset to yours is supported by whatever project you're trying to work with - for example most mid-to-high-end Qualcomm chipsets are not very difficult to work with. But MTK devices were nearly impossible to support with AOSP-derivative projects prior to One, and even after One, it seems like only Android One devices are "clean" enough to leverage Google's improvements to MTK support.

:/ should I waste more time or just drop it?
Entropy512 said:
You're screwed.
Click to expand...
Click to collapse
What should I do? I just quit without trying? I understand that this is a huge problem. But, if I decide to take the chalenge, is there a chance to succeed?
I am trying to figure this out and I didn't found an answer to this question: can I use the kernel that is packed with my stock ROM (provided by motorola) to build or port a CM11 ROM?
Sorry to bother, but I is really keeping me up at night
Regards,
Cassio Rodrigo

CM13 for Quark

Does anyone know when cm13 will start rolling out for quark? I love this phone, and I think marsmallow would be amazing on it, especially with that huge battery.

channing173 said:
Does anyone know when cm13 will start rolling out for quark? I love this phone, and I think marsmallow would be amazing on it, especially with that huge battery.
Click to expand...
Click to collapse
The CM Quark dev @Skrilax_CZ just bought a 2nd phone so he can test CM13 while still keeping CM12.1 going on his main phone.
http://forum.xda-developers.com/mot...xx-xt1225-cm12-0-pre-release-t3060089/page100

Rule #1 of Fight Club: Never ask for ETAs.
Sent from my DROID Turbo using Tapatalk

Patiently waiting here too ...
Patiently waiting here too. Marshmallow changes look interesting.
and Thanks in advance,

You'll know as soon as you see a changelog here http://www.cmxlog.com/13/quark/
Sent from my XT1254 using Tapatalk

I'm waiting on it, too. I thought about flashing CM 12.1, but I don't really know what i gain by doing that over unlocked w/ Xposed and the stock Moto features. Marshmallow, though, would make it worth it. Unless there's something i'm missing.

EnderKR said:
I'm waiting on it, too. I thought about flashing CM 12.1, but I don't really know what i gain by doing that over unlocked w/ Xposed and the stock Moto features. Marshmallow, though, would make it worth it. Unless there's something i'm missing.
Click to expand...
Click to collapse
I've done rooted stock + xposed.
I've done custom ROM + xposed.
I've done custom ROM by itself.
Here's my opinion based on experience...
I did rooted stock + xposed only when there was no custom ROM available. It's the least preferable choice, due to security risk. Rooted stock + xposed is just a simulation of a good custom ROM. It's better than nothing -- but good custom ROMs are updated frequently to close malware holes. Both CM121. and Resurrection Remix have blocked the Stagefright risk. Does Motorola's current stock ROM block that risk? Are there Xposed modules that block that risk? That's just ONE security threat, there are many others since stock 5.1 ROM was released.
I've done custom ROM+ xposed, when there was one or two features an otherwise excellent ROM did not have -- or in one specific case where the ROM devs on purpose locked users into a specific choice where they previously gave user options. Installing xposed with that ROM let me use my phone the way I wanted, giving me choice back while still using that ROM. The problem with using xposed + custom ROMs is xposed modules are only guaranteed to work on AOSP ROMs that have not been heavily modified. There may be a conflict somewhere. I would only use it for one or two features you could not live without -- like in the example I gave, "clear all recents".
I've done custom ROM only. CM12.1 has been the first ROM where I didn't need xposed to add any functionality to the ROM I was using. Resurrection Remix actually has even more options... but I'm comfortable with CM12.1. (CM dev @Skrilax_CZ brought the first custom ROM and kernel for our Quarks, all others that followed are based his work -- especially the kernel.) I'm running CM12.1 on both my Quarks and have been for months. But the point is both Resurrection Remix and CM12.1 are way more advanced than Motorola stock 5.1, as they are both 5.1.1 + custom features.
NOTE: There really aren't any stock Moto features that are not replicated by custom ROMs. It may be called something else, but it's the same feature. Resurrection Remix even has the permissions integrated to let you to install MOST Moto apps if you absolutely need to have the same name. See this page: http://forum.xda-developers.com/droid-turbo/general/to-motorola-features-t3266646/page5
Plus, Resurrection Remix and even CM12.1 would have the security updates stock ROM does not.
I'm running CM12.1 plus Moto Camera because someone ported the Moto camera for CM users, and CM12.1 has all the other functionality I need (just different names).

ChazzMatt said:
I've done rooted stock + xposed.
I've done custom ROM + xposed.
I've done custom ROM by itself.
Here's my opinion based on experience...
I did rooted stock + xposed only when there was no custom ROM available. It's the least preferable choice, due to security risk. Rooted stock + xposed is just a simulation of a good custom ROM. It's better than nothing -- but good custom ROMs are updated frequently to close malware holes. Both CM121. and Resurrection Remix have blocked the Stagefright risk. Does Motorola's current stock ROM block that risk? Are there Xposed modules that block that risk? That's just ONE security threat, there are many others since stock 5.1 ROM was .
I've done custom ROM+ xposed, when there was one or two features an otherwise excellent ROM did not have or in one specific case where the ROM devs on purpose locked users into a specific choice where they previously gave user options. Installing xposed with the ROM let me use the phone the way I wanted, giving me choice back while still using that ROM. The problem with that is xposed modules are only guaranteed to work over ROMs that have not been heavily customized already. There may be a conflict somewhere. I would only use it for one or two features you could not live without -- like in my case, clear all recents.
I've done custom ROM only. CM12.1 has been the first ROM where I didn't need xposed to add any functionality to the ROM I was using. Resurrection Remix actually has even more options, but I'm comfortable with CM12.1. BOTH are way more advanced than stock 5.1, as they are both 5.1.1 + custom features.
There really aren't any stock Moto features that are not replicated by custom ROMs. It may be called something else but it's the same feature. Resurrection Remix even has the permissions integrated to let you to install MOST Moto apps if you absolutely need to have the same name. See this page: http://forum.xda-developers.com/droid-turbo/general/to-motorola-features-t3266646/page5
Plus Resurrection Remix would have the security updates stock ROM does not.
Click to expand...
Click to collapse
Fair enough, I appreciate the input. I'm still pretty new to the custom ROM scene, so there's lots to learn. Why not, I'll give Resurrection Remix a try. Sounds like people love it, and I really like the Moto features so I'd want to keep those. Thanks for the advice

I honestly just like the "all my devices are the same" so all my devices that can run cm.

As for CM-13.0, there is still a lot to be done to get it to a daily driver state.

Hurts not having stock mm I'm guessing?
Sent from my XT1254 using Tapatalk

Skrilax_CZ said:
As for CM-13.0, there is still a lot to be done to get it to a daily driver state.
Click to expand...
Click to collapse
koftheworld said:
Hurts not having stock mm I'm guessing?
Click to expand...
Click to collapse
Not necessarily. That didn't stop @Skrilax_CZ from giving us Lollipop (March 2015) before Motorola released stock Lollipop for any of the Quarks. April 2015, Moto Turbo XT1225 was released with stock Lollipop 5.0.2 -- that was the first Quark with stock Lollipop from Motorola. @Skrilax_CZ beat them by using CM12.0 (Lollipop 5.0.2) with Kitkat 4.4.4 kernel, until Motorola publicly released Lollipop 5.0.2 kernel code. (Even though Motorola gave the Moto Turbo XT1225 5.0.2 in April 2015, they didn't release their Lollipop 5.0.2 kernel code publicly for devs to use until a few weeks later.)
Point is, we had Lollipop for Quark before Motorola gave Lollipop to Quark!
And we had CM12.1 (Lollipop 5.1.1) months (mid-April 2015) before Motorola finally gave just 5.1 to the Droid Turbo XT1254 in July 2015:
Skrilax_CZ said:
15th April 2015, 03:37 PM
Done. I have also moved to CM12.1 from now on, so I'll not be backporting latest set of patches back to CM-12.0
Click to expand...
Click to collapse
@Skrilax_CZ used CM12.1 (Lollipop 5.1.1) first with Motorola's 4.4.4 kernel code and then Motorola's 5.0.2 kernel code, until Motorola finally released Lollipop 5.1.x kernel code (September 2015).
Motorola never gave the other Quarks Lollipop 5.1 -- the Moto Turbo XT1225 and Moto Maxx XT1225 officially still have 5.02. and the U.S. Moto Maxx XT1250 (same identical device as the Droid Turbo XT1254, even the same FCC ID) is still "officially" stuck on Kitkat 4.4.4 -- unless you root and install custom Lollipop 5.1.1. ROM. But thanks to devs like @Skrilax_CZ we've had Lollipop 5.1.1 since April 2015!
So, NO, we do not have to wait for Motorola's slow roll-out of stock MM for our Quarks.
____________
mrkhigh said:
I honestly just like the "all my devices are the same" so all my devices that can, run cm.
Click to expand...
Click to collapse
Same here. When I help friends and family, I install CM so I know exactly where all the settings and options are. Two LG G2 phones, a Nexus 7 tablet all owned by other friends or in-laws. My wife's and my Quark XT1225. For some reason I never rooted my wife's Nexus 9 (yet) -- but when I do, it will have CM.
I also install Nova launcher and set all those options the same all all devices (including non-rooted Nexus 9). My wife said, "But my tablet looks like my phone." I replied, "Exactly." That was my intention.
If something isn't acting right, I can quickly diagnose it without having to remember it's set up differently or has an entirely different ROM.

Quick question, out of ignorance, not wanting to seem unappreciating... Doesn't the nexus 6 have very similar hardware to the turbo? And does MM change that much from the framework of lollipop? I have no idea about rom building, but shouldn't the process be more... Seamless? I've done some building on Linux itself and have some idea of how an OS works, shouldn't drivers be separate from the framework itself? I don't mean this for the turbo exactly, or trying to minimize the awesome works skrillax has done, but I mean this in the more general non-UI-modified-vanilla-ROMs sense.

IonAphis said:
Quick question, out of ignorance, not wanting to seem unappreciating... Doesn't the nexus 6 have very similar hardware to the turbo? And does MM change that much from the framework of lollipop? I have no idea about rom building, but shouldn't the process be more... Seamless? I've done some building on Linux itself and have some idea of how an OS works, shouldn't drivers be separate from the framework itself? I don't mean this for the turbo exactly, or trying to minimize the awesome works skrillax has done, but I mean this in the more general non-UI-modified-vanilla-ROMs sense.
Click to expand...
Click to collapse
I believe the it's the kernel that takes a lot of work. Could be wrong thou
Sent from my DROID Turbo using Tapatalk

http://forum.xda-developers.com/showpost.php?p=64573429&postcount=1050

cadenmiller60 said:
I believe the it's the kernel that takes a lot of work. Could be wrong thou
Sent from my DROID Turbo using Tapatalk
Click to expand...
Click to collapse
not that it is the right way to do things or anything less than half baked kanging, but
i sucessfully got carbon rom (shamu) to boot on my xt1254. several things *appeared* broken, the worst of which was a 180° flip on the screen that kept buttons (touch response) in a spot it is visually not. i tried to simply add the inverse mounted line from the cm12.1 build.prop but that didnt change anything. i used the cm12.1 kernel.
if any of you that actually have a clue have pointers, insight, or know what i need to do tp port shamu roms to the quark, im all ears

kitcostantino said:
not that it is the right way to do things or anything less than half baked kanging, but
i sucessfully got carbon rom (shamu) to boot on my xt1254. several things *appeared* broken, the worst of which was a 180° flip on the screen that kept buttons (touch response) in a spot it is visually not. i tried to simply add the inverse mounted line from the cm12.1 build.prop but that didnt change anything. i used the cm12.1 kernel.
if any of you that actually have a clue have pointers, insight, or know what i need to do tp port shamu roms to the quark, im all ears
Click to expand...
Click to collapse
Few things to note and remember that the DPI for the two devices are different (may be the cause of the rotation bug or not) For Quark is 640 for Shamu I think is 560 (will have to verify) Also what changes did you make to the existing build prop (if any) to get the ROM to boot?

GreaterLesser said:
Few things to note and remember that the DPI for the too devices are different (may be the cause of the rotation bug or not) For Quark is 640 for Shamu I think is 560 (will have to verify) Also what changes did you make to the existing build prop (if any) to get the ROM to boot?
Click to expand...
Click to collapse
the dpi looked right, but you are correct that technically, 560 is not correct for the quark. ultimately, i didnt have to change anything to get it to boot aside from swapping in the cm12.1 boot.img. it seems like someone could make a script or kit to easily port shamu roms to the turbo if the issues (bluetooth, screen, audio, radios lol) were ironed out. probably easier to build something else than to fix existing roms for another (similar, yet widely different) device. i have no answer for the screen issue aside from adding the inverted display line to build.prop, which changed nothing. principally, the fact that it didnt just blackscreen and soft brick is more promising than i had expected still, i do not know a tenth of what to do, so it isnt gonna work for me anytime soon. lol.

kitcostantino said:
the dpi looked right, but you are correct that technically, 560 is not correct for the quark. ultimately, i didnt have to change anything to get it to boot aside from swapping in the cm12.1 boot.img. it seems like someone could make a script or kit to easily port shamu roms to the turbo if the issues (bluetooth, screen, audio, radios lol) were ironed out. probably easier to build something else than to fix existing roms for another (similar, yet widely different) device. i have no answer for the screen issue aside from adding the inverted display line to build.prop, which changed nothing. principally, the fact that it didnt just blackscreen and soft brick is more promising than i had expected still, i do not know a tenth of what to do, so it isnt gonna work for me anytime soon. lol.
Click to expand...
Click to collapse
Well for WiFi, Radios, Bluetooth, etc doesn't the drivers need to be added to the build.prop for the system to actually use them? If possible you could use a build.prop for the turbo in Carbon and just tailor it a bit, theoretically of course. I know it's more complicated than I'm making it sound.

lol. yes, but i get what you mean. in older roms (cm10, cm11) to port, youd copy/paste all of the set perm recursives. in cm12.1 i dont know where to start pulling things from. mind you, i know its not as simple as it used to be because of the new dat format. guess i should read up a bit. lol