I currently have the AT&T version of SGN2 which is t0lteatt. I really like Liquidsmooth, but there is only a t0lte version (T-Mobile). I can flash and it runs great. The problem I'm having is that my voice/data network keeps cutting out. I believe this is due to it being a t0lte version. Can someone explain the difference? Do I just need to flash over an AT&T radio? I don't believe this is so, because the rom wouldn't flash over the current AT&T radio I have. The APN settings I have are correct for AT&T by the way.
Thanks ahead for any help offered
voice and data doesn't cut out on other roms?
t0lteatt is our att note ii, t0lte is the international lte note ii and t0ltetmobile or w/e is the t-mobile version, ver little differences, the build.prop reflects proper phone and some other minor changes, that said all 3 dont include a modem so no you dont need one if you didnt change it to the wrong one.
Sent from my SAMSUNG-SGH-I317 using xda app-developers app
Have you tried the UCAMC3 radio image ?
That radio may help...
Also check the dev section for the thread that offers the RIL files that have been pulled from the official UCAMC3 update.
Loading those libraries, to run along side the radio should give you the performance of the update build on the custom rom.
You "should " be okay loading RIL files into your rom, but please read the OP of those threads carefully.
And of course ...backup the current build if not done already.
I feel that RIL files are often overlooked or left incomplete, resulting in broken functionality on certain radio\rom combinations.
These critical files are normally included with radio images if packaged properly.
That being said, a re-flash of just the radio package should help as well.
But that question as to whether or not any given radio does contain the needed RIL's for the current network, should be forwarded to the respective dev or creators of the desired radio flash package.
Happy flashing ....g
I will try to answer this question as best I can. Up until about two months ago if you wanted to build a ROM from source for the GT-N7105, SGH-I317, or the SGH-T889 Galaxy Note 2 you had to use the t0lte folder as your device folder in your work tree. But Steve Klondik, A.K.A Cyanogen, made the partial device folders t0lteatt and t0ltetmo to start splitting the three devices apart. Now notice I said partial folders because even though these folders are for the SGH-I317 and SGH-T889 individually. They still use the t0lte folder to build as it has all the other folders in it that the device needs like overlays, configs, bluetooth, audio, device settings, and rootdir. this means that the compiler starts in the t0lteatt or the t0ltetmo depending on what device you are building for. But the full_t0lteatt.mk or full_t0ltetmo.mk directs it to go into the t0lte folder to use the t0lte.mk, or commonly called the device.mk file because neither the t0lteatt or the t0ltetmo folder has a device.mk file in them. Then only real difference in the folders is the name of the device in the files.
But this does not really address the difference between the t0lteatt and t0lte. The main difference is the t0lte is a build using only the t0lte device folder. This means that the build will probably not have the device model correct in the build-prop so it will not be the correct model number in Settings/About phone unless the build-prop is edited. The tolteatt is a build that used both the t0lteatt and t0lte device folders and should have the correct model number in the build-prop and Settings/About phone. But it is nothing wrong with building with just the t0lte folder as long as you do not mind editing the build-prop or that the build does not have the correct device model number. if you would like to look at all three folders below are links to all three on CyanogenMod github.
t0lte= https://github.com/CyanogenMod/android_device_samsung_t0lte
t0lteatt= https://github.com/CyanogenMod/android_device_samsung_t0lteatt
t0ltetmo= https://github.com/CyanogenMod/android_device_samsung_t0ltetmo?ref=commandbarr
Now to address you problem, if it is a t0lte build the it is more than likely a older build. Look in the the build.prop and see if you see this line. "ro.telephony.ril_class=SamsungQualcommUiccRIL" If you do you need to change it to " ro.telephony.ril_class=SamsungQualcommRIL". The ril file was changed on these devices in the t0lte.mk file about a month ago, below is a link to the commit showing the change. Maybe this will help you understand and help you fix yor issue.
Ril commit https://github.com/CyanogenMod/andr...mmit/f3459ea5651152c322334376f6c3c8b8b50375a3
Edit: I forgot that when Cyanogen made the t0lteatt and t0ltetmo folders he also added the smdk4412-qcom-common folder as a device dependency. But that is just for better GPS support so it further supports my point that it is no real big difference between t0lte and t0lteatt.
T-Macgnolia said:
I will try to answer this question as best I can. Up until about two months ago if you wanted to build a ROM from source for the GT-N7105, SGH-I317, or the SGH-T889 Galaxy Note 2 you had to use the t0lte folder as your device folder in your work tree. But Steve Klondik, A.K.A Cyanogen, made the partial device folders t0lteatt and t0ltetmo to start splitting the three devices apart. Now notice I said partial folders because even though these folders are for the SGH-I317 and SGH-T889 individually. They still use the t0lte folder to build as it has all the other folders in it that the device needs like overlays, configs, bluetooth, audio, device settings, and rootdir. this means that the compiler starts in the t0lteatt or the t0ltetmo depending on what device you are building for. But the full_t0lteatt.mk or full_t0ltetmo.mk directs it to go into the t0lte folder to use the t0lte.mk, or commonly called the device.mk file because neither the t0lteatt or the t0ltetmo folder has a device.mk file in them. Then only real difference in the folders is the name of the device in the files.
But this does not really address the difference between the t0lteatt and t0lte. The main difference is the t0lte is a build using only the t0lte device folder. This means that the build will probably not have the device model correct in the build-prop so it will not be the correct model number in Settings/About phone unless the build-prop is edited. The tolteatt is a build that used both the t0lteatt and t0lte device folders and should have the correct model number in the build-prop and Settings/About phone. But it is nothing wrong with building with just the t0lte folder as long as you do not mind editing the build-prop or that the build does not have the correct device model number. if you would like to look at all three folders below are links to all three on CyanogenMod github.
t0lte= https://github.com/CyanogenMod/android_device_samsung_t0lte
t0lteatt= https://github.com/CyanogenMod/android_device_samsung_t0lteatt
t0ltetmo= https://github.com/CyanogenMod/android_device_samsung_t0ltetmo?ref=commandbarr
Now to address you problem, if it is a t0lte build the it is more than likely a older build. Look in the the build.prop and see if you see this line. "ro.telephony.ril_class=SamsungQualcommUiccRIL" If you do you need to change it to " ro.telephony.ril_class=SamsungQualcommRIL". The ril file was changed on these devices in the t0lte.mk file about a month ago, below is a link to the commit showing the change. Maybe this will help you understand and help you fix yor issue.
Ril commit https://github.com/CyanogenMod/andr...mmit/f3459ea5651152c322334376f6c3c8b8b50375a3
Edit: I forgot that when Cyanogen made the t0lteatt and t0ltetmo folders he also added the smdk4412-qcom-common folder as a device dependency. But that is just for better GPS support so it further supports my point that it is no real big difference between t0lte and t0lteatt.
Click to expand...
Click to collapse
Awesome write up man!
ROOTBOXED!
Please read forum rules before posting
Questions and help issues go in Q&A and Help sections
Thread moved
Thank you for your cooperation
Friendly Neighborhood Moderator
Thanks for the information in this thread. :good:
I have used both t0lte, t0ltetmo, and t0lteatt ROMs on my SGH-T889 (T-Mobile branded) device and they all work (voice, text, 3G, LTE) with the usual minor nuisances like device model being listed wrong in About Phone. I recently switched from T-Mobile to AT&T as my carrier, so I am wondering which ROM would be most appropriate for my device now? Any input or advice would be appreciated.
Related
CM9 NIGHTLY (UNOFFICIAL SEMI-KANG) FOR CDMA TORO
Hey! This is my first post here on XDA, though I've been a long time user of these very forums, since the OG Droid root.
This is also my first ROM, though the credit should really go to the Cyanogenmod team. This is a pull from the ICS branch of CM's git repository,
built on Ubuntu x64. The proprietary .so files were pulled from Team-Kang's repo, because theirs was the only files I could actually get running.
I'm running this as my main install, and so far there's been no problems at all.
THIS IS NOT STABLE.
This is the equivalent of a nightly from CM, though much less polished. It can be considered a pre-alpha nightly build.
I am not liable for anything this ROM may do to your phone.
I'm doing this because I always enjoyed Cyanogen's ROMs straight without any mods or tweaks. I knew exactly what was running on my
phone. This is a straight pull from git. I haven't included any extra pulls from git or gerrit, nor anything else. It's pure Cyan.
I will do nightly releases of this ROM. CM's source is constantly changing, and I'll try and keep up with that, at least until the
build servers are doing automated nightly compiles.
Download:
thewcubed.com/update-cm-9.0.0-RC0-GN-CDMA-KANG-signed.zip
To install:
Download the ROM to your phone.
Download a GApps zip to your phone. (I use kejar31's zip)
Make sure you have the latest version of CWM's recovery.
Boot to recovery.
Backup your current system and data partitions.
Wipe data, cache, and the dalvik-vm cache. (I always do it twice to be on the safe side.)
Flash the ROM.
Flash GApps zip.
Reboot.
(tentative) Hooray!
If the download is too slow, I'll try and upload this to a couple mirrors. I don't know if my server's going to be able to handle a request flood on a 10Mb/s upload line.
Glad your making a Rom, but...
1) its in the wrong forum and
2) you dont have a link because of your "probation" status of < 10 posts
Good luck with your work though!
Also there's (unofficial) builds by a CM developer in the development section already:
http://forum.xda-developers.com/showthread.php?t=1397122
@kenyu73
I know that this isn't in the Dev section, but I can't switch it yet due to the 10 post limit. It should still be valid in the General section though.
The URL is still valid, simply copying and pasting it begins a download of the zip.
@got_milk
There may be unofficial builds, but those are for GSM devices. I apologize for not clarifying in the title that this is for CDMA/LTE versions of the Galaxy Nexus.
toroidal_loop said:
CM9 NIGHTLY (UNOFFICIAL SEMI-KANG)
Hey! This is my first post here on XDA, though I've been a long time user of these very forums, since the OG Droid root.
This is also my first ROM, though the credit should really go to the Cyanogenmod team. This is a pull from the ICS branch of CM's git repository,
built on Ubuntu x64. The proprietary .so files were pulled from Team-Kang's repo, because theirs was the only files I could actually get running.
I'm running this as my main install, and so far there's been no problems at all.
THIS IS NOT STABLE.
This is the equivalent of a nightly from CM, though much less polished. It can be considered a pre-alpha nightly build.
I am not liable for anything this ROM may do to your phone.
I'm doing this because I always enjoyed Cyanogen's ROMs straight without any mods or tweaks. I knew exactly what was running on my
phone. This is a straight pull from git. I haven't included any extra pulls from git or gerrit, nor anything else. It's pure Cyan.
I will do nightly releases of this ROM. CM's source is constantly changing, and I'll try and keep up with that, at least until the
build servers are doing automated nightly compiles.
Download:
thewcubed.com/update-cm-9.0.0-RC0-GN-CDMA-KANG-signed.zip
To install:
Download the ROM to your phone.
Download a GApps zip to your phone. (I use kejar31's zip)
Make sure you have the latest version of CWM's recovery.
Boot to recovery.
Backup your current system and data partitions.
Wipe data, cache, and the dalvik-vm cache. (I always do it twice to be on the safe side.)
Flash the ROM.
Flash GApps zip.
Reboot.
(tentative) Hooray!
If the download is too slow, I'll try and upload this to a couple mirrors. I don't know if my server's going to be able to handle a request flood on a 10Mb/s upload line.
Click to expand...
Click to collapse
I love seeing new developers come here everyday
One small issue though, this is posted in the wrong section. This should be posted in the GSM Galaxy Nexus Android Development or CDMA Galaxy Nexus Android Development (depending whether its GSM or CDMA)
toroidal_loop said:
@kenyu73
I know that this isn't in the Dev section, but I can't switch it yet due to the 10 post limit. It should still be valid in the General section though.
The URL is still valid, simply copying and pasting it begins a download of the zip.
@got_milk
There may be unofficial builds, but those are for GSM devices. I apologize for not clarifying in the title that this is for CDMA/LTE versions of the Galaxy Nexus.
Click to expand...
Click to collapse
Did you ever ask the guys from cm team before you post the kang build?I dont think this allowed.
Sent from my Galaxy Nexus using Tapatalk
Getting your post count up and then posting in Development would have been the thing to do. This will get lost in General, and I can't see it being moved to Development or everyone and his mate would be using that loophole.
@afilopou The CyanogenMod source is released under the Apache 2.0 license. This ROM isn't built for commercial gain, I'm crediting the CM team as the writers of the code, nor am I attempting to alter the code and then copyright it. The concept of "open-source" is that one can do something like this, building and redistributing.
@Kalavere I'm not trying to get this moved to the Dev. If there's enough interest in it, I'll repost the thread to Dev when I'm able. The problem I had was that there wasn't a vanilla build of CM that I could find anywhere for the CDMA/LTE toro.
toroidal_loop said:
@afilopou The CyanogenMod source is released under the Apache 2.0 license. This ROM isn't built for commercial gain, I'm crediting the CM team as the writers of the code, nor am I attempting to alter the code and then copyright it. The concept of "open-source" is that one can do something like this, building and redistributing.
Click to expand...
Click to collapse
Perfect .Just mention it because i dont want to see another locked thread
I haven't posted enough on XDA to be able to reply to the appropriate development forum post, so I decided to post here. I'm running CM10 on a Sprint Galaxy Nexus (toroplus), and I had been in need of a way to use NFC while the screen was locked, but couldn't find one for the latest build of CM10. I found this thread http://forum.xda-developers.com/showthread.php?t=1709586 but the latest updates only had one for screen off (which is a little less secure IMHO), and when I used it, I would have to turn NFC off and then back on almost every time I used it, which defeated the purpose. I also saw that someone else was having the same issue, so I decided to compile one myself using the latest CM10 source. This was built from source as of 10/31/2012 and has only been tested on the nightly build with the same date. I figured I'd share it with everyone that might be needing the same.
Disclaimers: This requires a rooted phone! This has only been tested on the Sprint Galaxy Nexus running CM10 nightly dated 10/31/2012, but may work with other versions. Do a backup! I'm not responsible for any problems resulting from these files, so backup first!
To install, copy to your SD card. Reboot into recovery. DO A BACKUP! Install the zip from the SD Card. Reboot.
There are two versions I created. One is for when the screen is on, but locked. The other is for when the screen is off.
Update 1/2/2013:
I compiled a version of the screen locked for CM10.1 (Android v4.2.1) for anyone who would like it. I was getting mixed results with the previous file on 10.1. This one is working on my toroplus with the latest CM10.1 nightly. I'll build a screen off version later. I was having some problems with my build VM, so I didn't get to it yet. The new file for CM10.1 is called NFC_Screen_Locked_CM10.1.zip.
Update 1/3/2013:
The CM10.1 version of the screen off version is now posted. File name is NFC_Screen_Off_CM10.1.zip
Update 1/16/2013:
Previous version of NFC_Screen_Off_CM10.1.zip was not working. Should be working now.
Update 1/16/2013:
Added a patch that can be used against CM10 or 10.1 source code to add an option to the settings to switch between screen on, locked, or off NFC. You must build the entire thing from scratch to use this patch. There are logs of guides for building CM. Here's a link to the CM wiki article for toroplus for example. Before executing brunch, copy this file to the root of where you created the repo (the article uses the ~/android/system/ folder for instance) then execute the following two commands:
Code:
tar -xzf nfc-patch.tar.gz
./apply-nfc-patch.sh
Or in the use package manager to untar all of the files (maintaining the directory structure) and then double click and run the apply-nfc-patch.sh file. This will patch all of the necessary files in the build. Then continue with the instructions in the build guide and flash the resulting ROM.
Disclaimer Again: This could break your phone. I'm not responsible for any damages this may cause. This has only been briefly tested on my toroplus with the latest CM10.1 code from the repository.
Credits: Rick C who originally submitted most of this to the CM repository but was rejected.
Update 1/21/2013:
Looks like a recent commit to the repository broke one of the diffs in the patch. Uploaded a new version.
Update 2/13/2013:
Another update to fix an issue with the patch files. I also added a reset script that will do a hard reset for git repos of the affected packages. Don't use this script if you have made any other customizations to the Settings app, NFC app or the frameworks/base code as you will lose them. Just do things in this order:
1) run reset script
2) run repo sync
3) extract tar again
4) run apply script
5) run brunch again
You can use this sequence every time you want to grab the latest code.
If you get errors when running the apply script you can use this command to delete the error files that come up. These files might show up even if the patch works, but the code wasn't exactly what the patch was expecting, but enough to apply anyway.
Code:
find . \( -name \*.orig -o -name \*.rej \) -delete
This set of commands should do the trick for most people to get the latest code, apply the patch and build:
Code:
./reset-nfc-patch-repos.sh
repo sync
tar -xzf nfc-patch.tar.gz
./apply-nfc-patch.sh
source build/envsetup.sh && brunch <your-device-name>
Update 2/27/2013:
Made some fixes to the notes in the previous update based on feedback from mrplowdan.
Update 3/15/2013:
Compiled a new version of the CM10.1 files for those having issues.
Update 10/21/2013:
Added a test version of the screen locked version for CM10.2 now that toroplus has an official CM10.2 nightly. Let me know if there are any issues. I'll add a screen off version when I have some time.
Update 11/19/2013:
Finally getting around to adding a screen off version for CM10.2. The screen locked version has been running well on my toroplus for the last month with no issues.
Has anyone tested this on Maguro?
Just recently got my phone back from service (after 10 weeks) so i'm not re-rooted yet, hence i can not try this on stock myself. Just wanted to give a big thanks to you for creating and developing this this is really a truly great way to make use of the nfc and the way it should have been done from the very beginning. I.ex if your out running, listening to music and for some reason need to pause your music, just swipe a previosly attached nfc-tag on your sleve over your pocket with the phone in. And again to start music. Awsome work, thank you!
Sent from my Galaxy Nexus using xda premium
It may work on Maguro as long as you're using a fairly recent version of CM10. If I knew anyone with a device, I'd test it myself. It's fairly low risk to test. It only replaces a single file. It's the Nfc.apk in the /system/app/ folder. You could always rename your existing file; install this one; and then reboot and test it out. Also, if you're wary of the zip itself, you can just extract the Nfc.apk and copy it to your /system/app/ folder manually, just don't forget to reboot. Then if it breaks you can just delete the new one and rename the old one back. You could also just backup everything; install the zip; and just restore the backup if anything breaks. Anyway if you decide to be adventurous, let us know how it goes. I'll keep this thread updated if CM makes any other changes that break it again. I use it often, so I'll likely find out pretty quickly. Hopefully, they'll add this as a setting in CM10 some day.
Sent from my Galaxy Nexus using xda app-developers app
could i use it on every rom cm based?
It depends on how many modifications were made by the mod around NFC, if any. Also depends on when the last time was that they merged their code with CM. In theory it should work with most CM based mods. You can always try it out as I mentioned above and revert if it breaks. And post here with your results if you try it, so others can benefit.
Sent from my Galaxy Nexus using xda app-developers app
Locked version tried and working maguro. I'm on latest Jellybro. Good work and thanks
Sent from my Galaxy Nexus using xda premium
CM10.1 Update
I compiled a version of the screen locked for CM10.1 (Android v4.2.1) for anyone who would like it. I was getting mixed results with the previous file on 10.1. This one is working on my toroplus with the latest CM10.1 nightly. I'll build a screen off version later. I was having some problems with my build VM, so I didn't get to it yet. The new file for CM10.1 is called NFC_Screen_Locked_CM10.1.zip.
irotsoma said:
I compiled a version of the screen locked for CM10.1 (Android v4.2.1) for anyone who would like it. I was getting mixed results with the previous file on 10.1. This one is working on my toroplus with the latest CM10.1 nightly. I'll build a screen off version later. I was having some problems with my build VM, so I didn't get to it yet. The new file for CM10.1 is called NFC_Screen_Locked_CM10.1.zip.
Click to expand...
Click to collapse
Great work! - many thanks from me!
I'm waiting so long for the Screen-Locked Version ...
Best regards
JoSch
can it be included in cm10.1?
I was just wondering, can't this be somehow merged with stock cm10.1? Add checkboxes in the settings.apk, lots of warnings when enabling it and people who know can use it.
nice work btw
Screen Off for CM10.1
The CM10.1 version of the screen off version is now posted. File name is NFC_Screen_Off_CM10.1.zip
cthulu said:
I was just wondering, can't this be somehow merged with stock cm10.1? Add checkboxes in the settings.apk, lots of warnings when enabling it and people who know can use it.
nice work btw
Click to expand...
Click to collapse
Yes, actually I've been wanting to do this for a while, but I never seem to have the time to dig into the settings UI and how to read that setting. If you or someone else would be willing to create the settings piece and tell me how to access the setting that you create, I'd be happy to alter the NFC service to look at those settings. Ideally there should be a preference with an integer value of 1 for screen off, 2 for screen on but locked, and 3 for screen on and unlocked (default) as that's the value that the service expects currently.
First of all i would like to thank you posting this, just what I was looking for.
Im running one of the latest cm10.1 nightlies (jan 1st or 2nd) and flashed the NFC_Screen_off_CM10.1zip however it doesn't work while the screen is off, though it does work when the screen is on and the phone is locked. I have a Galaxy Nexus (gsm).
When I logcat the phone I don't see NFC being discovered with the screen of but with the screen on and the phone locked I do see that it discovers an NFC event.
Is there anything that can be done about this?
Thanks!
dannyvanderzande said:
First of all i would like to thank you ting this, just what I was looking for.
Im running one of the latest cm10.1 nightlies (jan 1st or 2nd) and flashed the NFC_Screen_off_CM10.1zip however it doesn't work while the screen is off, though it does work when the screen is on and the phone is locked. I have a Galaxy Nexus (gsm).
When I logcat the phone I don't see NFC being discovered with the screen of but with the screen on and the phone locked I do see that it discovers an NFC event.
Is there anything that can be done about this?
Thanks!
Click to expand...
Click to collapse
That's odd. I didn't have an NFC tag handy when I built the screen off version, so I assumed the same changes I made in CM10 would work in 10.1 since the screen locked version worked. I'll test it on my device and see if I can figure it out as soon as I get some free time. Thanks for letting me know!
irotsoma said:
That's odd. I didn't have an NFC tag handy when I built the screen off version, so I assumed the same changes I made in CM10 would work in 10.1 since the screen locked version worked. I'll test it on my device and see if I can figure it out as soon as I get some free time. Thanks for letting me know!
Click to expand...
Click to collapse
I decided to check the files out myself to try and figure it out and maybe quick fix it myself (which would have saved you the time) by referencing to the 10.0 apk's however I found out they differ a lot more from eachother than I expected so it was a bit too much for my skillz. I found this out using a comparison tool and while I was at it I compared the 10.1 screen lock and 10.1 screen off versions. According to my program they are exactly identical in either file structure as in file contents so I'm guessing something must have gone wrong with renaming or I just don't know how to use the tool? I'm just mentioning this as something I came upon, not to ***** or anything! I really appreciate the work you did!
Anyway.. I had some fun figuring things out and learning about decoding apk's and all of that. Thanks for all the hard word so far and I'll just wait patiently upon the new screen-off version.
The screen off one works perfectly for the Toro running the last stable 4.1.2 liquid smooth rom. Awesome work, thanks a million!
Edit: I'm not sure if it makes a difference but I didn't flash it, I pulled the apk from the zip, copied and pasted and reset permissions then restarted.
Fixed CM10.1 Screen Off
irotsoma said:
That's odd. I didn't have an NFC tag handy when I built the screen off version, so I assumed the same changes I made in CM10 would work in 10.1 since the screen locked version worked. I'll test it on my device and see if I can figure it out as soon as I get some free time. Thanks for letting me know!
Click to expand...
Click to collapse
OK, so I uploaded a new version. I actually tested it this time and this one worked for me on my toroplus. Let me know if there are any other issues, but you should be good to go after flashing this one. Sorry it took so long to get around to it. Enjoy!
Settings Patch for CM Source Code
cthulu said:
I was just wondering, can't this be somehow merged with stock cm10.1? Add checkboxes in the settings.apk, lots of warnings when enabling it and people who know can use it.
nice work btw
Click to expand...
Click to collapse
I did a little digging and found that there was a patch submitted to CM10 to include a switch for this in the settings. However, it was rejected by Steve Kondik and abandoned. I took all of the code and merged it into the latest CM10.1 code and it seems to work. I added a patch to the main post, but you have to compile CM from scratch to use it since it touches some framework components. The good news is it should work on any device that CM supports (that uses the NFC.apk though not devices that use NfcNci.apk like the Nexus 4) and should work on both CM10 and 10.1 in most cases.
The patch is basically just a few diff files and a bash script to automate the patching. If anyone is feeling adventurous, feel free to experiment with it. I can't promise it will work for you, but it's fun to try and learn a bit about building CM source code in the process. Basic directions are in the original post. As always I take no responsibility for anything it might break, but I'll be happy to try to troubleshoot if I can. Enjoy!
Thanks for all your effort.
Unfortunately it doesn't work on the nexus 4 but after some googling I found a working version for the nexus 4 on the forums here on xda. Im guessing there's a difference in chips or something...
dannyvanderzande said:
Thanks for all your effort.
Unfortunately it doesn't work on the nexus 4 but after some googling I found a working version for the nexus 4 on the forums here on xda. Im guessing there's a difference in chips or something...
Click to expand...
Click to collapse
Thanks for pointing that out. I clarified the previous post a bit. I should have said it should work with any devices that use Nfc.apk. Newer devices that use NfcNci.apk will not work with the patch.
Hello Guys,
I made a AOKP device tree for ja3g [I9500].Its based off ewmno's one but this one is completely a different thing. It will not build anything. But i need Developers to help me fix and fill the gaps in my device tree. Not A Fancy OP for now will make it better later
This is the first step for Cyanogenmod or AOKP for S4 :victory:
Anyways Guys here is the Device-tree :taken down cause ewmno is faster
It can be seen that this is the n7100 device tree merged with mine with name changes. But you forgot:
1. The board its not smdk4×12
2. All system files need to be extracted from the i9500 dump, ones from older devices won't work.
3. The res is xxhdpi not xhdpi
4. The config points to the ramdisk files from exynos4412 devices
5. The proprietary-files.txt points to the wrong files for extraction.
6. High chances n7100 device settings wont work.
7. Same goes for RIL and audio
I didn't push my full changes to my github yet, as I was unsure of a few of them.
emwno said:
It can be seen that this is the n7100 device tree merged with mine with name changes. But you forgot:
1. The board its not smdk4×12
2. All system files need to be extracted from the i9500 dump, ones from older devices won't work.
3. The res is xxhdpi not xhdpi
4. The config points to the ramdisk files from exynos4412 devices
5. The proprietary-files.txt points to the wrong files for extraction.
6. High chances n7100 device settings wont work.
7. Same goes for RIL and audio
I didn't push my full changes to my github yet, as I was unsure of a few of them.
Click to expand...
Click to collapse
Let's together make this happen
I have mine ready. Just not pushing it until I get some idea about ril with sammy devices.
Thread closed at OP's request.
Hello All,
This may be in the wrong place so if it is, I am sorry, anyway to my question I'm trying to build CM for my S4 Mini LTE Serranoltexx everything was going fine until I got this message after running extract-files.sh
Code:
Extracting /system/lib/egl/libGLESv2S3D_adreno200.so ...
remote object '/system/lib/egl/libGLESv2S3D_adreno200.so' does not exist
Now after adding "libGLESv2S3D_adreno200.so" (if you search Google for it it's the top github link) I managed to get it to build the actual .zip and it does flash properly but it doesn't seem to have the correct graphics drivers (I thought this process wouldn't work and I was right), the guide on the how to build it doesn't help with this problem either so any help would be extremely appreciated
I've attached the logcat for reference (if it's needed) as a .docx file as the .txt file was 1.1mb and because I don't have a pro account on pastebin.
The problem with newer Android versions is that if often require new libraries which are not available in stock rom, so the extract method is actually not very useful unless we have a stock rom of the same version we are building for. To bypass this issue we use libraries from other phones that have the matching Android version. I suggest using the blobs that's on TheMuppets github, as those are up to date.
https://github.com/TheMuppets/proprietary_vendor_samsung
Hi everyone,
recently I have built and flashed on my sgh-t999 (galaxy S3 US tmobile version) CM11 Nightly. For my pro0ject however I need to modify two libraries of the Radio Interface Layer (RIL), libril.so and libreference-ril.so. I tried to modify the ones in the forlder /hardware/ril/ and build everything again with no results. Any change that I made to those files (such as ril.cpp in the folder libril) would not affect the functionality of the phone.
Finally yesterday I understood that when I build those libraries for the target cm-d2tmo-eng, those files that I have modified are not considered at all! When the libraries are built indeed, the system automatically takes the libril.so and libreference.so present in the vendor folder!
The problem is that those libraries in the vendor folder and already compiled and I cannot modify them. The question is:
Is there any way that I compile those libraries from the source code that I have modified?
Thanks,
brok85
Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.
Perseus71 said:
Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
Click to expand...
Click to collapse
Well, as fisrt I just wanted to insert some log to be able to follow the code execution from the logcat or do something similar.
Perseus71 said:
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
Click to expand...
Click to collapse
Sorry but I am kind of new on this things. I have already downloaded the source code from the device tree and made my modifications in the files ril.cpp contained in [path-to-android-source]/hardware/ril/libril/ril.cpp. What I did was commenting the whole code within the function RIL_onUnsolicitedResponse() and listenCallback() such that in theory, the phone is not able to display incoming calls for example. However after flashing the re-built android I am still able to receve calls. How can I "check in the changes if they boot ok on my device"?
Perseus71 said:
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.
Click to expand...
Click to collapse
I tried to remove the libril.so in the vendor folder and compile again using
# . build/envsetup.sh
# lunch (and select d2tmo)
# mmm [path-to-android-source]/hardware/ril/libril".
The problem is that when I indicate the target after lunch, the compiler looks for the vendor libraries and stop the build. What I am doing wrong?
Sounds like Compiler Dependacy path is set different from the code base. I will look further before commenting.
For when your changes are for the benefit of the community of users, you check in the changed code back to the Device Tree with detailed comments within the code and while checking in.
Perseus71 said:
Given that there is a unified D2LTE Build on CM, can you elaborate on what changes you wish to make to these libraries ?
To answer your question, You can do one of two things.
Grab the CM Source Code from the Device Tree of D2LTE. Make your relevant changes and check in the changes if they boot ok on your device. That way those changes will be included in future builds of CM and other Roms that use it.
If you do not wish to do so, then you will have to compile those libraries using C++ Compiler on a *NIX box and replace them in the Vendor folder.
Click to expand...
Click to collapse
Perseus71 said:
Sounds like Compiler Dependacy path is set different from the code base. I will look further before commenting.
For when your changes are for the benefit of the community of users, you check in the changed code back to the Device Tree with detailed comments within the code and while checking in.
Click to expand...
Click to collapse
Actually this is what I get after deleting
libril.so in vendor/samsung/d2tmo/proprietary/lib/
and after executing mmm /hardware/ril/libril :
No private recovery resources for TARGET_DEVICE d2tmo
make: *** No rule to make target `vendor/samsung/d2tmo/proprietary/lib/libril.so', needed by `/home/brok85/Documents/android/system/out/target/product/d2tmo/system/lib/libril.so'. Stop.
make: Leaving directory `/home/brok85/Documents/android/system'
If u want to build from source, delete the line that copies in vendor-blobs.mk
If u want to copy the blob instead of building it from source, keep the line
It'll be better if u provide us the device and vendor trees links
blackbeard said:
If u want to build from source, delete the line that copies in vendor-blobs.mk
If u want to copy the blob instead of building it from source, keep the line
It'll be better if u provide us the device and vendor trees links
Click to expand...
Click to collapse
I am not sure to understand what should I provide Sorry, as I said I'm kind of new here...
Also, I can not find vendor-blobs.mk...Where it should be?
brok85 said:
I am not sure to understand what should I provide Sorry, as I said I'm kind of new here...
Also, I can not find vendor-blobs.mk...Where it should be?
Click to expand...
Click to collapse
You said you built a cm11 for ur device. So for that you needed the device and the vendor trees. Give the link of those, if they are on the git
And vendor-blobs.mk would be present in the vendor folder under your device folder
blackbeard said:
You said you built a cm11 for ur device. So for that you needed the device and the vendor trees. Give the link of those, if they are on the git
Click to expand...
Click to collapse
Well I have followed the guide in the following page
http://wiki.cyanogenmod.org/w/Build_for_d2tmo
The link from where I have obtained the repository is
$ repo init -u git://github.com/CyanogenMod/android.git -b cm-11.0
and then
$ breakfast d2tmo
blackbeard said:
And vendor-blobs.mk would be present in the vendor folder under your device folder
Click to expand...
Click to collapse
Actually now I think I was able to compile the library following your instructions. Unfortunatly, when I have built and flashed everything in the galaxy S3, I was not able to use the network. Probably some compatibility issue?
When I compiled libril.so, I have obtained it from the folder /hardware/ril/libril which should contain google source code, maybe not compatibale with my device...is it right?
thanks a lot for the help guys
brok85 said:
Actually now I think I was able to compile the library following your instructions. Unfortunatly, when I have built and flashed everything in the galaxy S3, I was not able to use the network. Probably some compatibility issue?
When I compiled libril.so, I have obtained it from the folder /hardware/ril/libril which should contain google source code, maybe not compatibale with my device...is it right?
Click to expand...
Click to collapse
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.
Perseus71 said:
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Click to expand...
Click to collapse
No silly question at all
I have compiled CM11 as it is and worked perfectly. I could use the network.
Perseus71 said:
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.
Click to expand...
Click to collapse
The procedure I have followed is the following one:
1) Delete the llibril.so and libreference-ril.so from the vendor library. These are the pre-compiled vendor libraries that I need to modify.
2) commented the lines from the vendor-blobs.mk that were including those two precompiled libraries.
3) go to android/system/ and run "mmm /hardware/ril/libril" and "mmm /hardware/ril/reference-ril" to obtain the modified libril.so and libreference-ril.so respectively.
4) copied the new libraries just obtained in the vendor folder where the pre-compiled libraries were
5) re-include the lines commented in point 2).
6) run brunch d2tmo
7) flash the .zip obtained
Any mistake?
Perseus71 said:
You know, silly question. But just so we can rule out. Did you at any point compiled the CM11 code as is and flashed to the phone ? How did Network behave ? Was everything ok ?
Click to expand...
Click to collapse
No silly question at all. Yes I have built everything out of the box and worked perfectly. I could use the network.
Perseus71 said:
Galaxy S3 is a very open platform with standard hardware and chipsets. So the Default google code should work out of box with it. If you have network issues, then just for kicks you can flash a custom Kernel on top of your compiled CM 11. See how that goes.
Click to expand...
Click to collapse
I followed the following procedure to include my modified libraries:
1) Eliminate precompiled vendor libraries: libril.so and libreference-ril.so from the vendor folder
2) comment lines in the vendor-blobs.mk that included those two precompiled libraries
3) from /android/system/ executed command "mmm /hardware/ril/librail" and "mmm /hardware/ril/reference-ril" to obtain the modified libril.so and libreference-ril.so
4) copied the new libraries in the vendor folder in the same places were the precompiled libraries were positioned
5) re-include the two lines that were commented in point 2)
6) build everything again with brunch d2tmo
7) flash the .zip obtained
Any mistake?
Unless I am having a brain fart that process seems about right. I wonder if your RIL changes are related to the network
What kind of issues do you see ?
Perseus71 said:
Unless I am having a brain fart that process seems about right. I wonder if your RIL changes are related to the network
What kind of issues do you see ?
Click to expand...
Click to collapse
It cannot even find the network operators. It says that it is impossible to connect and to try later...
mine is the Tmobile version of S3. May this influence?
That would depend on the changes you made. But otherwise not really. The underlying Device tree is unified for all US S3 devices.