Related
I attempted to build my own ICS today for my gnex. I followed this guide:
http://www.freeyourandroid.com/guide/compile-ics
All went well (ie slowly) and the build compiled without issue. Flashed the resulting zip and booted to ICS. However, I had no cell connection.
Now, looking back, it appears as though the radio binaries for the CDMA/LTE phone haven't been posted yet (http://code.google.com/android/nexus/drivers.html). I guess I got a little too excited when I saw the gpu binaries posted that I just went for it.
My question: are the radio binaries for the CDMA/LTE available anywhere?
On a side note, are there any "AOSP rom building 101" guides out there? I followed the tutorial above just fine, but I wasn't exactly sure what I was doing in each step.
On a different side, when 4.0.4 eventually comes out will I need to download the entire 3+GB source from Google or can I somehow just update the new stuff? I'm working with a 3mbps connection - took me an entire day to sync and build 4.0.3.
As always, thank you.
Deleted msg
ibe2fly said:
http://code.google.com/android/nexus/drivers.html#toroiml74k
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
Thank you. That's where I pulled the gpu drivers from, but the radio drivers aren't there. The wifi drivers are in the ICS source, but the CDMA/LTE don't appear to be.
Same here..
e4xda said:
I attempted to build my own ICS today for my gnex. I followed this guide:
http://www.freeyourandroid.com/guide/compile-ics
All went well (ie slowly) and the build compiled without issue. Flashed the resulting zip and booted to ICS. However, I had no cell connection.
Now, looking back, it appears as though the radio binaries for the CDMA/LTE phone haven't been posted yet (http://code.google.com/android/nexus/drivers.html). I guess I got a little too excited when I saw the gpu binaries posted that I just went for it.
My question: are the radio binaries for the CDMA/LTE available anywhere?
On a side note, are there any "AOSP rom building 101" guides out there? I followed the tutorial above just fine, but I wasn't exactly sure what I was doing in each step.
On a different side, when 4.0.4 eventually comes out will I need to download the entire 3+GB source from Google or can I somehow just update the new stuff? I'm working with a 3mbps connection - took me an entire day to sync and build 4.0.3.
As always, thank you.
Click to expand...
Click to collapse
Same happened to me. I found a post from JBQ saying that they don't yet have distribution rights to the binaries for the radios and camera (the thread is fairly informational). I'm sure there's a way to grab them off the device, if we knew what files are needed.
Damn dude ur a hawk lol tried to del my comment before misleading u
Sent from my Galaxy Nexus using Tapatalk
phazen18 said:
Same happened to me. I found a post from JBQ saying that they don't yet have distribution rights to the binaries for the radios and camera (the thread is fairly informational). I'm sure there's a way to grab them off the device, if we knew what files are needed.
Click to expand...
Click to collapse
I was thinking along those lines, just wanted to be sure, thanks.
@ibe2fly - happened to be sitting at the computer when my phone beeped
I'll be F5'ing this I'm intrigued.
Oh, and the answer to your question about having to re-download 4.0.4 is no, you will only have to download the differences between 4.0.3 and 4.0.4. All you need to do is change the branch using repo (repo init -u http://android.googlesource.com/platform/manifest -b android-4.0.4_r1 && repo sync). This of course assumes 4.0.4 is indeed the next release.
phazen18 said:
Oh, and the answer to your question about having to re-download 4.0.4 is no, you will only have to download the differences between 4.0.3 and 4.0.4. All you need to do is change the branch using repo (repo init -u http://android.googlesource.com/platform/manifest -b android-4.0.4_r1 && repo sync). This of course assumes 4.0.4 is indeed the next release.
Click to expand...
Click to collapse
Excellent, thank you! I was dreading having to download the whole sha-bang again for the next release... 3mbps... yeah, 3mbps...
To part 2 of my OP, is there a good TUT out there for ROM building? I'm not looking to do anything too extravagant, but I would like to be able to add my own apps, pull some stuff from CM source, maybe add in a UI MOD of some sort... Should also learn about some cleanup in my build environment. I have a 50GB virtual disk setup on my build machine, I'm sure I'll use that up quickly if I don't cleanup after myself - but, I'm not totally sure which files can go and which need to stay...
Thanks again
Here it is :
1. How exactly are updates pushed to aosp? Are they pushed only when they announce a release like the new 4.0.4? Looking at this page https://android-review.googlesource.com/ it appears the updates are in real time but why is it that we are waiting for 4.0.4?
2. Let's say I build from the latest aosp now including the proprietary drivers specific to my nexus device. Is the result exactly the same as factory ota image? Or does Google make some small specific changes specific to devices?
3. Why is it that non nexus devices that get ICS unofficial roms even after the official release from the manufacturer still lack some functionally? Why is it not possible to use the proprietary libraries and drivers from the official update?
4. Does this page https://android-review.googlesource.com/ include all the changes the Google makes to aosp? What are the important ones compared to 4.0.3?
5. How do rom developers like teamkang or gummy etc port their 4.0.3 roms to 4.0.4? Do they have to add their extra code manually to each file or do code management tools like git take care of everything?
Sorry about the long questions I'm just really curious.
Thanks!
ArmanUV said:
Here it is :
1. How exactly are updates pushed to aosp? Are they pushed only when they announce a release like the new 4.0.4? Looking at this page https://android-review.googlesource.com/ it appears the updates are in real time but why is it that we are waiting for 4.0.4?
2. Let's say I build from the latest aosp now including the proprietary drivers specific to my nexus device. Is the result exactly the same as factory ota image? Or does Google make some small specific changes specific to devices?
3. Why is it that non nexus devices that get ICS unofficial roms even after the official release from the manufacturer still lack some functionally? Why is it not possible to use the proprietary libraries and drivers from the official update?
4. Does this page https://android-review.googlesource.com/ include all the changes the Google makes to aosp? What are the important ones compared to 4.0.3?
5. How do rom developers like teamkang or gummy etc port their 4.0.3 roms to 4.0.4? Do they have to add their extra code manually to each file or do code management tools like git take care of everything?
Sorry about the long questions I'm just really curious.
Thanks!
Click to expand...
Click to collapse
1. All Nexus OS versions are AOSP. We are waiting for the OTA because Google only sends the update to a few people at a time, because sending it to everyone all at once would make their servers very unhappy.
2. You'd just be missing the radio I believe.
3. The proprietary stuff is for their skinned OS versions, and is not necessarily usable for vanilla Android.
4 and 5 are beyond me :/
Sent from my Galaxy Nexus
I s it possible the rooted Galaxy Nexus to get the OTA ICS 4.0.4?
ragnarokx said:
1. All Nexus OS versions are AOSP. We are waiting for the OTA because Google only sends the update to a few people at a time, because sending it to everyone all at once would make their servers very unhappy.
2. You'd just be missing the radio I believe.
3. The proprietary stuff is for their skinned OS versions, and is not necessarily usable for vanilla Android.
4 and 5 are beyond me :/
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
thanks. you misunderstood my first question though. I know that nexus images are based off aosp. What I meant is that the changes on android gerrit review system are public and in real time. So why is it that a release like 4.0.4 is a big deal?
CakraMas said:
I s it possible the rooted Galaxy Nexus to get the OTA ICS 4.0.4?
Click to expand...
Click to collapse
Not the best place to ask this question but I think if you're on yajuko and you have stock bootloader (not cwm) then you may be able to get ota but you'll lose root.
4.0.4 ota is compiled by google from it's internal tree.
What you see in gerrit is the reviewing process for the master branch (and a few others), where everyone can submit, which should be updated (merged) with google internal tree everytime a ota/source gets released.
ArmanUV said:
thanks. you misunderstood my first question though. I know that nexus images are based off aosp. What I meant is that the changes on android gerrit review system are public and in real time. So why is it that a release like 4.0.4 is a big deal?
Not the best place to ask this question but I think if you're on yajuko and you have stock bootloader (not cwm) then you may be able to get ota but you'll lose root.
Click to expand...
Click to collapse
Because those sources are actually not released until google starts the ota update. They develop behind closed doors then release all new code at once with the ota. Some people dont like this but i dont think it matters prrsonally.
---------- Post added at 06:53 AM ---------- Previous post was at 06:51 AM ----------
5. Github has a diff function that can compare any two files and even merge the code together. So the devs likely use diff to check all new code and merge.
4. You can look thru all the commits to actually see the newest code changes to see whats important etc.
bk201doesntexist said:
4.0.4 ota is compiled by google from it's internal tree.
What you see in gerrit is the reviewing process for the master branch (and a few others), where everyone can submit, which should be updated (merged) with google internal tree everytime a ota/source gets released.
Click to expand...
Click to collapse
so Gerrit commits are just a very small percentage of all the changes, right?
and does that mean that ota updates may be (slightly) different from aosp compiles?
and that they are no changes to aosp between releases?
thanks!
ArmanUV said:
so Gerrit commits are just a very small percentage of all the changes, right?
and does that mean that ota updates may be (slightly) different from aosp compiles?
and that they are no changes to aosp between releases?
thanks!
Click to expand...
Click to collapse
gerrit commits to the master branch are most of time submitted by people working outside of google.
yes, compiling from the master branch of aosp is slightly diferent than from compiling through release tags (4.0.3_r1, 4.0.4_r1.1).
tagged releases are the same as an OTA, except it doesn't have radio/bootloader images, since they're binaries. they don't change, ever. now the builds compiled from aosp master branch do change, even if it is only under the hood changes.
First things first: THANK YOU to all those involved in the coding of this, especially the msm8660-common kernel that so many folks have put so much effort into, and Mr. Cyanogen for the device tree, etc etc. NONE of this would be possible without your efforts. I stand on the shoulders of giants in providing these instructions, the code is NOT mine, I'm just documenting this so you all can help contribute. Kindest regards to everyone who has contributed to make this possible. Your work has enabled the community to beat the vendor to the punch, yet again!
DISCLAIMER: This contains information on working with very early code as well as hacking together a completely unsupported Frankenstein build with some proprietary samsung binaries from another device (ATT Note) and I will warn you: If you aren't willing to risk bricking your device, don't even think about this. Also, I'm not so much a coder as I am a QA engineer, so I know enough to be dangerous, but I couldn't code C++ get myself out of a virtual crashing airplane if I had to. I also might not be able to help you out of a sticky situation, so... have fun at your own risk! But do have fun
Looking for binaries? See post #2
That said, it's honestly not likely any of this will brick your tab, if you know what you're doing, but... early software always carries danger, and using binaries from a similar yet different device can do who knows what.
Also of note: you should probably back up your EFS partition if you're going to hose with the radios to get cellular data working... hasn't been an issue for me, but... corrupt EFS partition = no more cellular data for you. ever.
Cyanogen has added initial support for the i957 to the CM10 repository, and it's looking good so far! But, there are no nightly builds yet, probably because Cyanogen would like to do some more work on it before handing out binary packages... Or maybe he hasn't figured out how to get things quite functional yet. I considered releasing a binary package for you to toy with, but then realized that would defeat the purpose of helping along the development of an official Cyanogen i957 (p5att) release, and lock you into something I already built from "pre-alpha" code. It's best to check out the latest source tree and do your own build, then you can easily test and contribute your modifications, should you find any.
So with that, here's some instructions on how to build CM10 for your SGH-I957 ("p5att") device from source code. This will also ensure time is spent doing development work, not hand-holding the faint of heart (sorry, sue me!)
These instructions assume you've successfully built Cyanogenmod for a supported device and understand the basics of getting things going. If not, start with that first, then come back to this. I'm also assuming you've got the android tools that you get from any build of cyanogen (like mkbootimg) in your path for some of the "optional" steps, which is of course elementary...
I'm also going to assume you know what to do with the resulting zip... You know... backup, factory reset, wipe system, flashy the zippy...
I really recommend doing the boot image modifications after the build, without ADB on boot, if something goes wrong, you'll have no way of knowing whats going on. If you get the boot image modified properly as detailed below, you will be able to ADB to the device as soon as the second boot logo disappears. Also, there's probably a cleaner way (like changing something somewhere to invoke one of the other case statements in init.qcom.usb.rc), but I didn't have any luck with that. Feel free to school me! :laugh:
EDIT: If you don't feel like hacking the boot image, just flash the one attached (ps: none of the zips below are TWRP/CWM flashable, just zipped up files.. dd if=bootimagefilename of=/dev/block/mmcblk0p8 from a root shell to flash the boot partition on the i957)
I've attached the initlogo.rle file to this post so you don't have to fish it out of the ramdisk embedded in the stock boot image. Adding initlogo.rle to the ramdisk gives you confirmation the kernel is bootstrapping, and it's disappearance indicates ADB is now available. Also, use a linux box for ADB! silly wabbit, windoze is for kids.
According to comments in system.prop, the cyanogenmod boot animation is disabled because the framebuffer is "weird". Strangely, it sometimes displays for me, one in 10 boots maybe. Weird!
Here goes.
----
Initialize Repo:
repo init -u git://github.com/CyanogenMod/android.git -b jellybean
Sync Repo:
repo sync -j6
... Coffee Break!
Breakfast for p5att:
. build/envsetup.sh && breakfast cm_p5att-userdebug
Modify device/samsung/p5att/BoardConfig.mk to clean up a few things:
Comment out:
#BOARD_SDCARD_DEVICE_PRIMARY := /dev/block/mmcblk1p1
#BOARD_SDCARD_DEVICE_SECONDARY := /dev/block/mmcblk0p28
#BOARD_SDEXT_DEVICE := /dev/block/mmcblk1p2
Add above these lines:
BOARD_HAS_SDCARD_INTERNAL := true
Modify device/samsung/p5att/device-proprietary-files.txt:
Comment out all the entries, because they aren't really needed and probably dont work with jellybean. Worry about this later, blah blah.
Modify device/samsung/msm8660-common/common-proprietary-files.txt:
Comment out all the WiFi stuff, that is, like:
# Wi-Fi
# etc/wifi/bcm4330_apsta.bin
#etc/wifi/wl
#etc/wifi/nvram_net.txt
#etc/wifi/wpa_supplicant.conf
#etc/wifi/bcm4330_p2p.bin
#etc/wifi/bcm4330_sta.bin
#etc/wifi/bcm4330_mfg.bin
#etc/wifi/nvram_mfg.txt
To get WiFi working later, you need /system/etc/wifi/* from your honeycomb image. Go save them to /sdcard/wifi or something like that now, so you can just copy them over after CM10 boots
Edit: attached the files
Extract proprietary files from i717 Note CM10 image, since I have no idea where else to get these files, and they work:
from device/samsung/p5att, run ./extract-files.sh <path to an extracted CM10 i717 nightly .zip>
... The path you provide should contain the "system" folder.. IE the root of the extracted nightly zipfile.
I had used the 0831 nightly with luck here.
Get prebuilts:
run vendor/cm/get-prebuilts
Do the build:
from the system directory of your CM10 source tree run:
. build/envsetup.sh && brunch p5att
Go find something or someone to do, this is going to take a while...
You'll end up with a .zip file to flash.
After you flash, you'll need to, manually:
1) Copy back the /system/etc/wifi/* files (wifi firmware/tools, the note ones dont seem to work).
2) Install a Skyrocket ICS AT&T radio if you want cellular data, the honeycomb radio doesn't seem to work with CM10. UCLF6 works for me, although it's slower to acquire LTE than the official samsung HC image... but it works great once it finds a cell, and HSPA comes up pretty fast.
3) Consider doing the stuff below to enable early ADB and add back the second samsung logo, for debugging purposes, if you care...
----
Things you might want to do after the build, start by unzipping the resulting .zip pacakge...
Edit: I attached a the resulting boot.img to this post so you don't have to do all this if you so desire. Bonus: working i957 JB kernel binary for whatever else you might want to do with it..
Remove the assert for platform type if your TWRP recovery, like mine, thinks it's a i717 Note:
Edit META-INF/com/google/android/updater-script, remove the assert lines (first two lines of that file)
Do some handy ramdisk hacks:
First, unpack the boot image. From the root of what you unzipped:
mkdir boot
unpackbootimg -i boot.img -o boot
cd boot
Then Unpack the initial ramdisk:
mkdir rd
cd rd
zcat ../boot.img-ramdisk.gz | cpio -id
Edit init.qcom.usb.rc to enable early adb:
Search for "on property:sys.usb.config=mtp", you'll find: (line 340, for me)
on property:sys.usb.config=mtp
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 04E8
write /sys/class/android_usb/android0/idProduct 6860
write /sys/class/android_usb/android0/f_acm/acm_transports tty
write /sys/class/android_usb/android0/functions mtp,acm
write /sys/class/android_usb/android0/enable 1
setprop sys.usb.state $sys.usb.config
Make this section like:
on property:sys.usb.config=mtp
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 04E8
write /sys/class/android_usb/android0/idProduct 6860
write /sys/class/android_usb/android0/f_acm/acm_transports tty
write /sys/class/android_usb/android0/functions mtp,acm,adb
write /sys/class/android_usb/android0/enable 1
start adbd
setprop sys.usb.state $sys.usb.config
Add the glowing samsung initlogo:
Copy initlogo.rle from the root of a stock ramdisk to the root of this ramdisk
... So you'll get the second samsung logo, so you know the kernel is bootstrapping... if you care.
Turn off ro.secure:
Edit default.prop in the root of the ramdisk and change:
ro.secure=1
to
ro.secure=0
Repack the ramdisk:
find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.gz
(you may want to save the original, if you care)
Make the new boot.img:
cd .. (ie get back to the directory with the files listed in the next line)
rm ../boot.img
mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz --cmdline "console=ttyHSL0,115200,n8 androidboot.hardware=qcom" --base 48000000 --ramdiskaddr 49400000 --pagesize 2048 -o ../boot.img
Repack the flashable zip:
cd .. (ie get back to where you unzipped the original flashable .zip)
rm -rf boot (remove the extracted boot.img and ramdisk under it, save it somewhere if you care)
(also remove the original .zip from here if you extracted it in the cwd)
zip -r ../somezipname.zip .
Then flash somezipname.zip or whatever you called it..
(Remember you'll need to put the Honeycomb files from /system/etc/wifi into /system/etc/wifi of the running image after you boot if you want wifi
(And flash a Skyrocket ATT radio if you want cellular data!)
WARNING: FOR SAMSUNG SGH-I957 NORTH AMERICAN DEVICES ONLY
GT-SERIES (IE: GT-7320, etc) ARE NOT SUITABLE FOR THIS RELEASE
UPDATE ZIP DOES _NOT_ CHECK YOUR PRODUCT CODE, WILL HAPPILY EAT OTHER DEVICES
THIS IS A TEST RELEASE FOR EXPERIENCED ANDROID HACKERS
SOME FEATURES MAY NOT BE USABLE OR WORK AS INTENDED
BOOTLOOP ISSUE? USE TWRP 2.1.4: https://www.dropbox.com/s/u07zrx808a5ae2z/i957_twrp_recovery.img.tar
Latest Flashable .ZIP, update 7: http://droid.arm.ee/957/cm10_p5att_nrvate_testrelease7.zip
Use TWRP, factory reset and wipe /system if you are coming from another ROM. Don't forget to install google apps http://wiki.cyanogenmod.com/index.php?title=Latest_Version/Google_Apps
Update 2
* h264 hardware decode fixes for youtube HQ and other hardware-decode enabled apps (vidc/yamato firmware update)
* camera fixes from kunals.shah -- thanks!! (camera library in system/lib/hw)
* wifi address fix - get MAC from EFS, no more random address (insert proper path to .nvmac.info in dhd.ko kernel module)
* move /mnt/secure to internal sdcard to fix asec apps (asec folder linked to /sdcard/.asec)
* disable adb on early boot -- fix mtp maybe? (change to init scripts in ramdisk)
* remove a couple of (probably) harmless references to sdcard1 in init scripts
* update vold.fstab with the correct partition for the sdcard (26), not sure if anything even uses that, but...
Update 3
* Kernel Lovins ->
--- Picked up slew of bugfixes from msm8660-common cyanogenmod jellybean kernel tree -- up to and including 09/13/2012 commits.
--- Enabled CONFIG_USB_ANDROID_SAMSUNG_MTP and CONFIG_SPI_QUP kernel options to match SHV-140 ICS samsung kernel config
--- Disabled CONFIG_XVMALLOC and CONFIG_ZRAM kernel options, also to match up to SHV-140 ICS samsung kernel config
--- Now compiled with newest Sourcery cross-compiler
--- Modified dhd.ko (Broadcom WiFi kernel module) -- you can now create file /data/.ranmac if you want your MAC address randomized on each reboot (ignores MAC on EFS partition, random generation expanded to 5 bytes)
* symlink for light sensor (/dev/i2c11 -> /dev/i2c-11) -- Doesn't fix auto brightness, but at least things that access the light sensor via the standard API will get values back now, FWTW.
* RIL stuff from SHV-140S (korean Tab 8.9 LTE) -- An attempt to resolve SIM_NOT_READY error -> Files replaced:
/system/lib/libril-qcril-hook-oem.so
/system/lib/libsecril-client.so
/system/lib/libreference-ril.so
/system/lib/libril.so
/system/lib/libril-qc-qmi-1.so
/system/bin/qmuxd
/system/bin/qmiproxy
/system/bin/netmgrd
* Update /system/etc/wifi stuff -- newer broadcom firmware images, wpa_supplicant.conf with p2p parameters
* Reenable early ADB since it appears MTP issues likely related to lack of CONFIG_USB_ANDROID_SAMSUNG_MTP kernel option -- Maybe someone who uses MTP can tell me whats up now?
Update 4
* Fix A2DP bitrate (48000 -> 44100 in /system/etc/audio_policy.conf)
* More invasive ASEC fix that might actually fix this jellybean nonsense (modified vold to use /data/secure locations, create /data/secure directory tree in init.emmc.rc)
* Revert SHV-140 RIL change, back to Note CM10 RIL libraries
Update 5
* Android 4.1.2 - Complete rebuild from CM10 tree retrieved on October 12th. Includes ASEC hack as in update4.
* SGH-i957 Radio Information Libraries (RIL) from official Telus ICS image - Thanks Dan!
Update 6
* Rebuilt from CM10 source code retrieved Nov 10 2012. ASEC hack applied.
* Update to latest msm8660-common kernel. Kernel unmodified (ie: no overclocking).
Update 7
* Rebuilt from CM10 source code retrieved Dec 20 2012. ASEC hack applied.
* Update to latest msm8660-common kernel. Kernel unmodified (ie: no overclocking).
Fantastic!
Are you saying everything seems to work pretty well except the 4G radio? (No guarantees, at my own risk, etc. etc. I know, I won't blame you)
If so, I'm going to try this right away. I don't have a data plan for my SIM, and haven't used the 4G yet. (Got a free upgrade from the wifi version after some shipping trouble with the vendor.)
The Galaxy Tab has been kind of a letdown when I have JB on my Galaxy Nexus and Kindle Fire both, and the "upgrade" is a bit disappointing since I checked on custom ROMs *before* I ordered, but the AT&T version is further behind.
Thanks for your hard work! I'll let you know what happens.
YellowRex said:
Fantastic!
Are you saying everything seems to work pretty well except the 4G radio? (No guarantees, at my own risk, etc. etc. I know, I won't blame you)
Thanks for your hard work! I'll let you know what happens.
Click to expand...
Click to collapse
I haven't had time to try "everything", but the stuff that I use on a regular basis is mostly functional. There's quirks, but... It's usable!
For example, one thing I just found out.. the Adreno (qualcomm MSM graphics) drivers aren't production-build.. There's no such thing available -- The current drivers available from qualcomm are "early sample" binaries for jellybean bringup testing, which is what this is... So, I've seen the random screen flicker, etc. Remember there are only a few devices with tested jellybean images, and most of them are google devices... And the i957 will probably never see an official JB release.
https://developer.qualcomm.com/mobi...phics-optimization-adreno/tools-and-resources
This release contains an early sample of the user-mode driver binaries for Qualcomm's Adreno 2xx GPU on Google Android 4.1 Jelly Bean. It has been tested with the CAF release M8960AAAAANLGD105210.1 and supports any Adreno 2xx GPU on Android 4.1 Jelly Bean. This release is intended only for developers that work on Jelly Bean bring-up work. It is an early release sample which will be replaced by a new driver binary in the future.
Click to expand...
Click to collapse
I'm sure there's plenty of little quirks you can find if you "twiddle all the knobs and flip all the switches" -- But it's certainly testable, and way closer to the "usable" end of the spectrum than the "barely functions" end.
Cheers!
PRE-ALFA CM10 Build
You did a great job nrvate !!. you inspired me to get ICS/JB on my SGH-i957. I did try your method and seems everything (3G, SMS, GPS, Bluetooth, Camera etc..) works except wifi. I am surprised that Voice calling is also working in this build !!! I will update you once I fix wifi issue. and also provide CWM/TWRP/ODIN flashable build if time permits.
Cheers !!
-KS
Its so exciting to see some real pregress.
Sent from my SAMSUNG-SGH-I957 using xda app-developers app
Ditto. This is really good news. Thanks.
Cheers, y'all!
Only thing I had to do to get wifi working was stuff the original stuff (from honeycomb) in /system/etc/wifi.
first thing I'd do is make sure the dhd module is getting loaded.. dmesg will print your kernel log that'll show problems with loading that module.. also, try rmmod dhd and insmod dhd, see what happens.
If the DHD module doesn't report symbol errors or some nasty like that, make sure it's loading the firmware -- That'll probably leave an error in dmesg also if it's broke.
also check logcat for wifi-related nastiness
If you can find a specific problem post it and I'll try to help reproduce/solve.
Also working on hacking together a build of ICS based on what's been done with JB, but no idea how that's going to turn out yet. It'd be nice to have as a daily until qualcomm releases production-grade adreno graphics drivers (and, the CM9 ICS tree is now "final", might as well build it!)
update: due to needing the "late model" msm8660-common kernel for proper i957 device support, the later qualcomm (JB) graphics drivers are required too.. drat! however, looks like I'll still be able to hack together a build of CM9 based on the current "final" ics branch using the JB kernel and beta qualcomm graphics. got 'er booted, working out the kinks now. I'll start another thread for that when it's done
i wish i knew half as much as you do, keep up the good work!
orlandoxpolice said:
i wish i knew half as much as you do, keep up the good work!
Click to expand...
Click to collapse
Thanks! Learning as I go with half this.. It's just bits, try one way, get dirt.. try another way, get bacon!
Some of this is so touchy.. ie kernel versions vs adreno drivers, blah blah.. seeing what the SHV-140 kernel does.. it boots CM9, now to see if it'll play nice with video decoders. might forget CM9, i <3 jelly beans anyways!
nrvate said:
Thanks! Learning as I go with half this.. It's just bits, try one way, get dirt.. try another way, get bacon!
Some of this is so touchy.. ie kernel versions vs adreno drivers, blah blah.. seeing what the SHV-140 kernel does.. it boots CM9, now to see if it'll play nice with video decoders. might forget CM9, i <3 jelly beans anyways!
Click to expand...
Click to collapse
Solid work/mashery my friend. This indeed great news. I am currently waiting for my zip file to spit out, do a few mods and then give it a flash when I complete those things.
As far as the adreno drivers have you checked the site for them? I recall reading about them on another msm8660 device and perhaps may pertain to this project as well. The screen flicker has a few work arounds based on other devices that may relate to this device as well. Either to get rid of the flicker entirely or at least minimize them. Worth trying (here are a few I have seen work on some devices.. dev options, disable HW overlay, another is adjusting the debug.mdpcomp.maxlayer value in build.prop from 3 to 2, another is to set the min CPU freq to 486mhz).. last but not least, this was posted on cyanogenmod review, and can be cherry picked if not merged already: http://review.cyanogenmod.com/#/c/22782/ and may work. As far as getting LTE to light up in a more prompt manner, it may be worth exploring different modems (I see you are using UCLF6 from the i717 note), there are many others from the i717 leaks (ie. UCLF5, UCLE2/3, etc etc) and also of course any other Skyrocket ICS+ modems, as well as i717m (canadian, rogers modems such as XLA2 (gingerbread but worked on the i717 note in the US) and various others. If you cannot located them I will post links when I have more time. This is a great start, and I will help out when I have time to contribute to this project (I have a few on my plate plus a full time job so sometimes having the time is a difficult venture). In any case, great start and I can see this will progress very well in due time. Congrats and thanks for your contribution to the base of this, as this progresses and we work to manage these small issues, we will have something even solid
Regards,
th3g1z
th3g1z said:
Solid work/mashery my friend. This indeed great news. I am currently waiting for my zip file to spit out, do a few mods and then give it a flash when I complete those things.
As far as the adreno drivers have you checked the site for them? I recall reading about them on another msm8660 device and perhaps may pertain to this project as well. The screen flicker has a few work arounds based on other devices that may relate to this device as well. Either to get rid of the flicker entirely or at least minimize them. Worth trying (here are a few I have seen work on some devices.. dev options, disable HW overlay, another is adjusting the debug.mdpcomp.maxlayer value in build.prop from 3 to 2, another is to set the min CPU freq to 486mhz).. last but not least, this was posted on cyanogenmod review, and can be cherry picked if not merged already: http://review.cyanogenmod.com/#/c/22782/ and may work. As far as getting LTE to light up in a more prompt manner, it may be worth exploring different modems (I see you are using UCLF6 from the i717 note), there are many others from the i717 leaks (ie. UCLF5, UCLE2/3, etc etc) and also of course any other Skyrocket ICS+ modems, as well as i717m (canadian, rogers modems such as XLA2 (gingerbread but worked on the i717 note in the US) and various others. If you cannot located them I will post links when I have more time. This is a great start, and I will help out when I have time to contribute to this project (I have a few on my plate plus a full time job so sometimes having the time is a difficult venture). In any case, great start and I can see this will progress very well in due time. Congrats and thanks for your contribution to the base of this, as this progresses and we work to manage these small issues, we will have something even solid
Regards,
th3g1z
Click to expand...
Click to collapse
Thanks for the input! The flicker, as is, is really minor. It only really seems to happen, for me atleast, in the main launcher window and sometimes when scrolling in maps. It's intermittent, actually. I will have a look at that change you linked, nice catch!
Qualcomm's dev site is linked in post #4, hopefully they will post the final drivers soon. Do they have another site that would receive them faster, or with incremental builds? I really wish OEMs would share engineering builds more openly with the community, but I guess I'm just used to being on an engineering team, lol. I've been spoiled with working for a few of the larger OEMs and getting all the cool toys first...hehe.
I tried a few of the note ICS radios, got nothing at all from them besides errors in logcat -b radio, wouldn't bring up the SIM.
All the skyrocket radios seem to work to varying degrees.
Also, it may be more of the RIL -- The UCLF6 skyrocket modem works very nicely on the stock honeycomb image, insta-LTE and everything.
I have not tried any of the non-ATT radios... wasn't sure how that'd work out. I'll give some of the non-ATT radios a go, why not! Besides Skyrocket or Note, any other similar devices? Only thing I can think of is the SGS II LTE HD (SGH-i757) but not much is available for that device as AT&T punted it for the S III (747) and it never got popular.. If you want the HD screen, you get a S-III, which came out about a month later, which is just why ATT punted it all together.
I hear you on the job. I've got an interview lined up for a better one, too! Man, I'm hoping that works out!
nrvate said:
Thanks for the input! The flicker, as is, is really minor. It only really seems to happen, for me atleast, in the main launcher window and sometimes when scrolling in maps. It's intermittent, actually. I will have a look at that change you linked, nice catch!
Qualcomm's dev site is linked in post #4, hopefully they will post the final drivers soon. Do they have another site that would receive them faster, or with incremental builds? I really wish OEMs would share engineering builds more openly with the community, but I guess I'm just used to being on an engineering team, lol. I've been spoiled with working for a few of the larger OEMs and getting all the cool toys first...hehe.
I tried a few of the note ICS radios, got nothing at all from them besides errors in logcat -b radio, wouldn't bring up the SIM.
All the skyrocket radios seem to work to varying degrees.
Also, it may be more of the RIL -- The UCLF6 skyrocket modem works very nicely on the stock honeycomb image, insta-LTE and everything.
I have not tried any of the non-ATT radios... wasn't sure how that'd work out. I'll give some of the non-ATT radios a go, why not! Besides Skyrocket or Note, any other similar devices? Only thing I can think of is the SGS II LTE HD (SGH-i757) but not much is available for that device as AT&T punted it for the S III (747) and it never got popular.. If you want the HD screen, you get a S-III, which came out about a month later, which is just why ATT punted it all together.
I hear you on the job. I've got an interview lined up for a better one, too! Man, I'm hoping that works out!
Click to expand...
Click to collapse
I hear you on OEM not releasing the drivers in a timely fashion, and it is frustrating when you have sources for it as "leaks" .. pertaining to your question I did see a link to update drivers but in my 5 min search (short on time atm, work early in the morning), I didn't find it yet, but I will look a bit deeper and hopefully can find it. I recall it related to CM10 and addressing said drivers for a particular device or devices. I will see what I can find tomorrow, and hope that it pertains.
No harm in trying a few other modems, I would look at the i717/i717m (m is the canadian model, same device though and the modems from rogers work with the i717 as well as the skyrocket).. and obviously the skyrocket various modems which it seems you have tried at least a few of. They vary so much and your location has a lot to do with it. Some work better in certain areas, and others in other areas as I'm sure you know already. Worst case, even after trying a few you can always go back to UCLF6. I found it a bit odd that the rogers modems worked with ATT but hey I'm not complaining about that one I believe you are correct, however, pertaining to the RIL as being the issue, not so much the modem's themselves. (no telling though without trial/error)
I'm not sure the i747 modems would work or not, but, it will not hurt to try, as you can return to UCLF6 if it is a dead end. the i757 I have yet to even see, so I can't comment on that in particular.
I'd like to chat a bit more when we both have some time, not sure if you get on IRC (freenode network) at all but if you do look me up, same handle as here on XDA. It would be easier to chat that way.
I have more to say but having to be away in about 4 hours, I will have to get back to you. Good luck w/ the interview bud.
Take care, we'll catch up soon.
~th3g1z
th3g1z said:
I hear you on OEM not releasing the drivers in a timely fashion, and it is frustrating when you have sources for it as "leaks" .. pertaining to your question I did see a link to update drivers but in my 5 min search (short on time atm, work early in the morning), I didn't find it yet, but I will look a bit deeper and hopefully can find it. I recall it related to CM10 and addressing said drivers for a particular device or devices. I will see what I can find tomorrow, and hope that it pertains.
No harm in trying a few other modems, I would look at the i717/i717m (m is the canadian model, same device though and the modems from rogers work with the i717 as well as the skyrocket).. and obviously the skyrocket various modems which it seems you have tried at least a few of. They vary so much and your location has a lot to do with it. Some work better in certain areas, and others in other areas as I'm sure you know already. Worst case, even after trying a few you can always go back to UCLF6. I found it a bit odd that the rogers modems worked with ATT but hey I'm not complaining about that one I believe you are correct, however, pertaining to the RIL as being the issue, not so much the modem's themselves. (no telling though without trial/error)
I'm not sure the i747 modems would work or not, but, it will not hurt to try, as you can return to UCLF6 if it is a dead end. the i757 I have yet to even see, so I can't comment on that in particular.
I'd like to chat a bit more when we both have some time, not sure if you get on IRC (freenode network) at all but if you do look me up, same handle as here on XDA. It would be easier to chat that way.
I have more to say but having to be away in about 4 hours, I will have to get back to you. Good luck w/ the interview bud.
Take care, we'll catch up soon.
~th3g1z
Click to expand...
Click to collapse
I'll hit you up on IRC at some point for sure
So I sort of figured it out... Found how to get the radio to play nice, still don't know why... The kernel! Went back to the 3.0.8 kernel as provided by samsung for the SHV-140 (replaced zImage in boot.img, reflashed mmcblk0p8) and BAM. Nice quick 4G. Nothing in /system changed (so a bunch of other stuff broke) but the radio sure got happy.
Not sure what the difference is, quite yet... Should be an interesting needle in the hackstack for sure.
Is the package manager a problem with this the same as cm9?
Sent from my SGH-I727 using xda premium
orlandoxpolice said:
Is the package manager a problem with this the same as cm9?
Click to expand...
Click to collapse
yes, the issue actually originated with jellybean -- since there's no device tree in the cm9 repo for the p5att, i jammed the cm10 p5att device tree into cm9 source to make it happen. the device tree includes the init scripts, so the problem actually originated from cm10, lol.
same fix works.. mount tmpfs on /mnt/secure (in addition to /tmp/asec) and use wide-open (777) permissions.
nrvate said:
same fix works.. mount tmpfs on /mnt/secure (in addition to /tmp/asec) and use wide-open (777) permissions.
Click to expand...
Click to collapse
Heh! Is it just me or does that feel a little less than 'secure'? :silly:
i feel like a english lit major walking into an advanced calculus class with this jargon
This is how the sausage gets made.
Speaking of making sausage, I'm starting to think this is stable enough to share a binary build...
1) Camera is borked. I'm at a bit of a loss to figure it out, maybe I'll try again next week -- Suggestions very welcome, I'd like to get this working for video chat ala skype / gtalk.
2) MTP is borked. Again, at a bit of a loss, I suppose I'd care if I used it... Silly MTP.
3) New kernel fixes radio issues (mostly) - I've had it completely refuse to come up, showing no signal, fixed by rebooting the tablet. Goes right to LTE, but defaults to HSPA only. Change to LTE / GSM / WCDMA in mobile network settings -> network mode.
4) /mnt/asec / /mnt/secure issue (play store install problems) resolved.
5) FC in Settings -> Storage resolved by removing sdcard1 (which will never exist) from the build config
6) Boot animation is disabled due to framebuffer problems (supposedly) -- i know the spinny thing is cool, but you'll have to live with a black screen. Strangely, it comes up on some boots. lol.
7) Qualcomm graphics drivers are still the pre-release version. They seem to work pretty nice though. Haven't seen any of the flickering since some mdp changes in the kernel.
8) Video codecs aren't as screwed up as they are in the ICS build I did -- IE youtube works for all the videos I tried and bsplayer for android nicely plays my favorite x264 720P tv shows (win! gotta keep myself entertained at work some how...)
9) overclocked kernel HACK WARNING for you purists -- Modifed the kernel slightly, it now recognizes all MSM8660's as having the higher binned speed (1.66 vs 1.50 ghz) -- I didn't touch the frequency tables or anything, since it made more sense to just recognize the parts as 1.66ghz parts. Also, removed the logic that limited single-core mode to 1.2ghz (why?!). Gabe put out a OC kernel and most people reported stability at 1.7+ ghz, so... 1.66 seemed good. Hasn't borked for me. If you want stock speeds bad enough or run into problems.. http://d-h.st/8mB
Usual procedure, TWRP.. factory reset, wipe system, flash zip, receive bacon.
Bacon: http://d-h.st/Klu
I've been using this as my daily the past few days, and unless it starts behaving badly for some reason, it's probably going to be my daily for the foreseeable future. Really want to get the cams working, though!
Please share other issues. There has to be something else horribly broken I haven't noticed.
Usual "may make zombies run out of your tablet" warning applies to this test software.
Enjoy!
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.
Presenting CM13 unofficial. Built from mostly pure CyanogenMod sources, with a few tweaks that I try to keep updated on my github. This is only possible due to the work of Ziyan and MWisBest.
Instructions
First time flashing CM13 to your toroplus (or coming from another ROM)?
Unlock & install a recovery
Wipe data & cache partitions
Flash CyanogenMod.
Optional: Install the Google Apps addon package.
Updating from a previous build?
Just install the latest ROM zip. If you had Google Apps installed, they will be reinstalled automatically.
Click to expand...
Click to collapse
Downloads
Latest cm-13.0 build: https://www.androidfilehost.com/?fid=24588212152305191
Final cm-12.1 build: https://www.androidfilehost.com/?fid=24438995911970260
All builds: https://www.androidfilehost.com/?w=files&flid=23531
Unofficial TWRP recovery: https://www.androidfilehost.com/?fid=24459283995311440
Google Apps: http://opengapps.org/
- Platform: ARM
- Android: 6.0
- Variant: pico (recommended), or nano
Bugs
LTE Data does not work. (3G works)
XDA:DevDB Information
UNOFFICIAL CyanogenMod 13.0 (DDK 1.9), ROM for the Samsung Galaxy Nexus
Contributors
musical_chairs
Source Code: https://github.com/CyanogenMod
ROM OS Version: 6.0.x Marshmallow
ROM Kernel: Linux 3.0.x
Based On: CyanogenMod
Version Information
Status: Beta
Created 2014-09-25
Last Updated 2016-07-15
now with Marshmallow!
Will this be updated to work with the new GPU drivers? Thank you!
Sent from my LG-LS980 using XDA Free mobile app
illinoissparks18 said:
Will this be updated to work with the new GPU drivers? Thank you!
Sent from my LG-LS980 using XDA Free mobile app
Click to expand...
Click to collapse
Short answer: yes. I'm going to try grabbing the relevant code from MWisBest's githib. If it turns out to be too involved for my limited skills, it will have to wait until Ziyan submits the changes to CM.
musical_chairs said:
Short answer: yes. I'm going to try grabbing the relevant code from MWisBest's githib. If it turns out to be too involved for my limited skills, it will have to wait until Ziyan submits the changes to CM.
Click to expand...
Click to collapse
OK I am going to be on board with testing for sure. I left a post in the now no longer current official thread that I flashed the last official build yesterday and I had perfect 3G to LTE to 3G handoff, rock solid WiFi strength, basically everything seemed to work very well. I am looking forward to seeing how things progress. I haven't been able to keep any of the official CM builds from bootlooping until now. Hopefully you stick with it because I am getting better performance from this device than I have seen in a long while
Sent from my Galaxy Nexus using Xparent Gray Tapatalk 2
musical_chairs said:
Short answer: yes. I'm going to try grabbing the relevant code from MWisBest's githib. If it turns out to be too involved for my limited skills, it will have to wait until Ziyan submits the changes to CM.
Click to expand...
Click to collapse
Awesome!! Thank you!!
Sent from my LG-LS980 using XDA Free mobile app
I should've had a machete to hack through the jungle of build errors from pulling a modified OmniROM device tree into a CyanogenMod build. Looks like the build is rolling now though, with any luck it might just complete successfully - who knows, it might even boot.
The only thing slower around here than me is my poor old computer.
Its kind of ironic that the Galaxy Nexus was the first official LTE device for Sprint and I am only just recently starting to get LTE on a semi regular basis.
@musical_chairs, take your time with your builds. I assure you that they are appreciated. Now that this device is actually getting decent (for Sprint) signal and still has current builds makes it more enjoyable to use than just about any time I can remember....I just miss Imoseyon's Lean kernels. I got GREAT battery on those. They were compiled in the now deceased (I think) CMRemix ROMs but the LTE is definitely a plus
Update: For now, I have stopped working on building CyanogenMod with the DDK 1.9 drivers. I was ending up with a completely unsustainable mess of a device tree, and was still running into build errors. If new drivers are what you want, use FML. I'll focus on keeping the regular CM builds updated for the time being.
musical_chairs said:
Update: For now, I have stopped working on building CyanogenMod with the DDK 1.9 drivers. I was ending up with a completely unsustainable mess of a device tree, and was still running into build errors. If new drivers are what you want, use FML. I'll focus on keeping the regular CM builds updated for the time being.
Click to expand...
Click to collapse
Link to toroplus build for fml?
Zeinzu said:
Link to toroplus build for fml?
Click to expand...
Click to collapse
I'm following its developements, but haven't had time to try it personally yet.
http://forum.xda-developers.com/galaxy-nexus/sprint-develop/rom-fml-fork-life-10-13-2014-t2903695
Thanks for trying anyhow. I'm glad cm11 still has a fighting chance with the GNex, thanks to you, and all the others who are able to help out.
We're all waiting for cm12 to get to a buildable state. In the meantime, I've been working on upgrading my build box. My old machine was just barely capable of building android, the 'new' one isn't new but it was a real beast in its day. Time for a clean build has dropped from a day and a half to two and a half hours. I'm happy...
jd14771 said:
just curious, how difficult is it to compile roms? Do you need to know how to write your own code or is it over glorified copy and pasting with packages and stuff?
Click to expand...
Click to collapse
I do a lot of copying and pasting, a lot of reading guides, and a whole lot of google-ing. I don't know how to write my own code, but I have lots of experience with applying patches. Compiling roms is not that hard if you're a Linux user, have a working knowledge of the command line, and have a basic understanding of git. Take away any one of those things and it becomes a whole lot harder.
jd14771 said:
Yeah i haven't gotten to play with linux, nor do i know what git's are (i think they are large batch's of code posted in plain text?) . always wanted to try but don't have the time.
Click to expand...
Click to collapse
git is the software the devs use to keep track of changes in the code. Most Android devs have their git repositories on Github, those are probably what you are thinking of. Every little change (called a 'commit') has its own unique hash number. It's pretty amazing, you can look through somebody else's commits and find one that fixes a bug you are working on, or split tens of thousands of changes in half, then in half again, then in half again, etc., and pinpoint the exact commit that causes a bug on your system - though that's more useful in Linux kernel development than in Android.
I don't really have the time either, but it's such a fun hobby...
Using quickboot?
Coming from Vanir. Really like the facility quickboot gives. Anyone "enabled" it? I can't seem actually show the field to turn it on. Settings search finds it, but that's it... Noticed Dev options is hidden also. What's up?
Props for keeping CM11 updated. Really like I can actually use SMS in Hangouts.
I haven't been following the nightly changes since toroplus went dark, but I ran a build today--nothing special, just the latest cm...whatever changes they are. I could post it but don't know if I should make another thread or just link to it in here.
Anything substantial get added to general cm in the last few months?
I tried to run a build of cm12 but it looks like things still aren't ready for building yet, either that or I'm not sure how to switch back and forth between the cm11 repo and cm12 without getting repo update errors.
yotvb531 said:
I tried to run a build of cm12 but it looks like things still aren't ready for building yet, either that or I'm not sure how to switch back and forth between the cm11 repo and cm12 without getting repo update errors.
Click to expand...
Click to collapse
I got cm12 built and booting for toro for the first time today. I'm trying to get mobile data working on that, then I'll give toroplus a shot. Looks like it shouldn't be too much trouble. Feel free to post any of your builds here, or start your own thread if you prefer.
Here's my cm11 build from yesterday--equivalent to a plain nightly. It's been running fine since I dirty flashed it last night. Md5sum is linked as well and noted below.
https://www.dropbox.com/s/lp4j3yayuktmlot/cm-11-20141227-UNOFFICIAL-toroplus.zip?dl=1
https://www.dropbox.com/s/z1b72j7oh70eg5w/cm-11-20141227-UNOFFICIAL-toroplus.zip.md5sum?dl=1
MD5 Sum: e6c265c57e00b4949362d6ff53c9a799
Well I got cm12 built and booting on toroplus, unfortunately the RIL is completely borked, so no cell service at all at this point. I'll keep working on that, in the mean time check out the updated cm11 build in the post right above this one.