• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [ROM] CM7 Community Style

dsmryder

Android Expert
May 28, 2011
2,418
502
NE Florida
This is the start of what I hope is the continuation of CM7 for our Motorola Triumph.
I hope all of those who wanted to learn will chime in early and can help bring new life to this ROM.



Goals:
  1. Bring stability to the code by forking all of the work needed to build . Done​
  2. Customize to have a respectable base by witch to theme off of.​
  3. Find bugs to make the ROM even more stable.
I will be busy doing my start up side of things. I have never tried to work on my own project before. I have no plans to change my phone for the next two years. After that, I think the mid range phone with it's six cores and 802.11m and 32GB of ROM space running android 10.whatever. will be too much of a draw.​
 
Since this is a DEV area and this is listed as "community" I figured I would through in my two cents. I don't want anyone to think I am picking on any DEV. These are just my two cents which could be rusted and wrong.

My thoughts on Community Goals is there should be one goal and that should be building from CM7 unedited source code. While this may be very difficult to resolve I think it is possible. Let me me explain.

After banging on the GB 2.3.4 ROM for a few days and reading up on RIL there is no reason we should have special RIL edits to the code. After looking at code from https://github.com/inferiorhumanorgans which is a port of CM7 they are not using any special calls for RIL.java and their device is on Virgin Mobile. They also released multiple device files to support multiple vendors Verizon, Metro PCS and Sprint PCS. Which is the same thing with CM7 did, one code to support all the vendors.

So how do we get there? Firstly I created some base device and vendor files based off the HTC Incredible phone and the current device files I was using to build g60 CM7. With those device files I was able to in fact get the phone to boot from unedited CM7.2 rc1 code. The only thing that worked on the phone was video (which was very laggy) and also touch screen. While that is no where near a perfect device it is a starting point.

After spending more time with Mobstergunz GB 2.3.4 ROM I found out a few things. In the build.prop there is a call to ro.product.model=ADR6350 which is the HTC Incredible, and the same device files I used. The reason I picked those device files had nothing to do with this finding as I built the files before I even started work on this. However the reason for the HTC was based off processor and also video drivers which are the same in both our phones.

Next if you scroll down in the build.prop you will also find htc_vivow again another device supported by CM7. So I think it's very possible to take what I started and use a mix of what TickerGuy released to get a fully compatible release. If we can do this with CM7 I am sure we can move our files into CM9 as well with some more edits to make the code work from stock.

Finally I took our deodexed Stock Froyo ROM and copied out /system/framework/framerwork.jar and used dex2jar to convert it a readable format to be used with jd-gui, here is a great guide on it. Anyways once you decompile to this level you can actually read the Java source code not to be confused with smali code for our Froyo ROM. Anyways this may be the key we can use as a community to help solve HDMI. It's not going to be an easy task by any means but I think it's the best way to achieve full compatibility with our phone.

While TickerGuy and IssacJ helped us pave the road I believe there is more information available then when they first started. Hopefully we can use this information to move this project forward so we can have a fully functional phone.
 
Upvote 0
Since this is a DEV area and this is listed as "community" I figured I would through in my two cents. I don't want anyone to think I am picking on any DEV. These are just my two cents which could be rusted and wrong.

My thoughts on Community Goals is there should be one goal and that should be building from CM7 unedited source code. While this may be very difficult to resolve I think it is possible. Let me me explain.

After banging on the GB 2.3.4 ROM for a few days and reading up on RIL there is no reason we should have special RIL edits to the code. After looking at code from https://github.com/inferiorhumanorgans which is a port of CM7 they are not using any special calls for RIL.java and their device is on Virgin Mobile. They also released multiple device files to support multiple vendors Verizon, Metro PCS and Sprint PCS. Which is the same thing with CM7 did, one code to support all the vendors.

So how do we get there? Firstly I created some base device and vendor files based off the HTC Incredible phone and the current device files I was using to build g60 CM7. With those device files I was able to in fact get the phone to boot from unedited CM7.2 rc1 code. The only thing that worked on the phone was video (which was very laggy) and also touch screen. While that is no where near a perfect device it is a starting point.

After spending more time with Mobstergunz GB 2.3.4 ROM I found out a few things. In the build.prop there is a call to ro.product.model=ADR6350 which is the HTC Incredible, and the same device files I used. The reason I picked those device files had nothing to do with this finding as I built the files before I even started work on this. However the reason for the HTC was based off processor and also video drivers which are the same in both our phones.

Next if you scroll down in the build.prop you will also find htc_vivow again another device supported by CM7. So I think it's very possible to take what I started and use a mix of what TickerGuy released to get a fully compatible release. If we can do this with CM7 I am sure we can move our files into CM9 as well with some more edits to make the code work from stock.

Finally I took our deodexed Stock Froyo ROM and copied out /system/framework/framerwork.jar and used dex2jar to convert it a readable format to be used with jd-gui, here is a great guide on it. Anyways once you decompile to this level you can actually read the Java source code not to be confused with smali code for our Froyo ROM. Anyways this may be the key we can use as a community to help solve HDMI. It's not going to be an easy task by any means but I think it's the best way to achieve full compatibility with our phone.

While TickerGuy and IssacJ helped us pave the road I believe there is more information available then when they first started. Hopefully we can use this information to move this project forward so we can have a fully functional phone.
That actually is very great information.
But one thing, different phones need different code. For example, all VM phones need a special MMS fix to the CdmaSMSDispatcher.java, or that was until we got it officially supported in CM.
 
Upvote 0
That actually is very great information.
But one thing, different phones need different code. For example, all VM phones need a special MMS fix to the CdmaSMSDispatcher.java, or that was until we got it officially supported in CM.

You are correct sir, and if you look where Tickerguy pulled in the code he snagged it from inferiorhumanorgans the same phone I listed on using Virgin Mobile and the same phone that does not have RIL changes to the code. Also we would need to use our specific GPS Drivers as well however that is something we should be able to integrate into the device files like the Audio has been done. We may also be able to integrate the MMS as well in the device files, or at the very least submit it to Cyangenmod and see if they would accept the change to the main line of code. Short of that it would be trial and error but I think this is very possible.
 
Upvote 0
You are correct sir, and if you look where Tickerguy pulled in the code he snagged it from inferiorhumanorgans the same phone I listed on using Virgin Mobile and the same phone that does not have RIL changes to the code. Also we would need to use our specific GPS Drivers as well however that is something we should be able to integrate into the device files like the Audio has been done. We may also be able to integrate the MMS as well in the device files, or at the very least submit it to Cyangenmod and see if they would accept the change to the main line of code. Short of that it would be trial and error but I think this is very possible.

You thinking maybe in the overlay? That could help with my repo sync so that I don't have to worry about syncing problems
 
Upvote 0
Well the hard programming will have to come second. First I need to make sure I can build. Then after that I will make changes to the code as the community requests. One of my main goals for this project is to prevent CyanogenMod from breaking the code while I am working on other parts of the code.

dsmryder,

That is the point of my post. If we use unedited CM7 code you can simply just download the code and build

Code:
repo init -u git://github.com/[B]CyanogenMod[/B]/android.git -b gingerbread
repo sync
. build/envsetup.sh && brunch triumph
What I am proposing is to start from scratch on the device files and adapt them to code so we don't need to edit the cm7 source code. If we can get to that point where we simply build CM7 with clean source code we don't need to worry about what Cyanogenmod does. If something breaks we simply update our device files and get it working again instead of going through code.

Any supported phone by CM7 that gets nightly builds works this way. Changes are made to the base CM7 code, and scripts are kicked off and people then download the nightly updates. You think each night some one is hacking on the frameworks base because it broke their camera? Not at all, the device files work hand in hand with the code so there is no need for that. That is my proposal, rebuild device files and make them work with CM7 base code so we don't need to be making stupid edits all the time each time an update comes out.
 
Upvote 0
You thinking maybe in the overlay? That could help with my repo sync so that I don't have to worry about syncing problems

I am thinking the overlay but I am sure there is another way. If we spend time looking at other device files I am sure some one has had to do the same thing we are dealing with. I know this can be done it's a matter of getting it done and testing it.
 
Upvote 0
After banging on the GB 2.3.4 ROM for a few days and reading up on RIL there is no reason we should have special RIL edits to the code. After looking at code from https://github.com/inferiorhumanorgans which is a port of CM7 they are not using any special calls for RIL.java and their device is on Virgin Mobile. They also released multiple device files to support multiple vendors Verizon, Metro PCS and Sprint PCS. Which is the same thing with CM7 did, one code to support all the vendors.

While I do think we could cut down on the number of edits, I don't think we could eliminate them completely. The reason we have edits to the RIL file (for fixing data) is because our phone is just plain weird. It makes unstandard calls and it has additional unsolicited upcalls. These are unique to the triumph (not VM) and would not be a problem with other VM phones.

Also wrt MMS (which was a problem unique to VM not our phone), wasn't the VM fix accepted upstream by CM? For some reason thats what I am remembering...

I am not sure what you mean by device files, but if you mean building files which we would then use as prebuilt files (and not use what is built by the source code). The problem with that is that some of the fixes (like gps) are built into libraries that may be used for other things and which CM might update. If we continue to use the those libraries, than that is as good as just not syncing upstream anymore (for those portions).

Finally I took our deodexed Stock Froyo ROM and copied out /system/framework/framerwork.jar and used dex2jar to convert it a readable format to be used with jd-gui, here is a great guide on it. Anyways once you decompile to this level you can actually read the Java source code not to be confused with smali code for our Froyo ROM. Anyways this may be the key we can use as a community to help solve HDMI. It's not going to be an easy task by any means but I think it's the best way to achieve full compatibility with our phone.

jd-gui is great but it doesn't produce code that can be recompiled (hence why we have to go down to smali). I used it a lot in trying to fix hdmi. I rewrote the hdmi service and listener based on the decompiled code it produced from andro-id's framework.jar (see https://github.com/wsimon/android_frameworks_base/commit/ce91b5e3cd7452b09393425cf7a79b9ffdb5d32c)
To add hdmi support, you need more changes than just in the framework. I am confident in the changes I made in the framework, but its the .so libraries (such as liboverlay.so, libsurfaceflinger etc.) outside of the framework that I believe contain the remaining problems.

I recently PMed tj_style about it and he said he's really busy right now with his real job, but will try to see if he can look at my changes to see what's missing.


You thinking maybe in the overlay? That could help with my repo sync so that I don't have to worry about syncing problems

I'm fairly certain that the overlay can't be used for source code (if that's what you mean)- I think that is more for resources.


I personally still think that we can get data working on that gingerbread rom. I was getting very involved and into the smali code- the differences between CM7 and the plain ol' gingerbread are significant (especially in RIL.smali) and so copy-pasting functions or smali files won't work. They have different function names and everything but when it comes down to it, they do pretty much the same thing (just with different organization/code). I am going to continue working on that, the next chance I get.

I haven't looked at the ICS camera at all but mantera gave us a good starting point (http://androidforums.com/triumph-all-things-root/488824-dev-continuing-triumph-ics-development-26.html#post4522169) and I would like to think that with tj_styles changes, we should be able to figure it out.... someday....


Long live the triumph and my 25$/month cell phone bills!! :D
 
  • Like
Reactions: dsmryder
Upvote 0
Has anyone noticed the occasional bug were you can not unlock the screen and you have to pull the battery to reboot? Or is that just me?
It would be a tuff one to catch as i can't seem to reproduce it in any particular way. It it happens at least once or twice a week.
Running r.09 g60

I had that on stock. Ever sense I loaded TG's .8, I haven't had that as a problem. It may be a rogue app or a bad download/flash. It could be a setting, but I doubt that because you don't have it consistently.

I would try reflashing without any app I didn't need and reload them over a week or more, depending on how many I had.
 
Upvote 0
Silly question, but is there some kinda "github for dummies" guide? I really want to learn to dev but all the codes are so confusing...:thinking:
The short answer is "no". I have been learning along the way myself. What I have learned is mostly that I need to concentrate on one side of git, not modifying both.

Where are you stuck? I may be able to help. I have found aguide. I had a better one, but it was taken down. I may look to see if it was put back up later.
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones