Database Develop

[development]-kernel 3.4-freexperia

hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J

Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1

ETA
depending on problems and developers that will join
from 6 months to NEVER

This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).

Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)

Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.

To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus

I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.

All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!​

We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.

adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?

CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.

Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert

hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse

FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7

voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page

diff is 5mb on proper tag
pushed on github

nice to see so many developers trying to help

FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.

tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes

Android 4.4 Kit Kat Discussion Thread

This thread is for the developers to discuss the bugs and problems of the kitkat development for the p990.

Nice that you created a thread for kitkat! Really thanks
So for the progress on cm 11:
It is really difficult to find the cause of the dark screen, because we can't get an adb connection to working. The devices don't show up with adb devices
Maybe it is disabled at the moment
We can't take all changes from your slimroms repo, because cyanogenmod toke another way in handling backward compatibility. So for now we have a dark screen with cm 11 and no adb

Here are some of the threads from other tegra2 devices which I'm following:
Galaxy R: link
Galaxy Tab 10.1: link
Captivate Glide: link
Xoom: link
P990: link
Additional T2 devices where I didn't see any Kitkat related threads, yet:
Eee Pad TF101: link
Atrix 4G: link
All still suffer from the same problems, we need some proper workarounds (in frameworks/native most likely) to fix the hot reboots before we can move on to fix the smaller problems.
I've posted in some of them in order to help with other problems (like the set_metadata one where I send the fix to @DJNoXD as well), but I have no idea how to fix the hot reboots currently.
Personally I don't see a use in fixing various stuff as long as the device is too unstable thanks to the reboots (that's why you won't find any 4.4 thread from my so far).
I'm just collecting some information in this thread to have everything together.
Therefore some more stuff regarding the device stuck at boot which we faced earlier as well:
tonyp said:
The only way to fix the blobs would be an update by nvidia / the vendors - which isn't happening obviously.
So you need to workaround the limitations of the old EGL in the sources to re-add compatibility (which btw had to be done for Android 4.3 and partly Android 4.2 as well).
The reason that CM11 doesn't boot up for you is that CM hasn't merged the required patches.
The commits do exist on CMs gerrit though:
http://review.cyanogenmod.org/#/q/s.../android_frameworks_native+branch:cm-11.0,n,z
They're new implementations of the CM10.2 patches by arcee.
Note that in some first tests the new ones didn't work for me on my tegra2 phone anymore - somethings seems to be broken in them for the tegra2 architechture.
The OmniROM has (had? I think they partly reverted it here) used forwardports of the old CM10.2 patches - which the SlimROM has merged as well in a similiar manner.
But this only fixes booting, I still do have way to many hot reboots so some more stuff has changed in 4.4 - which I didn't manage to fix or workaround so far.
What we need is someone with that kind of deep hardware knowledge.
All in all: Blindly changing blobs or other libs won't help here at all. Just building against different framework/native trees won't either.
The surfaceflinger and probably some more stuff in frameworks/native needs to get worked on in code.
Currently there doesn't exist a tegra2 device which fully works to my knowledge - and I'm following a couple ones like the Galaxy R, the Xoom, the Transformer TF 101, the Atrix and the Galaxy Tab 10.1.
I'm working on the 2x, but have way too less time at the moment to dig any deeper into the code - while the current ROM boots (using my frameworks/native repo here) and has a working ril, wifi & storage it's nowhere near a daily driver thanks to frequent hot reboots.
Click to expand...
Click to collapse
Edit: Reminder: Do not spam in this forum section!
I will delete all "thanks" posts or similiar non-development related ones without a comment.

When i use the sources for frameworks native from @DJNoXD, i have less then 2 hot reboots a day. I even use it as daily driver with a work around for wifi.
I think if we could find the commits that broke the stability we could search for a work around or fix. I already tried it only for the sufaceflinger but i had no success, because it still worked properly, so it maybe is related to libgui or i think libui?
Took me hours for the surfaceflinger, so it will take even more time for all other in framework native. When i found some time during the week, i will try.
But KitKat is awesome related to RAM, Multitasking and performance.
Gesendet von meinem LG-P990 mit Tapatalk

Evervolv frameworks/native etc were no help getting the tf101 to boot omni. So far we're at Boot Animation
thx to
kishoreinme said:
Having the 3 perfhud .so files in /lib/egl/ causes this. Delete them and it boots
Click to expand...
Click to collapse
from this thread: http://forum.xda-developers.com/showthread.php?t=2517719&page=9
http://forum.xda-developers.com/showthread.php?t=2489841&page=7
Firtecy said:
When i use the sources for frameworks native from @DJNoXD, i have less then 2 hot reboots a day. I even use it as daily driver with a work around for wifi.
Gesendet von meinem LG-P990 mit Tapatalk
Click to expand...
Click to collapse
Is that the frameworks from slimrom or from https://github.com/DJNoXD/frameworks_av1 ?

dlumberg said:
Is that the frameworks from slimrom or from https://github.com/DJNoXD/frameworks_av1 ?
Click to expand...
Click to collapse
These are the repos that I use for slimrom:
https://github.com/p990-slimrom/

Here is the GalaxyR Omni 4.4.2 development link
http://forum.xda-developers.com/showthread.php?t=2576793

Eeeeh, have I been gifted with a special P990?
I've flashed Tonyp's 4.4 build named cm-11-20131213-UNOFFICIAL-p990 and I am pretty much facing no bugs. Only bug I could find on this fine evening was that USB doesn't get mounted, it charges when connected though.
Sound works, camera works, external SD card works, WiFi works, I bet GPS works but testing that will have to wait till the morning. All of this is on a clean CM11 build without doing any modifications at all. I too am still shocked over this and since I couldn't believe it myself, so I figured I'd post a video bringing this to light.
Short YouTube footage of my P990 running KitKat: YouTube
Could someone do a full wipe and see what they come up with by flashing that same build? It seems rather surreal if 4.4 only works this well on just my phone.
Please note, I have not been under the developmental processes of this project. This is simply testing - all credits to the developers!

USB tether will not work under windows because there are no drivers found. And it works fine under linux. How to fix the hardware id (vid,pid)?
Sent from my XT875 using XDA Premium 4 mobile app

Topics and questions regarding compiling AOSP based Roms vs other sources like CM

I have decided to rework the thread to ovoid any confusion as the intent of posting this thread was to ask questions about compiling custom Roms from AOSP source that someone like myself who gained their development experience on other devices that building from pure AOSP code was not an option and are not as familiar working with AOSP. In the past my own experience comes from using and modifying for example the Cyanogenmod source so after attempting to now base my Rom on AOSP this time around with Lollipop have run into a few unfamiliar differences. As each question or topic is addressed I will update the Op. The hope is not only will I find solutions or answers to my own questions but that others in the same position will also be able to find use of the discussions posted in this thread.
Compiling the AOSP source into a format that can be safely flashed using a custom recovery. This was a 3 part question the first was just simply how to compile AOSP in a format other then .img files that can be flashed using a custom recovery without the need of flashing through fastboot or needing to use the adb sideload option.
1, Compiling AOSP into the for of an update.zip.
This was answered in short by know.patience by suggesting to use the “make otapackage” command in place of "make" to start the build. Was also made aware that a few modifications would need to be made to avoid producing an update package that does not use the new block format but instead the old style zips we are most used to seeing.
2, Now can create an update.zip using the “make otapackage” command ran into an issue that by flashing the update.zip produced would in the process replace the custom recovery used to flash with the Nexus Stock recovery. This was answered by Lethargy who suggested and provided a Link for the following commit.
For getting rid of the AOSP recovery:
https://github.com/Lethargy/android_build/commit/48521e167c642db76c9d4f52b1c63f9abc7f707f
https://github.com/Lethargy/android_build/commit/1d9224bd45ef2b4f5601a157de2bfe3bb1c95558
3, Now can create an update.zip using the “make otapackage” and after applying the above commit are now able to flash the update.zip without replacing the recovery Lethargy also provided links for the following commits.
To get rid of the block-based zip format:
https://github.com/Lethargy/android_build/commit/4d458300d935a3a9d893a590286cb578dcf54db2
You'll also want to make sure you have this commit so it doesn't flash awfully slow in recovery (8~ minutes, but only around 1-2 minutes with this commit):
https://github.com/Lethargy/android_system_extras/commit/52f8d5fc3edfacd112827d0a41516c1dc5f4a468
This one isn't required but you may as well:
https://github.com/Lethargy/android_build/commit/242be9ae4f05e3cb1d39d635cac7147ff904700c
Compiling using the AOSP Master branch vs release branches. In following the directions provided on the Google development site are given the command for downloading the source code using the Master branch. Using the Master branch as apposed to a release branch such as android-5.0.2_r1 or lower have found that the source compiles just fine but have run into one issue and just a general question that a little explanation would be helpful for general understanding of the AOSP Master branch.
The issue is that after flashing a Rom compiled using the Master branch everything in the Rom works as expected other than the radio. I have so far using the same exact vendor blobs as compiling a release branch have not had a signal and baseband version is listed under about phone as unknown.
The general question is that the android version listed compiling a Rom using the Master branch is version 5.0.50.50.50.50. In general I have yet to understand what this version number represents and very little to no information available via the Google Box.
Between the both I now wounder if the Master branch is intended for actual use or if so what changes are required so the baseband version is recognized and radio / Ril will work?
Quick Answer:
Google first commits new code into master and then is later tagged with an update for realease so in generall many things can be broken and the master branch is and not intended to be stable so if building from master expect that things will be broke or buggy.
Compiling Rom and Kernel together. For those of us again used to compiling using say the CM code are now used to compiling the Kernel along with the rest of the code. I know it is easy to just compile the Kernel and include in the device tree but for those of us who would still like the Kernel compiles with the rest of the code there is no information available on the Google Developers site for doing so and there seems to be a few differences as have tried just using the lines used in the CM Hammerhead device repository. I have come across these commits from Cl3Kener that should help. Hate posting other developers code but is on Github so is there for the public at large. So far have only tested as is so will update if finding not all changes are necessary or can be modified.
Inline Kernel Building
https://github.com/OptiPop/device_lge_hammerhead/commit/7de8fd95b6df16cb6311161d5048874d69cf1cb1
https://github.com/OptiPop/device_lge_hammerhead/commit/87768896f4eb8fcd989ce3b8492ca65305513851
https://github.com/OptiPop/device_lge_hammerhead/commit/5460eb3aa76ea5d813f64a3b3bab6ace1be6de68
Adding Pre-Built APK's
Seems Sprint users need a few apk's for updating prl and what not that are included into the Stock release but are not part of the AOSP code. For some reason through vendor or even device have tried adding these apk's into the build. First try I created a sprint vendor section and received a few errors untill learning would need to add sprint into a vendor white list found in build. Will post link to file later. After found the extra "Services.jar" I found in the stock image not found in the aosp compiled Rom did copy into the build but the apk's had not. Looking in the other vendor blobs noticed lge adds "qcrilmsgtunnel.apk" so followed the example and even tried just adding the other spk's into lge expanding the list used for adding in "qcrilmsgtunnel.apk" but still no luck. Also have tried adding through the device files for Hammerhead just to get them into the Rom for testing and still no luck. If this was CM or any other Rom not using pure aosp this would have been a 5 minut project so need to do some aditional homework.
Again think this thread could be a good resource for developers who are new to building their Roms around AOSP so wanted to include everything I run into during the process of moving away from using a heavily modified CM based code as the base of my Rom to using AOSP in its place so developers who are or in the same process or for those in the future can use as a resource to quickly adjusting. I have been building CM based Roms like Starship for years and after hours of working on other aspects to suddenly be stumped by these small differences between platforms can be very frustrating.

to the OP:
answer to your first question comes in two parts.
a) use 'make -j# otapackage' will generate a zip that is flashable in custom recovery.
b) if you plan on adding other files after the zip is made, you will need this info here:
https://github.com/android/platform_build/commit/26e6619c37e294fe2ee63aaa759e0ac861775ce8
There are some modifications needed to generate the OG zip files instead of the new "block" format.
Google hasn't released the 5.0.1 image for the N5 but that doesn't mean you can't build it and install it yourself. I'm running it and it seems okay to me so far although I'm hardly an expert.

simms22 said:
op.. this section is only for developers, to get work done. if you have questions, they belong in the q&a section. you arent new, you should know this. again, this section is only for developers, mot for the normal xda folk to post questions. you have a q&a section just for asking questions. please, ask a mod to move your thread there.
Click to expand...
Click to collapse
I am building a customized AOSP Rom I am interested in sharing so was looking for help or direction in creating an update zip that can be flashed in a custom recovery like TWRP. I am not used to compiling AOSP and with the help of know.patience in the first reply am now able to compile an update.zip I can flash in TWRP but in doing so it also replaces TWRP with the Stock recovery. I have still been using the .img files to flash personally but am still trying to figure out how to solve the recovery replacement issue. I still have other features I am adding and testing before I would like to post my work but before I get to that point I still need to figure out my recovery replacement issue. Maybe using the words personal use may have been confusing but at the moment until ready I have only been using my work personally but would like to at some point post and share. I also have work that is not AOSP based I am sharing in the Android Development section but I have been building CM and other source based Roms and sharing for years. This is the first device I have been able to build AOSP and still have a few things to figure out before sharing any of my AOSP based work. I am otherwise not sure why you think these are questions for general Q&A.
I started this thread in Android Development as there was only about 4 posts in this section and I see many AOSP based Roms in Android Development who's developers obviously know the answers to my questions so tried to get away posting there in hope one of these developers could help or like in the first response point me in the direction of a commit before the thread was moved by a mod into this section. Do you think someone in the general Q&A section is better equipped to help answer questions about compiling an AOSP based Rom in the form of an update.zip that can be flashed in TWRP without also replacing TWRP with the Stock recovery?? Would also be nice knowing what changes in the code need to be made in compiling an old style update.zip that does not use the new block format. This would be a bonus but overall not %100 needed as instead of moving files around after the code has been compiled have added init.d support and first have all the files I want moved into a staging directory and then form an init,d bash script to move the files during first boot and remove those that are not needed like this example I used in my CM based version of the Rom I am trying to update for AOSP for 5.0.
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/app-update
https://github.com/Starship-Android/android_device_starship-common/blob/cm-11.0/cleanup
I must seriously be underestimating the knowledge and in general the types of questions being asked and answered in the general Q&A section.
Honestly if not for the amount of times thanked I would think this comment was not so much about helping or community but more about someone trying to puff themselves up by trying to appear important by making decisions about what questions are worthy of being asked but judging by the number of times they have been helpful I am thinking its either a case of not reading or understanding the question being asked or my own inability to express my questions in the proper manor. Either way its definitely not about taking up resources in a section with less than 10 total posts. The frustrating part as a community as I like to believe we are all in is that why I worked on other parts in updating my Rom had expected that at least more than one developer out of all the AOSP based Roms posted in the development section would have helped me with this one part. Its not like I am asking how to be a developer just a resource to help with two simple things I am sure I could have figured out and will most likely still figure out without any help. Overall my thoughts behind posting this question was that why I am working to figure out something a bit more time consuming at least more than one person would be helpful enough to copy and past a commit.
XDA is weird in that with other devices all the developers would join a team and start a shared group of repository’s for one another to use in trying to make the best possible experience and options for everyone. For example in the op I posted an example of hours of work I did showing what libraries are needed by one another just so others could use it also in trying to port as much as possible for in that case the Galaxy Mini. Then with other devices like seems to be the case with the N5 its all about competition and what I am starting to call the smartest person in the room syndrome. Its just a shame there are only 5 maybe 6 threads posted in this section and I think that says allot about the community in general. So many good things could come about if we just tried to be helpful and pull as much knowledge together as we could. Anyhow think its time for ending this rant.

chairshot215 said:
compiling an AOSP based Rom in the form of an update.zip that can be flashed in TWRP without also replacing TWRP with the Stock recovery?? Would also be nice knowing what changes in the code need to be made in compiling an old style update.zip that does not use the new block format.
Click to expand...
Click to collapse
To get rid of the block-based zip format: https://github.com/Lethargy/android_build/commit/4d458300d935a3a9d893a590286cb578dcf54db2
You'll also want to make sure you have this commit so it doesn't flash awfully slow in recovery (8~ minutes, but only around 1-2 minutes with this commit): https://github.com/Lethargy/android_system_extras/commit/52f8d5fc3edfacd112827d0a41516c1dc5f4a468
This one isn't required but you may as well: https://github.com/Lethargy/android_build/commit/242be9ae4f05e3cb1d39d635cac7147ff904700c
For getting rid of the AOSP recovery: https://github.com/Lethargy/android_build/commit/48521e167c642db76c9d4f52b1c63f9abc7f707f then https://github.com/Lethargy/android_build/commit/1d9224bd45ef2b4f5601a157de2bfe3bb1c95558

Lethargy said:
To get rid of the block-based zip format: https://github.com/Lethargy/android_build/commit/4d458300d935a3a9d893a590286cb578dcf54db2
You'll also want to make sure you have this commit so it doesn't flash awfully slow in recovery (8~ minutes, but only around 1-2 minutes with this commit): https://github.com/Lethargy/android_system_extras/commit/52f8d5fc3edfacd112827d0a41516c1dc5f4a468
This one isn't required but you may as well: https://github.com/Lethargy/android_build/commit/242be9ae4f05e3cb1d39d635cac7147ff904700c
For getting rid of the AOSP recovery: https://github.com/Lethargy/android_build/commit/48521e167c642db76c9d4f52b1c63f9abc7f707f then https://github.com/Lethargy/android_build/commit/1d9224bd45ef2b4f5601a157de2bfe3bb1c95558
Click to expand...
Click to collapse
Thank you this is well beyond what I was looking for and don’t worry I make it a point not to send out PM's with questions that can be helpful for others as well. Otherwise would have blown up the AOSP Rom posters in development but thanks for the information.

chairshot215 said:
.. and don’t worry I make it a point not to send out PM's with questions that can be helpful for others as well..
Click to expand...
Click to collapse
If you mean "I'll probably ignore you if you try asking for support over PM.", that's part of my forum signature.
If you need anything else feel free to @‬‬mention me in a thread, though.

I reworked the Op to avoid confusion as Mods have been moving the thread around into different sections. I personalty believe these questions are more geared towered development than general Q&A but at least at the moment I appear to be wrong about that. Never know though as in the past one day one of the mods may decide to move the thread back into its intended location but until then I guess these topics will be of better use to general users than developers.

chairshot215 said:
I reworked the Op to avoid confusion as Mods have been moving the thread around into different sections. I personalty believe these questions are more geared towered development than general Q&A but at least at the moment I appear to be wrong about that. Never know though as in the past one day one of the mods may decide to move the thread back into its intended location but until then I guess these topics will be of better use to general users than developers.
Click to expand...
Click to collapse
You should include the other commit (https://github.com/Lethargy/android_build/commit/1d9224bd45ef2b4f5601a157de2bfe3bb1c95558) which fixes building since the first one results in "IndentationError: unexpected indent".

Lethargy said:
You should include the other commit (https://github.com/Lethargy/android_build/commit/1d9224bd45ef2b4f5601a157de2bfe3bb1c95558) which fixes building since the first one results in "IndentationError: unexpected indent".
Click to expand...
Click to collapse
Thanks for the heads up, when testing these I also cherry picked a few other things that looked related. Have to double check but may have forked the repository’s from you so would receive credit if anyone decided to look over my repository’s. Well overall my personal Github has been pretty bare as in the past most work was done on more obscure Virgin Mobile devices with only a few developers so we would pretty much create an organization for all the developers to use.
https://github.com/MTDEV-CM7
https://github.com/MTDEV-CM10
https://github.com/vmobi-triumph
https://github.com/MTDEV-KERNEL
https://github.com/MTDEV-MIUIv4
https://github.com/MTCM9
https://github.com/MTCM10
https://github.com/HTCCM9
https://github.com/HTCCM10
https://github.com/HTCStarShip
https://github.com/HTCUbuntu
https://github.com/vmobi-shooter
https://github.com/vmobi-gogh
These days have been keeping everything under Starship-Android.
https://github.com/Starship-Android
Have 2 other members listed who I had worked with in the past but has otherwise been a solo organization with one of the other members who decided on going with the Moto X and Verizon over the N5 and showed little interest in his 2012 version of the N7 as it was intended for being a Nexus only device line up and the second being my Kernel Guru from a few devices back who mainly joined to help me out with a few things but ultimately what I am getting around to is this is the first time working %100 solo. Have to say without having anyone to bounce off ideas and share findings with things definitely move much slower and take a bit of getting used to. Is also the reason for starting threads like this. Most of this stuff looking in the developer section appeared to be pretty common knowledge but having never worked from pure AOSP before was slowing down other development for about a week just to figure out what seemed like half the community had already known and with what probably took at the most 5 or 10 minutes of copying and pasting commits probably saved me a weekend of sifting through github and testing. I hope by creating a thread like this will be able to do the same for others.

Hi guys,
Anyone manage to fix RIL problems with master branch?
I also build AOSP roms so for sure i will hangout here
Sent from my AOSP on HammerHead using XDA Free mobile app

malcho said:
Hi guys,
Anyone manage to fix RIL problems with master branch?
I also build AOSP roms so for sure i will hangout here
Sent from my AOSP on HammerHead using XDA Free mobile app
Click to expand...
Click to collapse
Never tried.

ODEXED
i am successfully build cm12 with fully odexed. now i like to odex some prebuilt apk also but LOCAL_DEX_PREOPT=true not odexing prebuilt apk. can somebody help me? already DEX_PREOPT=true working fine.

soorajj said:
i am successfully build cm12 with fully odexed. now i like to odex some prebuilt apk also but LOCAL_DEX_PREOPT=true not odexing prebuilt apk. can somebody help me? already DEX_PREOPT=true working fine.
Click to expand...
Click to collapse
Why do you need to odex a prebuilt apk?
Not sure if what you want is even possible.
But if odexing your prebuilt apk is necessary then why not odex it then include the .odex with the prebuilt?

Lethargy said:
Why do you need to odex a prebuilt apk?
Not sure if what you want is even possible.
But if odexing your prebuilt apk is necessary then why not odex it then include the .odex with the prebuilt?
Click to expand...
Click to collapse
suppose i want to odex gapps. how to?

malcho said:
Hi guys,
Anyone manage to fix RIL problems with master branch?
I also build AOSP roms so for sure i will hangout here
Sent from my AOSP on HammerHead using XDA Free mobile app
Click to expand...
Click to collapse
Nothing so far, I downloaded the master and 5.0.2_r1 branches and have loaded both in meld for looking over differences but have not yet identified from the dif between the 2 branches that is responsible for ril working in release branch but not master. Still have allot to look over though still. Still have not found a decent explanation of the master branch to know if its recommended to build from but still just for Knowledge sake am interested in knowing. At first thought maybe apn's but not so sure with baseband also listed as unknown from my Master branch builds.

chairshot215 said:
Nothing so far, I downloaded the master and 5.0.2_r1 branches and have loaded both in meld for looking over differences but have not yet identified from the dif between the 2 branches that is responsible for ril working in release branch but not master. Still have allot to look over though still. Still have not found a decent explanation of the master branch to know if its recommended to build from but still just for Knowledge sake am interested in knowing. At first thought maybe apn's but not so sure with baseband also listed as unknown from my Master branch builds.
Click to expand...
Click to collapse
As far as i know all the patches goes to master branch then from this branch ,if they are ok,is distributed to lower branches.I also didn't find info why is named as 5.0.50.50.I will try to investigate this ril problem

malcho said:
As far as i know all the patches goes to master branch then from this branch ,if they are ok,is distributed to lower branches.I also didn't find info why is named as 5.0.50.50.I will try to investigate this ril problem
Click to expand...
Click to collapse
Thanks will definitely update the Op with any findings. Was very surprised to find the thread again as it has now been moved 4 times by 4 different Mods, some bounce it to general Q&A and then is bounced back here by another. I understand its not comprised of the most advanced development topics but with that said is still way more advanced than the topics being discussed by general users over in the general Q&A section. I had just thought it would be a nice one stop place for learning the basics of AOSP development. With the constant moving and scolding messages being received one would think the threads very existence is up there with crossing the streams and threatens the existence of Android development.

@chairshot215 Thank you for starting this thread. Thank you @Lethargy for all of your insight. I like to do my own perosnal builds every once in a while for my nexus devices. What I have observed over the years is that the Master Branch will sometimes have funky version numbers like you have described. One thing to consider is what @malcho mentioned. If all commits indeed go there first before the respective branches(although this may not entirely be the case), then it is likely that some things may be broken in the master branch from time to time, hence the ril problem. I think with the galaxy nexus I ended up running into issues from time to time with the master branch, and from there learned to build for specific branches/tags. For instance, there are times when items within a specific branch will be ahead of master in some areas and behind it in others, as in this link to platform_build for lollipop release https://github.com/android/platform_build/tree/lollipop-release. So with that, it is probably in our best interests to just use specific branches.

Milly7 said:
@chairshot215 Thank you for starting this thread. Thank you @Lethargy for all of your insight. I like to do my own perosnal builds every once in a while for my nexus devices. What I have observed over the years is that the Master Branch will sometimes have funky version numbers like you have described. One thing to consider is what @malcho mentioned. If all commits indeed go there first before the respective branches(although this may not entirely be the case), then it is likely that some things may be broken in the master branch from time to time, hence the ril problem. I think with the galaxy nexus I ended up running into issues from time to time with the master branch, and from there learned to build for specific branches/tags. For instance, there are times when items within a specific branch will be ahead of master in some areas and behind it in others, as in this link to platform_build for lollipop release https://github.com/android/platform_build/tree/lollipop-release. So with that, it is probably in our best interests to just use specific branches.
Click to expand...
Click to collapse
Thanks for the response and have definitely learned its better building from branches with a release tag. Still very curious why and how the branches are structured so thanks for the explanations.

Way totally off topic for the thread but landed a brand new SSD and decided to install everything fresh. After everything was set back up and wanted to start building I ran my usual,
-j'grep 'processor' /proc/cpuinfo | wc -l'
a very old habit before fully understanding what number to use after -j so used grep to figure it out based on Googles recommendation. The command did not work so removed the grep and just made it -j4 but also with 0 success. At first just figued I missed somthing setting everything back up and "make" is just not working but wrong again as running "make" command without -j of any number works just fine.
Also tried this with CM12 as I am doing 2 versions of my Starship Rom. One from AOSP and one using CM. Figured AOSP would be special for Nexus users why also having a version for CM I can make most changes by adding a Starship Device Tree could easily port the Rom to any device running CM supported or not.
https://github.com/Starship-Android/android_device_starship-common/tree/cm-12.0
Also found why compiling CM that -j also results in an error
Invalid lunch combo: cm_hammerhead--j4
No such item in brunch menu. Try 'breakfast'
So far have not found anything using the Google Box so figured may as well ask. If have not figured out by now I have no shame in asking questions. Oddly enough that is for things that are probably relatively simple. Took a better part of a week figuring out how to start CM using the Now Launcher and setting up init.d bash scripts for moving around and replacing libs after learning the Gapps package includes libs that will not work so the solution needed to be that the CM Gapps package libs needed to be replaced with either stock or libs pulled after installing the Now Launcher from the Play Store after flashing Gapps and the Rom staring. Also then what if user updates and wipes the system partition after the new and updated llibs have been moved into place. Anyhow point of story is things like this I will just figure out without bothering anyone but for the cant believe I need to stop what I am working on to figure out something most likely very simple and can be answered with very little time spent I have no shame in just asking. Not that someone else’s time is less important but like I have mentioned before is frustrating just after spending hours or days figuring out something asked in dozens of threads is just frustrating getting caught up or loosing momentum and thought processes over something so simple there are little resources available. Also I assume most devs have the same experience when you have an idea or thought behind resolving an issue that once you stop and change direction it just sometimes never comes back and that short time you had I guess can be called an epiphany is gone once going back. Otherwise thats how I justify asking dumb ars questions.

[DEV][G925F] CyanogenMod 12.1 Development

Hello there, it's time to get this rolling somewhere.
This is a Development-Thread. Please don't post if you aren't a developer.
What this IS
This is a Development thread, a platform for developers to discuss the development of CyanogenMod for the G925F. It's made so that we can get this working, fix up the problems - because there will be severe ones - and achieve a working official Rom at some point.
At the moment it's @OldDroid and me with help, but it would be awesome if interested devs would join in so that we can make this a team effort.
In short, it's a Dev-Thread in a dev section.
Right now it doesn't work and I'm not sure that it will work.
What this IS NOT
This is NOT a working Rom. Not even close. I can only link you to the kernel repo and soon to device and vendor, as they are almost completed for a first try.
And yes, there is no download link for the Rom. Because there isn't anything you could download yet.
This is also NOT intended as a Q&A thread. Please don't ask if your variant will be supported, I will respond by trolling. Firstand only priority is to get this running, then we'll talk about variants.
And ETA is an evil word with no meaning here. I work slowly, deal with it
Where are we currently?
Much further than a day ago
Thanks to @OldDroid, we've teamed up
All the links you want (minus the download link :angel
device: (soon, almost complete)
https://gitlab.com/mythos234/device_samsung_zeroltexx
vendor:
https://gitlab.com/mythos234/vendor_samsung_zerolte
kernel:
https://gitlab.com/mythos234/zerolte-kernel-CM
Once available, buggy alpha builds will be posted here
///
vendor and device will soon be pushed to my github
​

Reserved

i'll join you ... also started working on cm12.1 for s6 edge 5 days ago (currently in england with my school class)

vendor is setup
OldDroid said:
i'll join you ... also started working on cm12.1 for s6 edge 5 days ago (currently in england with my school class)
Click to expand...
Click to collapse
Welcome aboard then
vendor is finally setup and good to go!
https://github.com/mythos234/vendor_samsung_zerolte
It's apparently not without some minor casualties, but we got it. Huge thanks to @RaymanFX, he's helping me, since I'm not that much into CM building yet and I'm also basing this project on his CM for the N910C, which's 5433 is darn similar to our 7420, so we got a pretty good base to begin with.

add me as participant to the repos ^^
https://github.com/OldDroid

OldDroid said:
add me as participant to the repos ^^
https://github.com/OldDroid
Click to expand...
Click to collapse
Done for all the 3 of them

Looks like I killed Bluetooth for now (lol). Other than that it's slow but steady progress.

mythos234 said:
Looks like I killed Bluetooth for now (lol). Other than that it's slow but steady progress.
Click to expand...
Click to collapse
What do you mean "killed"? Killed the chip or wiped the MAC addr. or something?

nasko_spasko said:
What do you mean "killed"? Killed the chip or wiped the MAC addr. or something?
Click to expand...
Click to collapse
I'm currently building the Rom with completely removed Bluetooth support

First Build is compiled and ready for a test.. But I can't install the zip. This would be hillarious if it wasn't so annoying

mythos234 said:
Besides I said it can't be installed Hard to test something you can't even install
Click to expand...
Click to collapse
I think that there was a mistake in the partition sizes.. /system was declared as 4.1GB, but it's only 3.6GB. Recompiling with a new value, should be able to flash it then

Good luck develop without documentation for exynos chipset.
But can you tell us more in details how porting works and what are the challenges with it.
Is it hard to develop a rom without samsung binary files and drivers? I know they are proprietary and closed soruce.
If just Samsung could be more developer friendly like Sony.
We can request source for closed binaries here, http://opensource.samsung.com/reception/receptionSub.do?method=inquiryView, most likely they wont answer

Aircondition said:
Good luck develop without documentation for exynos chipset.
Click to expand...
Click to collapse
The lack of drivers makes this a fun exercise almost Where's be the challenge if everything was easy...?

Aircondition said:
Good luck develop without documentation for exynos chipset.
But can you tell us more in details how porting works and what are the challenges with it.
Is it hard to develop a rom without samsung binary files and drivers? I know they are proprietary and closed soruce.
If just Samsung could be more developer friendly like Sony.
We can request source for closed binaries here, http://opensource.samsung.com/reception/receptionSub.do?method=inquiryView, most likely they wont answer
Click to expand...
Click to collapse
I can't say what the challenges here will be, since I couldn't manage to even flash it yet - Second build is compiling since hours now. For now it's using all the proprietrary stuff we managed to grab and some additional stuff from the 5433 CM. But without booting it's hard to tell what won't work and might present a challenge ^^ From what I saw it'll be tough to just get the modem running. The hard part is to write the drivers yourself

mythos234 said:
I can't say what the challenges here will be, since I couldn't manage to even flash it yet - Second build is compiling since hours now. For now it's using all the proprietrary stuff we managed to grab and some additional stuff from the 5433 CM. But without booting it's hard to tell what won't work and might present a challenge ^^ From what I saw it'll be tough to just get the modem running. The hard part is to write the drivers yourself
Click to expand...
Click to collapse
It's interesting that you can use drivers from 5433, which is a 32bit platform. Most drivers are not compatible when you switch from 32bit to 64bit if I am right?
Sent from my SM-G920F using Tapatalk

lch920619x said:
It's interesting that you can use drivers from 5433, which is a 32bit platform. Most drivers are not compatible when you switch from 32bit to 64bit if I am right?
Sent from my SM-G920F using Tapatalk
Click to expand...
Click to collapse
As a base to know how to do it, obviously we can't just use drivers for a different chipset

Updated the /system size in the BoardConfig and at least it flashes. But it doesn't want to boot for some reason yet.

mythos234 said:
Updated the /system size in the BoardConfig and at least it flashes. But it doesn't want to boot for some reason yet.
Click to expand...
Click to collapse
If you have the 5.1.1 boot loader and are using 5.0.2 as a base. Sboot will not boot it. As a fyi. It checks Linux versions.

-Mr. X- said:
If you have the 5.1.1 boot loader and are using 5.0.2 as a base. Sboot will not boot it. As a fyi. It checks Linux versions.
Click to expand...
Click to collapse
Both is 5.1.1 and Sboot seems to clear the boot as well, everything seems to go fine, it just doesn't boot. :/ Trying with building the kernel during the build itself instead of using a prebuilt one and see how that goes

mythos234 said:
Both is 5.1.1 and Sboot seems to clear the boot as well, everything seems to go fine, it just doesn't boot. :/ Trying with building the kernel during the build itself instead of using a prebuilt one and see how that goes
Click to expand...
Click to collapse
I would personally flash an Engineering boot loader while doing this, to ensure version checking is not the issue.

[XZ][F8331/2] AOSP Pie builds [Stable] [Updates]

New build up at sx.ix5.org, use version 2018-10-30.
Changelog here: https://sx.ix5.org/changelog.html
Install guide: Flashing AOSP on Xperia XZ
XDA:DevDB Information
AOSP Pie based on Sony Open Devices Project, ROM for the Sony Xperia XZ
Contributors
local__hero, fastbooking, oshmoun
Source Code: https://git.ix5.org/felix/local-manifests-ix5/src/branch/ix5-customizations
ROM OS Version: 9.x Pie
ROM Kernel: Linux 4.x
ROM Firmware Required: .184 / .192
Based On: AOSP
Version Information
Status: Nightly
Created 2018-11-09
Last Updated 2019-05-17

Reporting bugs
Important: Read the bug list before posting. Anyone can add bugs to the list, just follow the rules.
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread
Don't make me ask you for logs every time!​
I will repeat the rules again here:
Rules:
New bugs must include version where error popped up and which oem version you are using
Only reproducible errors
Should include adb logcat (linked in a pastebin service like https://del.dog)
Must include clear description what is wrong
If it is a visual/SystemUI bug, only report it here
If it is an internal bug(e.g. fingerprint crashes device), report it to the Sony bugtracker as well!
Always try to fix the bug yourself first! Then submit a pull request to Sony
Must search if error has already been reported (bug tracker, this document, dev buglist)
If you've reported the issue somewhere else already and just want to track it here as well, add a link
Before reporting a bug, always make sure to isolate it. That means, wipe everything, install only the ROM without GApps and Magisk and see if the problem still exists. Only then report the bug!

---
If you have questions, ask them in this thread: Xperia XZ Pie ROMs Questions and Answers Thread​
---

In 9.11
1. Everything still works
2. Charging with plugged at screen off works
3. On gcam portrait mode and night photo gives purple glitched image
And phone seems to be faster.

Bug: 9.11 with oem v2- Clean install
- Hotspot not working
- Phone call issue - Mic and speaker not working, cannot hear anything or say anything << Listed in the bug
- Top speaker not working
Still testing.

An update
Yes, we know calling is kinda broken right now on both oem versions. Yes, we know you have problems with dualsim devices because you didn't flash the dualsim patcher. Yes, battery life isn't very good because we are testing out some increased CPU frequencies so video doesn't stutter. (you can go back to the 11-05 build which has the old CPU freqs and compare).
We're aware of a lot of these issues, and they are all tracked in the current buglist (see post #2).
Development happens mostly in the Sony open devices program, with a few heroic volunteers contributing. Right now, a lot of work is being done to get the current flagships(think XZ2, XZ3) to a semi-stable state, but work for our device is done as well.
You can check progress in the sonyxperiadev repos. E.g. recently, some changes to the telephony HAL integration have been made, see the common device repo.
Why is it taking so long to fix all this?
Sony buys many of their processors from Qualcomm. Lots of stuff in phones is proprietary and covered in patents, and you can only get the source code if you sign an NDA. So even if Sony wanted to, they could not release the source for a lot of things.
See all the files with the name "qti" in them? That's Qualcomm Technologies, Inc. See all the repos named something like "qcom-something-something"? That's Qualcomm.
When there's a problem, we have to report it to Sony, who report it to Qualcomm. This takes time already. And don't forget Qualcomm has suppliers as well, and so on and so on. The same is true for other parts, e.g. the Wi-Fi chips are from Broadcom.
Then, support for hardware stuff is on many levels. A lot of low-level drivers that are driving the hardware are on the /odm partition(the one that the oemv1/v2 blobs get flashed to). Then there is work to be done tweaking the actual hardware abstraction layer(HAL) interfaces that work with these driver blobs. Then there are kernel drivers that can go wrong and mess up. Then it can be a problem somewhere higher up in the Android frameworks. Lots of detective work.
If new blobs from Qualcomm come out, Sony itself needs to do some testing, and then releases a new oem version. It won't just magically work, we need to tweak the SODP vendor side as well. It could be as easy as changing a version to a newer one, but it could also be a lot harder. The sonyxperiadev crew knows what's needed to integrate these new blobs, but it still takes time and testing.
Qualcomm provide the a lot of the source code to work with their hardware and blobs from the higher-level Android side in their CodeAurora forum (CAF) repositories. The relevant changes then get merged into the sonyxperiadev repos and we can test if it works(or if something new is broken...).
For more info, read the Android documentation on hardware etc.
The chip in our phone, the MSM8996, is quite old already(even the SDM845 in the XZ2/3 is already quite old in processor standards). We can be luck that Qualcomm still provides support. But it's not a priority to them, they want to sell new
ones of course. That is also a reason updates can take longer.
Regarding full forced-reboot crashes:
Sadly, as of now, for some people the "/sys/fs/pstore" folder does not get populated after a crash. This is important to diagnose what happened.
You can apply this patch to force a kernel panic on every reboot, but I would recommend that you do
so only if you know what you are doing.
Regarding battery life:
Please install BetterBatteryStats
and find out what is draining the battery.
This could really help us out! But first, make sure you are not running any GApps, because the Google Mobile Services are a massive pile of battery drain.
If you absolutely have to use GApps, please run only the "pico" GApps version!
---
About the posts here:
Like 90% of posts here and in the old thread are full of people who just plain refuse to read, asking how to install or demanding someone help them out with something that has already been answered time and time again. This makes it extremely annoying for the us who have to scroll through pages of useless stuff to find the genuine bug reports. You do realize this site is literally named "xda-developers", right? If you're unclear on the concept, please read this: https://forum.xda-developers.com/showpost.php?p=16682226&postcount=2441
"This doesn't work!" - "This thing crashes!" - That gives us almost no clue what is happening. We need logs, or we can't do anything about it. I have only one phone, and I only use the stock ROM. There are a lot of nice testers who send others and me helpful bug reports, with detailed explanations in what circumstances it occured, with proper logs.
With that info, the Sony open devices team and us can actually look into issues.
So please, if something doesn't work AND we are not aware of it yet, post it to the bug list (not here!) and attach a link to a log that you uploaded, e.g. to a service like hastebin.com.
nhicko95 said:
how is battery life?
Click to expand...
Click to collapse
Test it out, please. And don't forget to report the diagnosed battery stats.
DarkPrinciple said:
I should be able to get to 12 lunch with my battery being more than 50%
Click to expand...
Click to collapse
I've tweaked for more performance right now, but you can use 11-05 to get old CPU freqs. Also, please help hunt down what is draining the battery, it's most likely too many held wakelocks, but it could be any number of things.
bihslk said:
So what is the latest and best working version of this rom?
Click to expand...
Click to collapse
It's literally in the first post.
bihslk said:
Rom is pretty OK but really annoying top speaker bug. Only lower one works.
Click to expand...
Click to collapse
That is already in the bug list. Please read the bug list before posting.

Update 2018-11-16
Some new developments are happening.
Oem binaries version 3 are out. This should give improved power management. The SODP team has also worked on getting audio handling during calls to work. A big thanks to oshmoun for his work on the audio manager. This change was introduced on the 11-15 build. The issue of no call audio when a bluetooth headset is connected is still present as of now.
Changed IRQ handling (PR by Angelo/"kholk"). This should give better battery life and maybe faster wakeup from deep sleep. But could also lead to instabilities and crashes. Send logs & pstore, see post #2. This change was introduced on the 11-15 build.
Testing kernel 4.9.137 i in progress (we are currently on .103). This means stability and security enhancements from upstream linux. Thanks to Nathan Chance who opened this pull request..
But some of those upstream changes might be incompatible with our Sony kernel, so we have to test that. Send logs & pstore, see post #2. This change was introduced in the 11-16 build. If the 11-15 and 11-16 builds are unstable, revert to an older one. But please be brave and run them for at least a day to get us logs of potential crashes.
---
optixperiaa said:
I am always confused about "flash latest stock ftf" part about roms as a newbie.. if we flash sony's ftf how can we flash rom ? isnt it overwrite ?
Click to expand...
Click to collapse
Your phone software is made up of many layers. The ROMs like omni or this AOSP-based one only modify your /system and /boot partitions.
But when you update your stock firmware via flashtool, you also update your phone modem firmware, your qnovo charging controller firmware, your lower-level bootloaders etc. That is why we instruct you to update to the latest stock firmware. You could theoretically skip flashing /system in flashtool(because it will get overwritten anyway, as you've already discovered) and directly flash a custom ROM afterwards.
When you're coming from omni, there is no need to flash stock firmware again in between, because your other partitions stay the same. Just a new /oem is needed.

viori said:
flash omni_kagura-2018-11-20_UNOFFICIAL_TESTBUILD-2
Click to expand...
Click to collapse
Again, please keep this thread about development for AOSP. The omni builds are not meant for you.
If you have trouble installing then simply don't use it.
DO NOT POST HERE FOR HELP OR YOU WILL BE REPORTED. Read everything before posting.​
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332​

The OP has requested that you do not post questions in this thread, please use the thread he states in the OP to do that.
If you have questions, ask them in this thread: AOSP 9.0 Pie builds for F8331/F8332
Click to expand...
Click to collapse
Thanks
Thread cleaned

General update
Newer builds will have selinux set to "enforcing". Most denials should have been fixed or are irrelevant. If you encounter any problems, selinux-related or anything else, please report them to the Sony bugtracker or - even better - submit a pull request to the selinux-policy repo.
Update 1: vendor blobs aren't binderized correctly atm, so no network. You can set selinux back to permissive to fix most issues atm.
The Wi-Fi hotspot has been fixed thanks to oshmoun. In newer builds, it should be using less battery.
Next thing we're going to tackle is deep sleep and battery drain. Big pain point and one of the last blockers, apart from the camera and bluetooth in-call audio.
You might have noticed that the omnirom device trees have been updated to 9.0. Nightly testing builds work fine, but they have the same issues as the AOSP-based ones.
Work is also under way to get a Pie-based TWRP recovery stable, with support for FDE encryption(this means that you will be able to back up your encrypted installations). Mounting /userdata works, but the builds are not ready for public release yet.

Update
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.

local__hero said:
New build up (2018-12-08)
Camera key works
Update to December security patch(12-05, r21)
Fingerprint should not crash device on enrollment any more
Allow setting lower minimum brightness
Double-tap-to-wake off by default(but can be enabled)
Plugging in charger with screen off should be fixed
Once again, I invite anyone who would like to help out or just learn a bit about building and tweaking to take a look at the sources posted here.
There will be a guide on how to build only the kernel and experiment with a custom boot.img shortly.
The build guide on sx.ix5.org for reproducing these AOSP builds should bring you up to speed, and if you need help building or just want to chat, the telegram group in post #1 is open to you.
Click to expand...
Click to collapse
Great job.
I already built a custom Pie kernel about a week ago to gain better performance but the charging bug was driving me insane :crying:
I guess now's the time to go back to the mighty Pie and try building a nice and hopefully stable Marrow Kernel.
Cheers

Finally a new build is out!

I can't pass safety net on latest build.
Any ideas what should I use ?
Since modules for spoofing fingerprint simply don't work.
I tried universal safety net fix but with no avail.

V 12.15
Charging working fine. But i have problem with camera, photos are very dark.

Sometimes touch screen not working and i need to switch the screen and on again.

ov2rey said:
Sometimes touch screen not working and i need to switch the screen and on again.
Click to expand...
Click to collapse
Disable Dt2w

oem v4 is out

DahakePL said:
Disable Dt2w
Click to expand...
Click to collapse
Thank you It's work!
Layns said:
oem v4 is out
Click to expand...
Click to collapse
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/

ov2rey said:
Thank you It's work!
i am testing v4 on latest build aosp_f8331_2018-12-21-NIGHTLY-permissive.
Screen unable to display after update to oem v4
https://developer.sony.com/file/download/software-binaries-for-aosp-pie-android-9-0-kernel-4-9-tone/
Click to expand...
Click to collapse
I tried it works fine but the camera sucks and the sound is bad, the screen opening with double tap is running slow, the charge is a little quick