Related to the ril because the amaze is an oddball and im not sure what files relate to the ril i got the lib ril and libhtcril and libqc-qmi-ril and the oem version but what else thanks?
Related
Im interested to know how these guys (CyanogenMod, codeworkx) take the ASOP Jellybean and get it running on the i9300, ive seen (http://review.cyanogenmod.com) where they show the open/megred/abandonned status information.
Do they run a debugging app on the i9300 while testing for issues, how is it done?
Also, when samsung add their own features, like touch wiz, camera app + fm radio on top of ASOP, how do they go about (trying) porting it over to Jellybean to make it work? Is that samsung proprietary code? and does that require decompiling before trying to debug and port??
Any info/links to point me in the right direction is appreciated.
Cheers, Nic
niczoom said:
Im interested to know how these guys (CyanogenMod, codeworkx) take the ASOP Jellybean and get it running on the i9300, ive seen (http://review.cyanogenmod.com) where they show the open/megred/abandonned status information.
Do they run a debugging app on the i9300 while testing for issues, how is it done?
Also, when samsung add their own features, like touch wiz, camera app + fm radio on top of ASOP, how do they go about (trying) porting it over to Jellybean to make it work? Is that samsung proprietary code? and does that require decompiling before trying to debug and port??
Any info/links to point me in the right direction is appreciated.
Cheers, Nic
Click to expand...
Click to collapse
The devs just download the AOSP/CM sources from their Android git/CM git and compile it in linux with device specific source files. These device files can be forked from a device like GNexus and modify it to support your phone. If the device files are already modified for your phone, then you can just clone the git repo and compile the Android/CM build.
They might run debugging app or they may not.. it depends on the dev's themselves.
Don't know how samsung does it. They make their own proprietary code.
This is just to give you a brief idea of how things get done here. If you wanna know more just Google. There are plenty of guides available on the internet, there are a lot of guides in xda too.
accidentally thanked u
The front page of XDA has a development section .
jje
Just trying to understand the game here... previously I had a Sprint Galaxy Nexus and as I understood it the entire source for the image was available and thus the devs could do a full build roughly equivalent to what an OEM would do. On the other hand with a device like my Galaxy Tab 10.1 there were certain things that were always flaky (running non-OEM roms) and the devs claimed they just didn't have the real drivers to properly support the hardware.
So what is the actual deal with the DNA? To run something like 4.1.2 what would be the procedure to generate the image? Nevermind the unlock/s-off details of actually getting it on the phone, how would you go about getting the DNA-specific drivers from the stock image and combining that with the aosp mainline? Would this involve disassembly of the stock image? Or is there a way to somehow use binary modules directly from the stock image?
Bump
Sent from my ViperVivow
from what I understand the hardest thing to get aosp (i believe thats what you were referring to in the OP?) will be cracking the RIL
[email protected] said:
from what I understand the hardest thing to get aosp (i believe thats what you were referring to in the OP?) will be cracking the RIL
Click to expand...
Click to collapse
That's what I'm trying to figure out though, what is the actual process of doing this? I'm a Windows kernel dev, so in my world if I had one Windows machine up and running I could grab the binary .sys files and copy them into another similar OS (from Vista to Win7 perhaps) and things would just work. If I were moving between two imcompatible platforms (say from Windows to OpenBSD) then I'd have to disassemble the .sys to figure out what it actually does and then rewrite something functionally equivalent for BSD. I know nothing about Android development so I'm trying to understand how all this works here. We obviously have full stock image that includes all necessary drivers for the screen, radio, etc. And we also have generic, hardware independent aosp. So how do we combine the peanut butter and the chocolate to get the Reese's?
The issue is the RIL like has been stated. The problem is that HTC Sense uses a different telephony package than AOSP ROMs so the closed source ril.so and rild.so (radio interface layer and radio interface layer daemon object files) won't work with an AOSP ROM's telephony package (telephony.jar). There also may be some other hardware issues besides the radio like the camera that are different, but the radio is the biggest one.
Mazer
Sent from my rooted and debloated Droid DNA.
So in the past with other devices, how is this bridge crossed? Would a new telephony.jar be developed to interop with the existing ril/rild binaries? Or would the ril/rild binaries be reverse engineered and rewritten to be compatible with the existing telephony.jar?
HiBoost said:
So in the past with other devices, how is this bridge crossed? Would a new telephony.jar be developed to interop with the existing ril/rild binaries? Or would the ril/rild binaries be reverse engineered and rewritten to be compatible with the existing telephony.jar?
Click to expand...
Click to collapse
The telephony binaries would be decompiled and somewhat interpreted/understood and modified (usually involves a lot of guesswork and error log reading) recompiled then tested. If the build works then it is released. Usually there'll be two preliminary builds one that just has voice/text service, one with 3g, then one with 4g (all three working.) All three are completely separate and are huge milestones.
Mazer
Sent from my rooted and debloated Droid DNA.
Thanks for your responses!
HiBoost said:
Thanks for your responses!
Click to expand...
Click to collapse
Sure thing.
Sent from my rooted and debloated Droid DNA.
I'm sorry to post this on general forum, because I don't have permission to write on dev forum.
I think is pretty old, because there is new android version 4.2.1, but anyway
as you know, you cannot use ICS libril.so with JB, because of network searching problem.
Well known solution is compiling new libril.so with JB source code.
But if you really want to use ICS ril, because of ril specific function that is implemented on ril by device vendor, you will face big challenge.
So I made mod for JB (4.1.2).
I just compared ril.cpp file with two version (JB and ICS), and add new features from JB ril.cpp to ICS RIL.java.
So, unsupported requests will proceed by RIL.java not libril.so.
this is works for me.
mine is HTC's 4.0.3 ICS libril.so, ril version 6.
I'm not sure this will works for all of your libril.so, I hope this is helpful.
GIthub link is here. (sorry, I dont have link permssion.)
github.com/hounjini/JB_ICS_ril_support
Happy new year!
Recently i have ported a cm12.1 beta 7 stable v2 rom
Everything is working fine except for front camera & Bluetooth
Plz can anyone know how to fix this?
I have tried many lib files, but non of them r working
Plz help on it to fix this issue
Anyone plz
Your issue is gonna be a kernel issue and without the source there is nothing you can do. It is a common issue with devices running that chip set. That's why developers don't touch devices with it.
zelendel said:
Your issue is gonna be a kernel issue and without the source there is nothing you can do. It is a common issue with devices running that chip set. That's why developers don't touch devices with it.
Click to expand...
Click to collapse
My phone is Symphony h150. Its mediatek mt6582 chipset.
I don't know about any source file. But i think not.
So ur telling me that there's no way
rabin69x said:
My phone is Symphony h150. Its mediatek mt6582 chipset.
I don't know about any source file. But i think not.
So ur telling me that there's no way
Click to expand...
Click to collapse
Yes I'm saying that without a proper kernel then there will be things that just can't be fixed. Normally things like the camera and wifi radios. You might be able to hack your way through it but it will take weeks of searching through the code.
The kernel source code is the base code that is required by law to be published for any device that runs a Linux kernel (any android device) the issue with that chip set is they are based in China and dont respect copyright laws or the GPL.
rabin69x said:
My phone is Symphony h150. Its mediatek mt6582 chipset.
I don't know about any source file. But i think not.
So ur telling me that there's no way
Click to expand...
Click to collapse
If it's still actual for you (2 years, but still...), mediatek has laid off some kernel and AOSP sources for mt65xx series. Also check out this repo: github.com /bq/aquaris-E5, it has some code for your chip and other Mediatek stuff.
Also you have few other options:
Build your ROM around existing (official) kernel, adding more drivers as .ko's. I've had certain success adding some USB drivers like that.
Use some .so's from your original ROM. Sometimes manufacturers don't provide sources for libcamera.so/libcamera_client.so (camera), libhardware.so/libhardware_legacy.so (wifi and some minor stuff, like vibromotor)
Hi there,
I want to port a Lollipop ROM to an Android device which has only a KitKat ROM. In order to find the fitting Lollipop drivers, I would like to know the exact HW specs (like cam, display, WiFi+BT, GPS, etc..). Then I plan to inject these driver files in the template LP ROM.
So I had the idea I could find out the exact HW specs by disassembling the libraries from the base ROM. So I checked several files (libcam.so, wifi... .so, etc.) in the base KK ROM, but could not find any hints.
Can anybody help me, how I can identify the exact HW of the critical components by the ROM?
Thanks in advance!
Nobody an idea?