Related
Hey so I love that we have AOSP for my Sony = Sony Nexus!!
But who should I be following as the cutting edge of AOSP. I know Sony releases some sources but not the proprietary ones so I know most of it comes from there. I myself have just installed the latest RC3 of CM 10.1. And the bugs I used to have like Lockscreen delay and No audio on Hangouts seem to have gone. But why should I install FreeXperia over CM?
Is CM the base that everyone bases their AOSP on? Is Free Xperia more focused on the Sony Specific Issues?
And what about Linaro? Carbon? AOKP? Are they all based off the same source (they all seem to have the same bugs)
Thoughts? Direction?
Thanks in advance!
First of all, CM roms are made by the FXP team as they are official CM maintainers for Sony devices.
Secondly, Sony's AOSP sources are different from that of CM sources. AOSP implies pure android with stock customizations. CM sources is heavily customizable (think of all the settings you can do in CM10.1) they are based on Google's open source as well as the device specific source code released by Sony.
Sent from my C6602 using xda app-developers app
CM10.1 vs. Free Xperia
What is the difference between the regular CM and the one you can download from FreeXperia project?
E.g. for Xperia Z (the latest releases at the moment):
FXP222a-cm-10.1-20130604-UNOFFICIAL-yuga.zip
Click to expand...
Click to collapse
vs.
cm-10.1-20130608-NIGHTLY-yuga.zip
Click to expand...
Click to collapse
80mercury said:
What is the difference between the regular CM and the one you can download from FreeXperia project? ...
Click to expand...
Click to collapse
I too would like to know this - obviously, they're very close, but there must be something different there.
I spent an hour trying to find this out the other night - got slightly excited when I saw a message from some poor sucker who explained he was a noob, etc, blah, blah, and would someone please explain the difference. The only reply he got was a terse demand that he go read the FreeXperia dev thread and work it out for himself ...
If someone can write an explanatory sentence or two about the difference between the builds on the official Cyanogen Mod site and the FXP* builds from freexperiaproject.com, I would appreciate it.
ratworks said:
I too would like to know this - obviously, they're very close, but there must be something different there.
I spent an hour trying to find this out the other night - got slightly excited when I saw a message from some poor sucker who explained he was a noob, etc, blah, blah, and would someone please explain the difference. The only reply he got was a terse demand that he go read the FreeXperia dev thread and work it out for himself ...
If someone can write an explanatory sentence or two about the difference between the builds on the official Cyanogen Mod site and the FXP* builds from freexperiaproject.com, I would appreciate it.
Click to expand...
Click to collapse
hey man, I had forgotten that I had made this thread but long story short FXP and CM are the same. CM has their own schedule, standards and code they develop and CM work towards AOSP for all their devices. FXP are SONY only, They use the code by CM and are responsible for both the Sony releases via CM and FXP. How FXP differs is that they can go ahead and release a lot of versions without any established "stable" or milestones they just release updates as they go. CM take those Sony specific changes that are made and combine them standard CM code are release Milestones, RC's and Nightlies with varying results
TLDR: They are the same, All the Sony specific code in CM is FROM FXP, FXP has no interest in making a stable version they just release new code in an almost "nightly" fashion. Their is no guarantee that the newest FXP will be more stable then the previous, its the same risk you take when you go with CM nightlies.
Personally I prefer CM Nightlies. If you want stable (with established bugs) go with CM, if you want to be running the latest CM code go with CM but if you want the latest sony fixes (unstable at times) go FXP, who updates about 1 every 1-2 weeks
Great explanation mate, thanks for that.
[EOL][KERNEL][UNOFFICIAL BUILDS] Boeffla Kernel Linaro/Uber
hi Guys,
It's me again and this time with a special "build-service" for boeffla kernel users! As some of them liked the "linaro build" made by Lord Boeffla in form of his 5.1 beta 13 version and requested it for newer versions too i decided to "tune" my build script a bit and spent that 2 min 40 sec in addition on every build for those of you who requested a Linaro build of recent versions of the boeffla kernel. As i anyway do my own builds of every new released (but only for samsung sources!) Boeffla Kernel version mainly for testing new versions of the ZZMoove Governor, building itself isn't that much more effort.
As stated Lord Boeffla used the linaro toolchain in his kernel version 5.1 beta 13 but he finally came back again to the well proven Android Stock Toolchain in following versions for stability reasons. Good and understandable decision because this is really what Boeffla stands for, stability and i underlined that *g*!! Kernel images build with linaro toolchain tend to be less stable then build with a stock toolchain due to the optimizations it makes to the code when it builds the image. Anyway they run a little bit "smoother/faster" and for some of you it even might not make any troubles at all. So in agreement with Lord Boeffla i want to provide you these self made linaro builds here for your further usage. Beside of that for really brave guys *g* i will in addition use this thread for own purposes too and will put in here beta versions of zzmoove governor compiled into boeffla kernel. But they will only be "Samsung" versions as i'm using only stock roms and they will only be build with stock toolchain because zzmoove is sometimes experimental enough, i have no need for more "unexpectedness" by using linaro toolchains during testing
ok then let's start...
First of all the obligatorily Disclaimer:
As also written in the title please note these builds are UNOFFICIAL, are NOT SUPPORTED in any way by Lord Boeffla or myself and might be EVEN UNSTABLE! So take them as they are! As always flash them at your own risk and make a backup before flashing!
About bugs: Before you report ANY issues with the linaro builds provided here (doesn't matter which one!) FIRST TRY the non-linaro official builds from HERE to see if they will be gone then. if they wont, you can go on and report your problems in the official boeffla kernel thread! I hope you understand that we have to treat and keep these builds here completely separate from official ones as they have in no terms something to do with each other! Not respecting this will force me to stop building further linaro builds of boeffla kernel.
About benchmarks and comparisons between toolchains: It's common known that linaro builds might give us higher benchmark rates and that seems great for some people (in fact it's pointless per se in my opinion ) so please if you really must, post them ONLY here and NOT in official boeffla kernel thread, thanks!
Now some more precise informations about what's going on here:
what i did:
the images are always build with original sources from official boeffla kernel repositories from HERE
with some not worth to mention minor changes to be able to build it on my build environment.
all images are compiled with following build flags which were also used in boeffla kernel 5.2 beta 4
and with NEW Toolchain Linaro 4.9.3-2015.03 - Credits to @Christopher83 for the preconfigured toolchain and many many thanks to @P$T for the pm with the info and credits for the needed modifications i could use from his repo! :highfive: meanwhile even @Lord Boeffla benefited also from this info and therefore we had also a stock toolchain 4.8 build
all images are build with lzma compression instead of gzip to produce a compatible images size with the used optimization flags below
Code:
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration
-Wno-format-security -Wno-array-bounds
-fno-delete-null-pointer-checks -fno-schedule-insns2 -ffast-math
-mtune=cortex-a9 -march=armv7-a -mcpu=cortex-a9 -mfpu=neon -marm
-fno-schedule-insns2 -mno-unaligned-access -fno-pic
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os
else
KBUILD_CFLAGS += -Ofast -fmodulo-sched -fmodulo-sched-allow-regmoves -fno-tree-vectorize
endif
all images are build with changes from following repos:
Samsung i9300 Stock
https://github.com/zanezam/boeffla-kernel-samsung-s3
Samsung i9300 CM/LineageOS/Omnirom
https://github.com/zanezam/boeffla-kernel-cm-s3
https://github.com/zanezam/boeffla-kernel-omnirom-s3
Elite Boeffla Kernel:
https://github.com/zanezam/elite-boeffla-kernel-lineage14.1-i9300
Samsung n51x0 Stock
https://github.com/zanezam/boeffla-kernel-samsung-n51x0
Samsung n51x0 CM/LineageOS
https://github.com/zanezam/boeffla-kernel-cm-n51x0
what i will do:
build the source code with linaro toolchain and (like Lord Boeffla usually does) provide a odin-flashable tar.md5 and a CWM image of recent boeffla kernel versions.
do a test for about 1 day with this builds and if they work without any big issues, add them here in the thread.
i will try to keep the linaro toolchain as up-to-date as possible till the need of bigger code change will be reached.
not providing versions that are not released by Lord Boeffla yet.
not providing an image if it is not working - well of course not *g* but it will be marked as "canceled" then for info.
not change the source code to add/remove features or fix boeffla kernel related bugs.
not support the whole stuff here.
what i will maybe do (sooner or later):
provide zzmoove test builds if there are any new versions to test - more infos and discussions about ZZMoove Governor can be found HERE
maybe tune the build flags if some more linaro experienced user comes up with "better" ones (feel free to post and let me know, linaro specialists! *g*)
Downloads:
Galaxy S3
GT-I9300 Samsung builds
(for Samsung JB 4.3 and Samsung KK 4.4 ARCHIPORT)
GT-I9300 Cyanogenmod 11 builds
(for CM11, Temasek unofficial CM11)
GT-I9300 Cyanogenmod 12 builds
(for CM12, full support for TeamUB unofficial CM12, confirmed to run also on some other CM12 variants but u have to try yourself as they are untestet by me)
GT-I9300 Cyanogenmod 12.1 builds
(for CM12.1, full support for unofficial CM12.1 by JustArchi, Moster2 and arter97, confirmed to run also on some other CM12.1 variants but u have to try yourself as they are untestet by me)
GT-I9300 Cyanogenmod 13.0 builds
(for CM13.0, support for official CM13.0 and based roms)
GT-I9300 Cyanogenmod 14.1 / LineageOS 14.1 builds
(for LineageOS14.1/CM14.1, support for official LineageOS14.1/CM14.1 and based roms)
GT-I9300 Omnirom builds
(for Omnirom, Slimkat, Carbon, AOKP etc.)
Elite Boeffla Kernel:
Elite Boeffla Kernel GT-I9300 Cyanogenmod 14.1 / LineageOS 14.1 builds
(for LineageOS14.1/CM14.1, support for official LineageOS14.1/CM14.1 and based roms)
Check out original thread with info and changelogs of Elite Boeffla Kernel
Galaxy Note 8
N5100:
GT-N5100 Samsung Jelly Bean 4.2.2 builds
(for Samsung JB 4.2.2 roms)
GT-N5100 Samsung KitKat 4.4.2 builds
(for Samsung KK 4.4.2 roms)
GT-N5100 CyanogenMod 12.0 builds
(for CyanogenMod 12.0 roms)
GT-N5100 CyanogenMod 12.1 builds
(for CyanogenMod 12.1 roms)
GT-N5100 CyanogenMod 13.0 builds
(for CyanogenMod 13.0 roms)
GT-N5100 LineageOS 14.1 builds
(for LineageOS 14.1 roms)
N5110:
GT-N5110 Samsung Jelly Bean 4.2.2 builds
(for Samsung JB 4.2.2 roms)
GT-N5110 Samsung KitKat 4.4.2 builds
(for Samsung KK 4.4.2 roms)
GT-N5110 CyanogenMod 12.0 builds
(for CyanogenMod 12.0 roms)
GT-N5110 CyanogenMod 12.1 builds
(for CyanogenMod 12.1 roms)
GT-N5110 CyanogenMod 13.0 builds
(for CyanogenMod 13.0 roms)
GT-N5110 LineageOS 14.1 builds
(for LineageOS 14.1 roms)
N5120:
GT-N5120 Samsung Jelly Bean 4.2.2 builds
(for Samsung JB 4.2.2 roms)
GT-N5120 Samsung KitKat 4.4.2 builds
(for Samsung KK 4.4.2 + 4.4.4 roms)
GT-N5120 CyanogenMod 13.0 builds
(for CyanogenMod 13.0 roms)
GT-N5120 LineageOS 14.1 builds
(for LineageOS 14.1 roms)
Mirror on Androidfilehost for all devices (only latest kernel versions)
NOTE: if u got issues with root (cause is currently unknown!) after flashing one of these images u can try this method provided by @VictorLapin (thx for letting us know!)
previously known issues with recent boeffla kernel versions compiled with linaro toolchain (none of them appeared since one of newer toolchain 4.9.1 versions and also did not appear with actual used 4.9.2 version):
stuck of max. frequency for example at 1400mhz even if it is set to a higher max. frequency - reported by some users, and confirmed by me!
fix would be to temporary change the governor once or also temporary change the governor settings once (for example with profiles in boeffla config app)
EDIT: This is not related to the toolchain!
slower hotplug or sometimes stucking cores in zzmoove governor - reported by some users, not confirmed by me
higher "idle" temperature and operating temperature in general - confirmed by me
noticeable higher energy consumption (maybe related to next issue) - confirmed by me
lags when using zram and or in combination with frandom tweaks - confirmed by me
random hot reboots - confirmed by Lord Boeffla, not confirmed by me
see? that's really not boeffla like, isn't it!? but anyway as always these problems might depend "just" on one, some, or on a combination of multiple things so it might be that you never face them. If you find a setting and/or have other informations which workarounds or even fixes the issues feel free to post them here they would be highly appreciated! Even if this is not the main aim of that thread yet we maybe can find a way to a more stable linaro build of boeffla kernel and that would be a good thing, though! :highfive: Beside of that feel also free to post new issues found with the linaro builds but keep in mind don't forget to crosscheck with non-linaro offical builds to be sure that it is really related to the toolchain.
finally i wanna throw out big thanks to Lord Boeffla for his great work and for accepting that i provide you the linaro builds here especially because he had a bad feeling about this, but i think we will not disappoint him, won't we?!
enjoy living on the edge...
reserved
Reserved
Reserved
this one too
Great idea and thanks for all the work. If people get used to read OP before doing anything, we shouldn't be worried at all.
Sent from my GT-I9300 using XDA Premium 4 mobile app
Lulavc said:
Great idea and thanks for all the work. If people get used to read OP before doing anything, we shouldn't be worried at all.
Sent from my GT-I9300 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Thx, yeah that might be the only problem
Lulavc said:
Great idea and thanks for all the work. If people get used to read OP before doing anything, we shouldn't be worried at all.
Click to expand...
Click to collapse
Isn't that like saying: There will be trouble for sure?
SaschaKH said:
Isn't that like saying: There will be trouble for sure?
Click to expand...
Click to collapse
Most likely yes. In the past we had overheating phones and zRam being weird.
But... still, thanks to ZaneZam to take the work and build the Linaro versions for it for the ones that like trouble
Andi
Version 5.2 beta 1 ready
Hi Guys,
just for info:
Boeffla-kernel-5.2-beta1-Samsung-i9300-linaro - build ok - testing
arriving in about a day (if everything is ok *g*)
EDIT: and looks good to me therefore added to the OP! enjoy!
regards
ZZ
fantastic !
Just want to say that I am using this kernel for about one week now and this is by far the smoothest kernel I have used. I really can feel the difference between Google Toolchain and linaro (Beofflas build is also smooth but I think this one is a tick faster). I don't have any of the problems mentioned in OP. Everything is working like it should.
@ZaneZam there is a new linaro build available - 14.01. I also see there are many devs using linaro 4.8.3. What is the difference compared to the linaro version 4.7.4 you are using?
Many thanks in advance.
bone069 said:
Just want to say that I am using this kernel for about one week now and this is by far the smoothest kernel I have used. I really can feel the difference between Google Toolchain and linaro (Beofflas build is also smooth but I think this one is a tick faster). I don't have any of the problems mentioned in OP. Everything is working like it should.
@ZaneZam there is a new linaro build available - 14.01. I also see there are many devs using linaro 4.8.3. What is the difference compared to the linaro version 4.7.4 you are using?
Many thanks in advance.
Click to expand...
Click to collapse
Thx for the info! nice to hear that! :highfive: well honestly atm i dunno exactly what's the differnce between these two toolchains (but i think it might be a lot, question is if it has big relevance for us ) i have to check that in a quiet minute. but what i know since yesterday from my own experience is that recent boeffla kernel beta2 (inofficial yet, but will come soon) + zzmoove 0.8b10 (release candidate, comes also soon) build with linaro 4.8.3 runs very good!! if that positive result stays for one more day :fingers-crossed: i will jump on that one and forget the other one!
we will see...
ZaneZam said:
Thx for the info! nice to hear that! :highfive: well honestly atm i dunno exactly what's the differnce between these two toolchains (but i think it might be a lot, question is if it has big relevance for us ) i have to check that in a quiet minute. but what i know since yesterday from my own experience is that recent boeffla kernel beta2 (inofficial yet, but will come soon) + zzmoove 0.8b10 (release candidate, comes also soon) build with linaro 4.8.3 runs very good!! if that positive result stays for one more day :fingers-crossed: i will jump on that one and forget the other one!
we will see...
Click to expand...
Click to collapse
Very nice to hear that. Thank you very much buddy
Waiting for the Linaro beta 2...
5.2 beta2?
Bro ZZ,
Any plan to recompile for 5.2 beta2?
Let me know when the omni version is up! I'm eager to help with any testing necessary.
ymy3890 said:
Bro ZZ,
Any plan to recompile for 5.2 beta2?
Click to expand...
Click to collapse
Yeah man, in a few hours and test with new Toolchain was very positive so this one will be a linaro 4.8.3 build
ZaneZam said:
Yeah man, in a few hours and test with new Toolchain was very positive so this one will be a linaro 4.8.3 build
Click to expand...
Click to collapse
Glad to hear it.
Little mess
ymy3890 said:
Glad to hear it.
Click to expand...
Click to collapse
hi guys,
sry to all of you who are waiting for the latest linaro build and still can't use it yet!
unfortunately this build delays a bit because of three reasons:
first: a dumb-ass "git" accident during prepare of sources - i really nuked my brand new build script - what a fu.... mess still can't beleve it
(for insiders: NEVER EVER do a "git clean -f -d" if you are in hurry or try to do mutli-tasking (last one applies not on girls *g*)! backup? what is this? needed? no yet! *g* yeah i hear u laughing insiders but i think some of u know exactly how this really feels if u have spend some hours for what u lost, actually so: :crying: well i will survive this but throws me back a bit. some of u might think: wtf? hours needed to a make a build script? well due to the latest motivation because of this thread here *g* it has grown up from a advanced script to a full automatic build programm
second: i have a "feeling" that Lord Boeffla will release a new beta soon!
third: day has too less hours (hence this giant automatic build "programm" *g*)
i'm just doing a dump of the latest changes i made from my brain into an older backup of the script
and will be back again if it is up and running and maybe also with new beta of boeffla kernel thenl! :good:
aaand yes as i said i did already a test with recent beta2 build with new linaro toolchain but this build has "something" included which is only for interenal testing yet. yeah u got me it has some final changes for the new "beast" included
so I ask for a little bit patience, thx!
cheers
ZZ
Thanks!
ZaneZam said:
hi guys,
[HIVE]
sry to all of you who are waiting for the latest linaro build and still can't use it yet!
unfortunately this build delays a bit because of three reasons:
first: a dumb-ass "git" accident during prepare of sources - i really nuked my brand new build script - what a fu.... mess still can't beleve it
(for insiders: NEVER EVER do a "git clean -f -d" if you are in hurry or try to do mutli-tasking (last one applies not on girls *g*)! backup? what is this? needed? no yet! *g* yeah i hear u laughing insiders but i think some of u know exactly how this really feels if u have spend some hours for what u lost, actually so: :crying: well i will survive this but throws me back a bit. some of u might think: wtf? hours needed to a make a build script? well due to the latest motivation because of this thread here *g* it has grown up from a advanced script to a full automatic build programm
second: i have a "feeling" that Lord Boeffla will release a new beta soon!
third: day has too less hours (hence this giant automatic build "programm" *g*)
i'm just doing a dump of the latest changes i made from my brain into an older backup of the script
and will be back again if it is up and running and maybe also with new beta of boeffla kernel thenl! :good:
aaand yes as i said i did already a test with recent beta2 build with new linaro toolchain but this build has "something" included which is only for interenal testing yet. yeah u got me it has some final changes for the new "beast" included
so I ask for a little bit patience, thx!
cheers
[/HIVE]
ZZ
Click to expand...
Click to collapse
Bro ZZ, I will be patiently waiting for it.
ZaneZam said:
second: i have a "feeling" that Lord Boeffla will release a new beta soon!
ZZ
Click to expand...
Click to collapse
Your "feeling" was absolutely right. Seems you got some insider information, hehe.
But now it is out, so go for it with Linaro
Thanks
Andi
This is the first ROM I've ever built after years of using Android.
So this is CyanogenMod 11, compiled fresh from source with JustArchi Android Optimizations (This Commit). Linaro 4.7 is used to build the ROM & Kernel for a balance between performance & stability (4.8 gives too much problem). Also the target user is user (instead of userdebug) because it reduces debugging modules which will make the phone faster, the downside? This ROM is Odexed and Unrooted
Disclaimer:
I do not take responsibility of:
Bricked Phone
Data loss
Nuclear War
Losing your job because the alarm didn't go off
TLDR, use this at your own risk!
What is JustArchi Android Optimizations?
Basically, It's a patch for the Android Source. It patches the compiler flags so it's compiled with -O3 optimization (and others) to the WHOLE ROM, not just Kernel.
Why?
Android's default flag is -Os, which is "Optimize for Size". It makes sense because back then, phone storage are small. But phones has advanced, so we can optimize it further with -O3, even though it makes the ROM a little bit larger. This increased the performance up to 6X! (Remember, UP TO 6X, not TO 6X).
It could just be a placebo!
Well it could be, but I can assure you that it is not. Few days prior to building this ROM, I flashed another ROM, and switched to ART immediately. It took a long time to generate the "ART Cache", aka doing the AOT Compilation. I just tried again with this build, and it is INDEED much faster. It almost as fast as generating dalvik cache.
Why is it unrooted?
Because this build's target user is user instead of userdebug, user disables debugging modules and root, in exchange with higher performance. For now you can flash SuperSU zip (like I do) if you want root. Tell me if you prefer the CM built-in Superuser or SuperSU. Personally I prefer SuperSU, but I can make it pre-rooted if you guys want it (It only need one commit )
Credits:
CyanogenMod Team
@JustArchi
Summary:
CyanogenMod 11 (stable branch, milestone builds)
JustArchi Android Optimization (-O3 in the WHOLE ROM, not just kernel)
Compiled with Linaro 4.7
Unrooted
Odexed
ROM Downloads
Google Drive
GApps
You can use TK Gapps
XDA:DevDB Information
CyanogenMod 11 + JustArchi Android Optimization, ROM for the Google Nexus 4
Contributors
KcLKcL, JustArchi
Source Code: https://github.com/cyanogenmod/
ROM OS Version: 4.4.x KitKat
ROM Kernel: Linux 3.4.x
Based On: CyanogenMod
Version Information
Status: Stable
Current Stable Version: Milestone 11
Stable Release Date: 2014-10-09
Current Beta Version: 20140704
Beta Release Date: 2014-07-04
Created 2014-07-06
Last Updated 2015-07-07
Reserved
Changelog
Builds are based on the stable branch of CM, which is the base of Milestone builds. Although he CM team keeps the branch updated for bugfixes from the latest Milestone release so I try to keep with the latest source of the CM Branch, so I can ensure there will be no bugs on my build
Build 5.0 - 20141009
CyanogenMod 11 Milestone 11!
Build 4.0 - 20140916
CyanogenMod 11 Milestone 10!
Build 3.0 - 20140804
CyanogenMod 11 Milestone 9!
Build 2.2 - 20140715
Synced with latest CM Stable Branch (more bugfixes from the CM Team!)
Compiled with Linaro 4.7 for both ROM and Kernel to avoid problems introduced when compiling with 4.8 (hopefully)
That means, the lens blur FC has been fixed!
Build 2.1 - 20140711:
Synced source with the latest one in the stable branch (many bug fixes, including the video recording bug, is fixed). Basically, this is CyanogenMod 11 M8 with bugfixes cherry-picked
No changes from Build 2 apart from the bug fixes.
Build 2 - 20140709:
Based on CyanogenMod 11 M8! This ROM is now build based on the CM11's Stable Branch. Next build will be at CyanogenMod 11 M9, OR if there's something that I need to add there might be build 2.5.
ROM is now compiled with GCC 4.8! This should bring more performance improvements over Build 1. Kernel is still build with GCC 4.7 due to compile errors (you can flash another kernels to overcome this.
Applied ART Fix for building with GCC 4.8, so this build supports ART with no bootloop!
Please note that upgrading from Build 1 which was a nightly, is not recommended by CM due to release type difference, it's not recommended to upgrade from nightly build to a Milestone build. If you're feeling brave, feel free to dirty-flash over Build 1. And if Settings keep FCing when you dirty-flash, see this post
Build 1 - 20140704:
Initial Build
Latest CM Sources as of 04 July 2014
Applied JustArchi Android Optimizations V3
Using Google's GCC 4.7 Toolchain
Stock CM Kernel
Known bugs:
Please tell me if there's any and make sure you are in the latest build
KcLKcL said:
Wow, I'm such a noob, why is this ended up in General instead of Android Development? Could it be moved? Thanks~
Click to expand...
Click to collapse
PM a moderator to move the thread. Welcome to the community btw. ROM looks good.
Niceeeeee looked forward to find a ROM with @JustArchi commits.
Subscribed, downloading and will report issues.
TY!
CM built-in Superuser.
Thanks man! was really watching out for something like this since i heard of Archi's work!
Still i would REALLY prefer a userdebug (Superuser) rooted build, like official CM
I'm having issues flashing PA Google Keyboard.
file_getprop: failed at stat "/system/build.prop": No such file or directory
E:Error executing the updater binary in zip 'sdcard/ROMs/GApps/Google Keyboard - 20_06_2014.zip'
Error flashing zip 'sdcard/ROMs/Google Keyboard - 20_06_2014.zip'
blackbird5308 said:
Thanks man! was really watching out for something like this since i heard of Archi's work!
Still i would REALLY prefer a userdebug (Superuser) rooted build, like official CM
Click to expand...
Click to collapse
Actually, JustArchi said it's possible to keep root access while the build target = user. I will try to include CM's Superuser in the next build then! And I'd keep it user since it is said to improve performance by reducing debug codes which we usually don't need. (Personally, I don't, up to this point).
Konstantinos said:
I'm having issues flashing PA Google Keyboard.
file_getprop: failed at stat "/system/build.prop": No such file or directory
E:Error executing the updater binary in zip 'sdcard/ROMs/GApps/Google Keyboard - 20_06_2014.zip'
Error flashing zip 'sdcard/ROMs/Google Keyboard - 20_06_2014.zip'
Click to expand...
Click to collapse
Sounds like your recovery isn't compatible or the zip is broken. Error executing updater binary has nothing to do with ROMs usually
Also I'm using PA Gapps as well, although I don't flash Google Keyboard (I only flashed Mini Modular Gapps, Chrome, Google Camera, and Google Play Games addons). It works!
KcLKcL said:
Sounds like your recovery isn't compatible or the zip is broken. Error executing updater binary has nothing to do with ROMs usually
Also I'm using PA Gapps as well, although I don't flash Google Keyboard (I only flashed Mini Modular Gapps, Chrome, Google Camera, and Google Play Games addons). It works!
Click to expand...
Click to collapse
But it works on official Nightly builds.
Konstantinos said:
But it works on official Nightly builds.
Click to expand...
Click to collapse
Wait, I should've read the logs correctly.
It's says it can't find build.prop in /system, have you actually installed the ROM prior to flashing the GApps?
Try:
(Redownload all the zips if necessary)
Flash ROM
Flash GApps as possible
If Google Keyboard fails to be flashed again, try booting the ROM for the first time, and check if /system/build.prop is actually there (it should be, because I think Android wouldn't even boot without build.prop)
Reboot to recovery and try flashing Google Keyboard again.
with all due respect I see it as a normal CM, I see nothing different ... but appreciate your work and I thank you for sharing
KcLKcL said:
Wait, I should've read the logs correctly.
It's says it can't find build.prop in /system, have you actually installed the ROM prior to flashing the GApps?
Try:
(Redownload all the zips if necessary)
Flash ROM
Flash GApps as possible
If Google Keyboard fails to be flashed again, try booting the ROM for the first time, and check if /system/build.prop is actually there (it should be, because I think Android wouldn't even boot without build.prop)
Reboot to recovery and try flashing Google Keyboard again.
Click to expand...
Click to collapse
It worked when I flashed it after booting into the ROM.
to me it has worked for me the first
slipknot31 said:
with all due respect I see it as a normal CM, I see nothing different ... but appreciate your work and I thank you for sharing
Click to expand...
Click to collapse
Yes, as I said in the OP, this is fresh CM, but compiled with JustArchi Android Optimizations which makes the OS a lot faster!
I tested this during the day, I really couldn't find that much of smoothness than in other Roms without justarchi commits.
Am I missing something?
I am currently using stock ROM, its a bit slower (not noticeable for me) but not much of a huge difference.
How is other users experience?
KcLKcL said:
Actually, JustArchi said it's possible to keep root access while the build target = user. I will try to include CM's Superuser in the next build then! And I'd keep it user since it is said to improve performance by reducing debug codes which we usually don't need. (Personally, I don't, up to this point).
Click to expand...
Click to collapse
yeah, but with all the "odexed" thing? will that affect ART?
blackbird5308 said:
yeah, but with all the "odexed" thing? will that affect ART?
Click to expand...
Click to collapse
I may be wrong but,
I don't think it affects ART.
Read about odex vs deodex here http://forum.xda-developers.com/showthread.php?t=2200349
From my understanding odex is kind of similar to ART (but still the code needs to be compiled as you run the app, while on ART, it's already compiled when you installed the app), so it's faster then deodexed. But then, since the codes are already executed, it makes it hard to modify.
KcLKcL said:
I may be wrong but,
I don't think it affects ART.
Read about odex vs deodex here http://forum.xda-developers.com/showthread.php?t=2200349
From my understanding odex is kind of similar to ART (but still the code needs to be compiled as you run the app, while on ART, it's already compiled when you installed the app), so it's faster then deodexed. But then, since the codes are already executed, it makes it hard to modify.
Click to expand...
Click to collapse
That's why i was asking, dirtyflashing this over an official CM build and then reflashing the original CM will cause problem with the odexes maybe
blackbird5308 said:
That's why i was asking, dirtyflashing this over an official CM build and then reflashing the original CM will cause problem with the odexes maybe
Click to expand...
Click to collapse
Oh, yeah, you should not dirty flash from official CM. It will cause problem. Better grab Titanium Backup
What is this?
This a rebuild of Cyanogenmod 10.2 for I9100G where the source has been patched for the Stagefright vulnerability. The only code-wise difference: http://review.cyanogenmod.org/#/c/105496/
Build platform
CentOS Linux release 7.1.1503 (Core)
Linux polaris 3.10.0-229.11.1.el7.x86_64 #1 SMP Thu Aug 6 01:06:18 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
java-1.7.0-openjdk-1.7.0.85-2.6.1.2.el7_1.x86_64
java-1.7.0-openjdk-devel-1.7.0.85-2.6.1.2.el7_1.x86_64
Build date
8th of august 2015
Download
[md5sum] 13944c192abd11eca5ceee526bb6230a [file] cm-10.2-20150808-UNOFFICIAL-i9100g.zip [download] mirror 1 mirror 2
Please verify checksum after downloading!
Installation instructions
Via recovery & ADB
Boot to recovery, go to sideload mode and run "adb sideload cm-10.2-20150808-UNOFFICIAL-i9100g.zip"
Reboot
Via recovery
Put zipfile on sdcard on some other storage location accessible from recovery
Flash zipfile as you would any other ROM
Reboot
Note from me
I only built this release for myself to protect me from the stagefright vulnerability. I still use CM 10.2 because it works the fastest for my device.
Required notice
This software comes without any warranties and I cannot be held liable for any consequences by your use of this software. You agree to these terms when you download the software.
XDA:DevDB Information
Unofficial Cyanogenmod 10.2 for I9100G with stagefright fix, ROM for the Samsung Galaxy S II
Contributors
RedShift1
ROM OS Version: 4.3.x Jellybean
ROM Kernel: Linux 3.0.x
Based On: CyanogenMod
Version Information
Status: Snapshot
Created 2015-08-09
Last Updated 2015-08-09
any information?
Screenshot?
xn0live said:
any information?
Screenshot?
Click to expand...
Click to collapse
What is this?
This a rebuild of Cyanogenmod 10.2 for I9100G where the source has been patched for the Stagefright vulnerability. The only code-wise difference: http://review.cyanogenmod.org/#/c/105496/
Click to expand...
Click to collapse
http://forum.xda-developers.com/galaxy-s2/development/rom-cyanogenmod-10-2-official-nightly-t2379850
edit:
btw, you might want to start reading the posts before you start asking questions. You spam an awful lot in my opinion. In the future I'll just report your posts, if you didn't bother to read at least the first posts and the last pages.
its 4.3 version right? have that version sod or is it only by 4.1.2
xn0live said:
its 4.3 version right? have that version sod or is it only by 4.1.2
Click to expand...
Click to collapse
Cyanogenmod 10.2 = Android 4.3.1. I haven't had any screen of death issues.
RedShift1 said:
Cyanogenmod 10.2 = Android 4.3.1. I haven't had any screen of death issues.
Click to expand...
Click to collapse
is it the same
toppits posts?
you have screenshot from scrren on ?
xn0live said:
is it the same toppits posts?
you have screenshot from scrren on ?
Click to expand...
Click to collapse
It's exactly like toppits post, no I don't have any screenshots as that's redundant anyway (plus I already customized my only I9100G, I'm not going to revert that just for you). Like I said in the topic start, this ROM is code-wise CM 10.2 aside from the stagefright fixes.
stagefright fixes
what does it mean?
xn0live said:
stagefright fixes what does it mean?
Click to expand...
Click to collapse
https://blog.zimperium.com/experts-found-a-unicorn-in-the-heart-of-android/ This build has a fix for those problems.
only 180mb? we need to flash gapps or only full wipe then flash?
and is there came at the future updates?
Can you build CM12.1 for i9100g? Please.
Thank you for dev.
dacsang97 said:
Can you build CM12.1 for i9100g? Please.
Thank you for dev.
Click to expand...
Click to collapse
I would be happy if the dev focuses more in stability in this version rather than working on more recent updates. Believe me or not, this device isn't really capable in working smoothly above KitKat anymore actually. It's just too old and weak to run smoothly on newer firmwares. You can see why I stopped my RR development, I totally lost my passion in doing it anymore. What's the point of doing it when it cant even run smoothly on it with lags time by time. If I have time, I might learn building a kernel for this build. All I want is performance and stability rather than having more recent updates but with crappy memory management and laggy UI.
Once again, thanks to the dev for this build.
Diatomix98 said:
I would be happy if the dev focuses more in stability in this version rather than working on more recent updates. Believe me or not, this device isn't really capable in working smoothly above KitKat anymore actually. It's just too old and weak to run smoothly on newer firmwares. You can see why I stopped my RR development, I totally lost my passion in doing it anymore. What's the point of doing it when it cant even run smoothly on it with lags time by time. If I have time, I might learn building a kernel for this build. All I want is performance and stability rather than having more recent updates but with crappy memory management and laggy UI.
Once again, thanks to the dev for this build.
Click to expand...
Click to collapse
You try with Mokee Nightly, it is smooth , but battery drain. I believe you can fix RR on next build. Hope . Try your best. Let's do what's best for i9100g . Thank you.
dacsang97 said:
You try with Mokee Nightly, it is smooth , but battery drain. I believe you can fix RR on next build. Hope . Try your best. Let's do what's best for i9100g . Thank you.
Click to expand...
Click to collapse
I tried, on the first 3 days, it works extremely fine. Slowly, the lag increases, yesterday it was lagging so much that I have no choice but to switch to this rom. It's not even my primary device and I got only messenger and gapps installed. Let's see how it goes. =)
Ok, i try this rom , wait kernel from you.
I don't intend on releasing any ROMs or kernels of my own. I only built this ROM so I could keep on using CM 10.2 but have the stagefright vulnerability fixed. You can get decent kernels from other topics in this forum. I may accept patches to fix other bugs or security issues but I'm not intending this to be a long-term project.
Diatomix98 said:
I tried, on the first 3 days, it works extremely fine. Slowly, the lag increases, yesterday it was lagging so much that I have no choice but to switch to this rom. It's not even my primary device and I got only messenger and gapps installed. Let's see how it goes. =)
Click to expand...
Click to collapse
I have the same problem, on both my I9100 and my I9100G. Whenever free memory drops below 100 MB, the system becomes so sluggish that it is painful to use. Freeing memory helps but fills up too fast again. I think android needs 2 GB of RAM to run properly, which our devices don't have.
New rom for our device from China
http://m.romjd.com/Rom/Detail/64860
Haha
Diatomix98 said:
I would be happy if the dev focuses more in stability in this version rather than working on more recent updates. Believe me or not, this device isn't really capable in working smoothly above KitKat anymore actually. It's just too old and weak to run smoothly on newer firmwares. You can see why I stopped my RR development, I totally lost my passion in doing it anymore. What's the point of doing it when it cant even run smoothly on it with lags time by time. If I have time, I might learn building a kernel for this build. All I want is performance and stability rather than having more recent updates but with crappy memory management and laggy UI.
Once again, thanks to the dev for this build.
Click to expand...
Click to collapse
Dude You just said the truth! ^_^
Is this odex or deodex rom?
Hi,
I was hoping to get some clarification about what is going on with the camera on Android 6.
I think what from reading so far the camera needs some closed source blob, that is kind of like a driver for it, specifically for one version of the Android Kernel.
And this blob must exist for CAF/Qualcomm 3.4 Kernel used in the Stock rom and lately also Sony 3.10 Kernel used in the 5.1 AOSP build?
What I do not get is, why can none of the existing blobs not be used with the Kernel Android 6.0 AOSP requires.
And also: Is this just a matter of time until someone gets it working, or are we totally dependant on Sony to release the blob for the new kernel, or camera will never work.
Any insight would be nice
user822 said:
Hi,
I was hoping to get some clarification about what is going on with the camera on Android 6.
I think what from reading so far the camera needs some closed source blob, that is kind of like a driver for it, specifically for one version of the Android Kernel.
And this blob must exist for CAF/Qualcomm 3.4 Kernel used in the Stock rom and lately also Sony 3.10 Kernel used in the 5.1 AOSP build?
What I do not get is, why can none of the existing blobs not be used with the Kernel Android 6.0 AOSP requires.
And also: Is this just a matter of time until someone gets it working, or are we totally dependant on Sony to release the blob for the new kernel, or camera will never work.
Any insight would be nice
Click to expand...
Click to collapse
Hi,
first of all - sony released MM (6.0) blobs for 3.10 kernel on 2. February, so there are all things that developers need from sony. (including camera)
Existing blobs can't be used because all custom roms were using very old camera blob from 4.3 Jelly bean stock - newer blobs have some (DRM) protection on them so that they cannot be used. And unfortunately this old camera blob is not usable on MM, so CM team decided to wait for sony to release open source (they just call it open source, blobs are still closed source, but they are compatible with AOSP, unlike stock ones) one.
And why it still isn't working? Because there is still a lot of work ongoing on sonyxperiadev github, so I guess CM is waiting till the changes are complete.
Last thing I want to say - I'm not a developer, so I may be wrong. This is just how I understand the situation there.
SuperLamic said:
Hi,
first of all - sony released MM (6.0) blobs for 3.10 kernel on 2. February, so there are all things that developers need from sony. (including camera)
Existing blobs can't be used because all custom roms were using very old camera blob from 4.3 Jelly bean stock - newer blobs have some (DRM) protection on them so that they cannot be used. And unfortunately this old camera blob is not usable on MM, so CM team decided to wait for sony to release open source (they just call it open source, blobs are still closed source, but they are compatible with AOSP, unlike stock ones) one.
And why it still isn't working? Because there is still a lot of work ongoing on sonyxperiadev github, so I guess CM is waiting till the changes are complete.
Last thing I want to say - I'm not a developer, so I may be wrong. This is just how I understand the situation there.
Click to expand...
Click to collapse
I don't think that's entirely correct. Sony released blobs have never worked for AOSP camera. They have also not released anything for 3.10 kernel. I also don't think that jb blobs were used in up to LP5.1.1, as 4.3 camera never fully worked. If you look at CM gerrit, they say that they were able to have camera work once on MM with 3.4 kernel, but then they couldn't repeat it. Then, out of frustration and because they know Sonyxpdevs have abandoned 3.4 for good, CM have decided to switch to 3.10 kernel and wait for Sony to fix it. Good luck: Sonyxpdevs couldn't have camera work on ANY aosp rom...
So, the answer is, in my view: (i) potentially, we can have camera in MM with 3.4 kernel, but nobody is working on it in favor of 3.10; and (ii) not in our lifetime on 3.10. This is a pity and really has very little sense: Both 3.4 and 3.10 are hopelessly outdated (Linux is using 4.x already), so, why not to try to have it with 3.4, which worked fine up to MM? One of the reasons is that many developers just don't like CM (jealousy?), and CM isn't going to lift a finger for 2 devices (Z1 and Z1c), which they consider legacy devices. So, no luck. But in my view, M is crap (LP is crap too) LOL... Kitkat is still a lot more preferable...
optimumpro said:
I don't think that's entirely correct. Sony released blobs have never worked for AOSP camera. They have also not released anything for 3.10 kernel. I also don't think that jb blobs were used in up to LP5.1.1, as 4.3 camera never fully worked. If you look at CM gerrit, they say that they were able to have camera work once on MM with 3.4 kernel, but then they couldn't repeat it. Then, out of frustration and because they know Sonyxpdevs have abandoned 3.4 for good, CM have decided to switch to 3.10 kernel and wait for Sony to fix it. Good luck: Sonyxpdevs couldn't have camera work on ANY aosp rom...
So, the answer is, in my view: (i) potentially, we can have camera in MM with 3.4 kernel, but nobody is working on it in favor of 3.10; and (ii) not in our lifetime on 3.10. This is a pity and really has very little sense: Both 3.4 and 3.10 are hopelessly outdated (Linux is using 4.x already), so, why not to try to have it with 3.4, which worked fine up to MM? One of the reasons is that many developers just don't like CM (jealousy?), and CM isn't going to lift a finger for 2 devices (Z1 and Z1c), which they consider legacy devices. So, no luck. But in my view, M is crap (LP is crap too) LOL... Kitkat is still a lot more preferable...
Click to expand...
Click to collapse
well, you're not watching community here so much alviteri is woring on Z1 even he doesn't have the device and here you go.
And yes, they made camera working like two months ago on Lollipop on 3.10 kernel with aosp blobs and now - a few days ago even on marshmallow. It's only matter of time when it will work.
Check this: https://github.com/SonyAosp (there you have blobs and everything from alviteri)
SuperLamic said:
well, you're not watching community here so much alviteri is woring on Z1 even he doesn't have the device and here you go.
And yes, they made camera working like two months ago on Lollipop on 3.10 kernel with aosp blobs and now - a few days ago even on marshmallow. It's only matter of time when it will work.
Check this: https://github.com/SonyAosp (there you have blobs and everything from alviteri)
Click to expand...
Click to collapse
Well. As I said before, no one is working on making camera work with 3.4. Also, as far as blobs, according to davitery, "there is nothing to do" because of Sony: http://forum.xda-developers.com/showpost.php?p=64582482&postcount=33
optimumpro said:
Well. As I said before, no one is working on making camera work with 3.4. Also, as far as blobs, according to davitery, "there is nothing to do" because of Sony: http://forum.xda-developers.com/showpost.php?p=64582482&postcount=33
Click to expand...
Click to collapse
yes, this post was right on 31st December, but now is 6th February and the blobs ARE now available as I said before (and you can see screen with working camera in my previous post)
https://github.com/SonyAosp/platform_vendor_sony/commit/4f7409446779f371973035720935c36dbd09d7cc
SuperLamic said:
yes, this post was right on 31st December, but now is 6th February and the blobs ARE now available as I said before (and you can see screen with working camera in my previous post)
https://github.com/SonyAosp/platform_vendor_sony/commit/4f7409446779f371973035720935c36dbd09d7cc
Click to expand...
Click to collapse
I think the picture about camera is for Z3, which is not rhine. Also, if you look at the new blobs, there is nothing new for rhine devices; they just took out some older binaries, which are useless anyway. And this is consistent with Sony saying there won't be M for Z1. We will see, but I am not holding my breath.
Edit: I just downloaded the latest M blobs and everything in rhine and honami folders is dated August 2015. So, there is definitely nothing new for our device...
optimumpro said:
I think the picture about camera is for Z3, which is not rhine. Also, if you look at the new blobs, there is nothing new for rhine devices; they just took out some older binaries, which are useless anyway. And this is consistent with Sony saying there won't be M for Z1. We will see, but I am not holding my breath.
Edit: I just downloaded the latest M blobs and everything in rhine and honami folders is dated August 2015. So, there is definitely nothing new for our device...
Click to expand...
Click to collapse
Well, I didn't test it, so I don't know. But does it even make sense to release camera for Z3 and not for Z1 in the same package?
Anyway why do you think that they are useless? I tried that crdroid rom and it's not that bad (except for touchscreen driver and camera). And AOSP camera was definitely working on Lollipop (I personally tried it on build from erikcas), so it wouldn't make sense not to update it too when it requires only update their wrapper - and they can even use the one from Z3. (I don't really understand CM developers why they can't use Lollipop camera AOSP blob with simple wrapper to fit on Marshmallow, but I understand that it's more work and it's easier to wait)
I'm not that optimistic about Marshmallow officially, but I do think that they will release at least a bit usable blobs.
SuperLamic said:
Well, I didn't test it, so I don't know. But does it even make sense to release camera for Z3 and not for Z1 in the same package?
Anyway why do you think that they are useless? I tried that crdroid rom and it's not that bad (except for touchscreen driver and camera). And AOSP camera was definitely working on Lollipop (I personally tried it on build from erikcas), so it wouldn't make sense not to update it too when it requires only update their wrapper - and they can even use the one from Z3. (I don't really understand CM developers why they can't use Lollipop camera AOSP blob with simple wrapper to fit on Marshmallow, but I understand that it's more work and it's easier to wait)
I'm not that optimistic about Marshmallow officially, but I do think that they will release at least a bit usable blobs.
Click to expand...
Click to collapse
"make sense to release camera for Z3 and not for Z1 in the same package"
No, it doesn't, because Sony engineers do work on Z3 and NOT on rhine (Z1 and Z1c) devices.
You are confusing several things: the fact that camera worked with LP AOSP has nothing to do with M blobs, but rather the fact that Sony released a crippled AOSP camera for lollipop. This camera has nothing to do with M. And note, Sony released LP camera only after Android has moved to M.
Now, about M. The reason I think real blobs are not coming is that first Sony engineers must create stock M for rhine devices (and it ain't coming, because Sony said so). Then, they dumb stock down for custom roms. That's the usual way. But because M isn't coming to rhine devices, there is nothing to dumb down, unfortunately. And rhine is a different platform, as compared to Z3 and up. Not to mention that 3.10 kernel is the whole new deal on top of that. So, if there is a chance we could have a fully functional camera on M, it would rather be with 3.4, but no one seems to be working on 3.4 in favor of 3.10...
optimumpro said:
"make sense to release camera for Z3 and not for Z1 in the same package"
No, it doesn't, because Sony engineers do work on Z3 and NOT on rhine (Z1 and Z1c) devices.
You are confusing several things: the fact that camera worked with LP AOSP has nothing to do with M blobs, but rather the fact that Sony released a crippled AOSP camera for lollipop. This camera has nothing to do with M. And note, Sony released LP camera only after Android has moved to M.
Now, about M. The reason I think real blobs are not coming is that first Sony engineers must create stock M for rhine devices (and it ain't coming, because Sony said so). Then, they dumb stock down for custom roms. That's the usual way. But because M isn't coming to rhine devices, there is nothing to dumb down, unfortunately. And rhine is a different platform, as compared to Z3 and up. Not to mention that 3.10 kernel is the whole new deal on top of that. So, if there is a chance we could have a fully functional camera on M, it would rather be with 3.4, but no one seems to be working on 3.4 in favor of 3.10...
Click to expand...
Click to collapse
Ok I understand. But it's still android, isn't it? So camera API is not changed that much and there must be some way how to put another layer between the blob and kernel (the wrapper). Every time I see another device's tree updated to Marshmallow I see updated camera wrapper (only one or two lines changed). So I'm wondering why this isn't possible on our device, especially when CM was using a wrapper on stock blob.
SuperLamic said:
Ok I understand. But it's still android, isn't it? So camera API is not changed that much and there must be some way how to put another layer between the blob and kernel (the wrapper). Every time I see another device's tree updated to Marshmallow I see updated camera wrapper (only one or two lines changed). So I'm wondering why this isn't possible on our device, especially when CM was using a wrapper on stock blob.
Click to expand...
Click to collapse
Current stock blobs don't work on 3.10, and there is no stock for 3.10. So, there is nothing to wrap...
You should ask the devs why they prefer to bang their heads (in the dark) on a totally foreign to Sony 3.10, when they can work on adapting 3.4 to work with August M blobs.
optimumpro said:
Current stock blobs don't work on 3.10, and there is no stock for 3.10. So, there is nothing to wrap...
You should ask the devs why they prefer to bang their heads (in the dark) on a totally foreign to Sony 3.10, when they can work on adapting 3.4 to work with August M blobs.
Click to expand...
Click to collapse
so what's this? http://www.cas-online.nl/author/erikcas/
edit: my bad, I ment why is not possible to wrap aosp ones
SuperLamic said:
so what's this? http://www.cas-online.nl/author/erikcas/
edit: my bad, I ment why is not possible to wrap aosp ones
Click to expand...
Click to collapse
Sony has opened the entire camera (not just blobs) for Lollipop, so, because it is open and you know your "addresses", it will work with other kernels (like 3.10). This is different from having closed source blobs (with uknown addresses) wrap around for a particular kernel. When they release crippled camera for M, then it would be possible. But why would Sony release crippled camera for M if M isn't coming to Z1?
So, the answer is, in my view: (i) potentially, we can have camera in MM with 3.4 kernel, but nobody is working on it in favor of 3.10; and (ii) not in our lifetime on 3.10.
Click to expand...
Click to collapse
So anything AOSP 6.0 with working camera will never come to Z1 ?
Camera works, (of course with poor quality) in the latest cRDroid 6.0.1 build.
hey @optimumpro
have you seen this? https://github.com/SonyAosp/platform_vendor_sony/commit/43c92897de18e71d40aa4fe3da350ea19c5c7ba9
I can see there some new camera blobs for honami, what do you think?
SuperLamic said:
hey @optimumpro
have you seen this? https://github.com/SonyAosp/platform_vendor_sony/commit/43c92897de18e71d40aa4fe3da350ea19c5c7ba9
I can see there some new camera blobs for honami, what do you think?
Click to expand...
Click to collapse
@SuperLamic i hope it's have deal with kernel 3.10
from i read the discussion the old blobs can deal with 3.4 and not 3.10 but all favor 3.10
what do you think?
DectonX said:
@SuperLamic i hope it's have deal with kernel 3.10
from i read the discussion the old blobs can deal with 3.4 and not 3.10 but all favor 3.10
what do you think?
Click to expand...
Click to collapse
huh, I'm not really sure that I understand.
But - yes new blobs should not be compatible with old 3.4 kernel (though I didn't test it and I'm not planning on to)
so now all 6.0-MM roms use 3.10 kernel and new blobs. I don't think that it's that bad as optimumpro says. Many things improved, but it's true that we have to wait for it because of still ongoing development.
SuperLamic said:
huh, I'm not really sure that I understand.
But - yes new blobs should not be compatible with old 3.4 kernel (though I didn't test it and I'm not planning on to)
so now all 6.0-MM roms use 3.10 kernel and new blobs. I don't think that it's that bad as optimumpro says. Many things improved, but it's true that we have to wait for it because of still ongoing development.
Click to expand...
Click to collapse
Here is a fact: sonyxpdev team has NEVER had camera fully working on any aosp rom. So, what makes anyone think things are going to be different on MM? They won't. The only chance was to have it work with cm device trees and 3.4 kernel, but that ain't coming, because CM and everyone else switched to aosp trees and 3.10.
So, if you want MM, buy a new device.