Related
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Ditto. I am all for AOSP 2.0
richbayliss said:
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd
Click to expand...
Click to collapse
I think part of the "issue" is that whilst Google have release some 2.0 code to AOSP, it is not currently complete (see here). In addition, many of the Google apps (e.g. Gmail) are closed source, so you have to rely on prebuilt components which may, or may not, be compatible.
The long and short of it is that Lox is already doing what you are asking. The prerelease of HTC's 2.1 has possibly served as a distraction to the AOSP 2.0 build, but I'm sure once Google properly drops AOSP 2.1 code that work will be of direct relevance to the AOSP project.
Regards,
Dave
yeah exactly. just sit tight and wait for Lox_dev to finish his 2.1 Then he might look after the AOSP 2.0. and as AOSP 2.0 is running pretty fine without much hassle its fine if Lox takes some time before working on AOSP 2.0 . cheers
I'm with this idea!
I mean, just compare the 2.1 and 2.0 aosp videos; android 2.0 has much cleaner, and better transitions imo.
Design choices in 2.1 by HTC are, imo, bad as usual; the transparent notification drawer for example; what is the purpose? It's only jerky. And so on..
I suggest suspending judgement on HTC's 2.1 until they've actually released final code! Remember this is a leaked internal build - what ends up in the final ROM may be quite different.
Regards,
Dave
I think I have a clearer picture now, thanks guys.
I just wish that we could be in a scenario where we could flash a standard AOSP build onto our Hero's, sans the whole SenseUI, and have a basic usable phone.
I really dont get the whole "gmail is closed source" crap with Google. I mean, I can have Gmail on WinMo, S60, etc - but only on Android IF I have a license?? WTF! Crazy! Luckily, now that Gmail does support Exchange Activesync I don't need the standalone app anyway.
So the word on the street is wait.... which I guess is what we will have to do
I am keen to be able to build from source so I can start on a project I have in mind. Think along the lines of SenseUI, but a bit different.....
richbayliss said:
We have had alot of activity over the last few days, what with the first 2.0 releases from the main players and now even some 2.1 builds. Which is excellent.
Maybe I am not 100% up to speed on the whole thing, but if AOSP 2.0 is "released" by google, then surely things like sync issues, etc shouldn't be in the source code?? I mean, the code should be as "bug free" as possible, so anything obvious like that would strike me as odd.
The reason I raise this point, is because I dislike the Rosie/SenseUI on my Hero, I would rather have the good, old Android standard like I had on my G1 - just what I prefer. However there are only beta versions of the AOSP eclair for Hero.
Would it be possible to build an AOSP eclair firmware, using the Qualcomm? proprietory drivers from someones leaked 2.1 image (working on an assumption that 2.1 has the same kernel base?) to produce a fully working Eclair 2.0 for Hero?
If I am way off the mark with this, please say, I'm just trying to think it through with the help of the people in the know.
Click to expand...
Click to collapse
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
jnwhiteh said:
Forgive me if I'm missing the point, but we already have a fully working AOSP Eclair image for the HTC Hero. I've been using it for over a week, on a daily basis and other than the looping sync issue (which we are working on) it works fantastic..
Click to expand...
Click to collapse
I wasn't aware that all issues apart from the syncing were fixed. I thought we still had issues with camera stability etc?? Is this not the case??
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
Believe me, I'll come back to AOSP soon with great things
That's an awesome news ! Thank you Lox !
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Thanks Lox, appreciated.
Lox_Dev said:
Believe me, I'll come back to AOSP soon with great things
Click to expand...
Click to collapse
Great news man! Thanks a lot! Holding my breath...
jnwhiteh said:
There are some minor issues with stability, but it's absolutely useable on a daily basis. I guess it would be better for you to list what your problems are or concerns, rather than making (what appears to me) to be a grand claim for concentrated work on something.
There are a number of us who are solely focused on getting AOSP Eclair working 100%.. but we're very nearly there. Having people contribute constructive information about what doesn't work would be the best.
Click to expand...
Click to collapse
I agree. The only reason I am now using Lox_devs Hero 2.1 1.4 instead of the pure Eclair one is that Eclair does not sync my exchange calendar. I just cant see why the calendar has been left out.
FroydVillain 1.3/2.x roadmap
EDIT: Due to unforeseen issues rapidly accelerating the release of 1.3 (more framework changes), I'll edit this roadmap to reflect 1.4 as well as what we hope to accomplish depending on how many of the 1.3 promised features make it into the accelerated release. Thanks for your patience.
Now that FroydVillain 1.2.x is somewhat stable we can concentrate on the next releases.
First, any and all "WHENNNNNNNNNNN???????!!!!!111oneeleven" posts will be ignored. As usual, "when" = "when it's done".
Features/items in this roadmap are things you can definitely look forward to unless otherwise stated, ie, something happens that renders that feature impossible. Like an asteroid hitting my house, for example.
First, the preliminary work.
I promised the guys over at Cyanogenmod that my new build profile for the Hero (and other MSM7xxA based phones, so the Dream, Slide, G1, etc etc) will be tidied up and offered up in a pull request. I will be cleaning up my tree and submitting my changes before I begin work on the next release of FroydVillain. The main reason for this being, the closer the CM tree is to my tree, the less work involved in keeping the FroydVillain tree up to date with upstream fixes.
Right, so the changes.
Version 1.3.x:
Obviously it is customary to break some **** with each major revision just to give me an excuse to release another release after that broken release.
So for 1.3.0 I nominate, umm...nah I'll let you find out. A release post isn't complete without at least 20 posts asking if anyone is having xxxxx problem and a further 20 posts complaining about the said problem after I post that we're aware and we're very sorry and those responsible shall be flogged.
FroydVillain 1.3.x:
Further changes to the build base and source code to move Froyo-on-Hero further away from reliance upon Eclair libraries. We aim to be building a native libcamera.so in the same vein as the D/S guys are. This combined with already eliminating proprietary liblights makes it easier to...
Switch over to the Froyo prelink map. If you don't know what prelinking is, don't ask. Either don't worry about it or do some Googling. The upshot for you the end user should be better stability and maybe even some added performance improvements.
Along with the addition of the CPU profile to the CM base I'm hoping to get VFP support fixed in the kernel and in the dalvik source. VFP is your phone's ability to offload number crunching to a dedicated number crunch piece of hardware. The cpu the Hero has supports it, however support for VFP on ArmV6 architecture is a bit...well, pants. Accomplishing this should also give another measurable boost in dalvik performance since currently the only enhancement to dalvik, is the optimised binary, the source itself still trudges along with only armv5te support which again rather pants.
Giant /data partition. Thanks Maxisma and co. I'm not going to bring this in until we next need to do a wipe, ie, 1.3 since it resizes the mtd partitions. Coupled with old school apps2sd there should never be a single whine about space on /data ever again. Even dkelley could fit all of his dalvik cache data on it with his encyclopaedic collection of apps. Be aware this will be accompanied by an updated recovery.img so the different layout is supported. You have been warned.
Debugged Exchange support. I can't promise that this will appear in a 1.2.x update but I will get it in for 1.3. I don't use Exchange and so have to rely on others to help find the cause of the issue, debug it and test it. I can't believe after nearly 10 years dodging it, I'm back troubleshooting Exchange bollocks again.
Theme revival. Because Google were kind enough to provide no theming engine what so f**king ever (cheers lads) theming is a pain in the behind that involves hacking the framework. However because we now build from source rather than trying to crowbar bits in and out of a prebuilt HTC tree, it's significantly easier to produce themes from the newly built source tree. I'm working with Alex24 on a project to go with 1.3.x which will put Themes back into the OTA app and they'll be available at the same time as the new releases are. This also allows us to easily add more themes over time.
CMSettings/CMParts. After having a chat with the folks at Cyanogenmod they're more than happy for me to make the menu entry in settings feel more at home within FroydVillain instead of looking like a kicking and screaming rip off from the Cyanogenmod ROM itself. So those of you that have been hopping up and down for CMSettings functionality, it's coming.
Better GPS functionality/better radio functionality overall. For various reasons, changes made by Google, the fact we'll never have official "Froyo supporting" radios, bugs creep into the OS when it comes to using newer Google based apps that make use of the radio. We'll have some fixes for the slow GPS locking and the random reboot/crash when looking for a GPS signal. We're hoping we have mobile data+gps properly nailed down as well.
We're also going to look into different Gallery implementations. Gallery 3D is annoying as hell and the bugs with it are likely due to us relying on the Eclair GL libs. So no further ground is likely to be made until/if/when another MSM7xxA class phone gets Froyo which if any will likely be the Legend. That's a big if though. Imagine if you will, 50 metre tall letters I and F, draped in neon coating with a flashing, strobing sign above them announcing "THIS IS A BIG IF." But no whining if the best you get is the old 2D Gallery as I'm really struggling to find any decent Gallery implementation. Which is somewhat surprising. Perhaps we should offer a bounty for a new decent one.
Add further language support
That's all for 1.3.x for now I think. I'll update this as new things occur or as things appear to be impossible.
FroydVillain 2.x:
Kernel 2.6.34.
What? That's not enough? Wtf is wrong with you? Ok fine.
2.6.34 will provide official support for the newer Froyd features such as in built Tethering and no more annoying bull**** surrounding connecting a simple USB phone to a simple USB port on a simple Windows system. Apparently the Windows driver stack is easier to confuse than a 90 year old Alzheimers suffering dementia patient.
We'll also be looking to bring the Hero Froyo platform closer in line to the more complete Cyanogenmod D/S platform. There's really no reason why we shouldn't be able to especially once 2.6.34 is available since as far as the hardware is concerned the phones are practically identical.
More will be added to the 2.x branch as we discover it. Don't be surprised if in the course of working on 1.3.x some features get pushed back to the 2.x release due to practical limitations or it just making more sense.
Now is the time for feature requests from you the user. 1.2.x is now critical bugs only, I do not want to have to make you wipe/flash 1.2.x now until 1.3 hits so any fixes involving a framework rebuild won't appear until 2.x. 1.2.x is now considered feature complete in the scope of features we want to have supported. New features will appear in 1.3.x or 2.x depending on the work required to make them appear.
So the forum is now yours, dear users, to get those feature requests in. We'll endeavour to get as many implemented as we can. Any ridiculous or unobtainable goals will be identified as such as quickly as possible so people don't get their hopes up only for me to dash them like an abusive husband.
Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.
Looking great! Hope you'll get that all working!
acolwill said:
Thanks for all of the Froyo deliciousness you've provided us with! I myself will be waiting with baited breath for the next installments of Froyd.
p.s.
If you need more people with access to Exchange, or if you'd like an Exchange environment to play around with, let me know. I've got an Exchange 2010 machine sitting next to me.
Click to expand...
Click to collapse
Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
maxisma said:
Looking great! Hope you'll get that all working!
Click to expand...
Click to collapse
Cheers bud! Check your PMs.
wow keep on the great work...
Flash? 10char
dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Impossible, it doesn't work on ARMv6 CPUs.
Ah, now that -would- be useful. [email protected] if you want to hit me up on GTalk.
Click to expand...
Click to collapse
Req sent. Gimme a nudge
dpi295 said:
Flash? 10char
Click to expand...
Click to collapse
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.
Hacre said:
Best we can do is see if we can hack over the Flash Lite stuff from Sense, but don't hold your breath.
In fact, you all should start a campaign and hammer the **** out of Adobe to provide an armv5te or armv6j version of the flash library. It's their fault, make them fix it.
Click to expand...
Click to collapse
They won't do that, they aren't powerful enough..
I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.
Amazing work! Data Partition, Themes, VillainSettings... cant wait!
As for Feature Requests, +1 for a quick 2D Gallery
Nice post ninpo.
Thanks for your great ROM. I'd love to see better rtl language support in your ROM.
Really lame request, and probably easily fixed just by finding the pictures myself, but could you put all the nice wallpapers you had back into the releases?
It's obviously a very trivial request, but the wallpapers were always exceptional compared to my attempts of being sophisticated. I always ended up with either breasts or something Xbox related...
mobydeek said:
As for Feature Requests, +1 for a quick 2D Gallery
Click to expand...
Click to collapse
+1 for the standard 2D Gallery.
Tanks guys for your hard work.
Sent from my HTC Hero using Tapatalk
Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.
Screatch said:
I'd appreciate it if you would make an optional patch for people who want their phone unlocked by double clicking menu button.
Click to expand...
Click to collapse
Blue-K said:
Woah, that's a lot of things to do, and some big ones too. Good luck on that, would be awesome to see these things done in the next months, though, take your time, no rush .
As for Feature-Requests: I only have one, and I don't have any idea if it's already done (I don't test many ROMs that often, I'll prefer to stay on my 2.1 Vanilla ROM ) or if it's even possible, so sorry for my Noobishness in advance. Now, I would love to be able to control the Music Player with the volume keys. Short presses change the volume, like before, and long presses skip the songs.
Click to expand...
Click to collapse
We'll be putting a modified CMSettings back into FroydVillain in 1.3, so these features will be there automaticallymagically.
Yeah, it's a fair bit of work, but with HTC pretty much ditching the Hero we can take the project and make sure it's all done and done right.
There's collaboration with other developers on other projects for a lot of this, it's not just me or Team Villain making it all happen. I'll be pushing the fixed cpuprofile up to cyanogenmod and they can then work on it too, I'm working with Elemag on the 2.6.34 port, Maxisma brought the repartitioning stuff to everyone's attention for the Hero, etc. Proper open source development at its best.
It's well worth it too. Look how different the Hero runs with FroydVillain 1.2.1, I'm quite frankly disgusted that HTC never, ever, tapped all that potential.
I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!
e2zippo said:
I can't believe it, my hero will never die!
This is indeed great news and I can't wait!
I just wanna thank everyone involved, all the developers are doing a fantastic job bringing us things i never thought was possible on the hero, and I totally agree Hacre, it's a real shame that HTC ditched ther hero when there's still juice left in it!
Cheers!
Click to expand...
Click to collapse
Not to mention juice they never, ever bloody gave us. Grr.
Dear Reefermattness and arrrghhh !
I apologize for making a new thread but I just want have your attention on the Neopeek Release for Rhodium.
In this forum stays that in FRG83.R5 release
http://www.neopeek.com/en/forum/Android-ROMs/2183-ROM-FRG83-Build-Froyo221-05-11-2010
Bluetooth IS WORKING !
I have no idea what this release can, but I saw its structure. Basically EXT2 Partition for Neopeek is the same thing that system.ext2 file for FRX03 !
And in andoidinstall.tar.gz file is the same stuff as in system.ext2 and roofts.img together.
Why we just not pick the working Bluetooth "driver-package-what-ever" from Neopeek and combine it with FRX03 ? I could do it by my self, but I don't have deep system structure know-how.
I must say that FRX03 is lot easier to handle (getting ready, install, edit etc) thats why I'd prefer working with it as with Neopeek.
And besides I just reached almost 8 hrs of working time with one charge on it with new kernel and startup change. Thats why I want to improve it. Can you help me to understand the structure of driver packages for BT ?
Thank you
-------------------------------------
----------------
EDIT:
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
d0nate110 said:
Dear Reefermattness and arrrghhh !
I apologize for making a new thread but I just want have your attention on the Neopeek Release for Rhodium.
In this forum stays that in FRG83.R5 release
http://www.neopeek.com/en/forum/Android-ROMs/2183-ROM-FRG83-Build-Froyo221-05-11-2010
Bluetooth IS WORKING !
I have no idea what this release can, but I saw its structure. Basically EXT2 Partition for Neopeek is the same thing that system.ext2 file for FRX03 !
And in andoidinstall.tar.gz file is the same stuff as in system.ext2 and roofts.img together.
Why we just not pick the working Bluetooth "driver-package-what-ever" from Neopeek and combine it with FRX03 ? I could do it by my self, but I don't have deep system structure know-how.
I must say that FRX03 is lot easier to handle (getting ready, install, edit etc) thats why I'd prefer working with it as with Neopeek.
And besides I just reached almost 8 hrs of working time with one charge on it with new kernel and startup change. Thats why I want to improve it. Can you help me to understand the structure of driver packages for BT ?
Thank you
Click to expand...
Click to collapse
1) as far as I understand Neopeek uses large parts of Xdandroid projects, starting from the kernels/rootfs. This is not hidden/secret, so he and xda devs may know each other pretty well.
Therefore I can't understand how he can have bluetooth working and Xdandroid not.
then ...
2) maybe he shares branches of code and patches with our devs, but while our devs decided that the code to make bluetooth working is still too buggy, he could have decided to shoot it in for good. In fact reading comments on the thread you posted you will see that at the end the people crying for not-working BT are a lot ...
I'd be interested to see if BT works fully. I've seen some where they scream that BT works, but then when they actually try to use BT... it fails. So if it pairs and nothing else, that's what state our build is in as well.
I just installed it, on a blank 2Gb I had spare.
At start it's quite a pain in the arse ...
cmdline was a little different, I just set correct keyboard.
But I immediately put the latest kernel (24.11.2010). Both in installer and main.
Much faster than Xdandroid. Much faster at boot, much snappier in launcher etc., but this may be related also to the age (of the FAT32 file system) of the other SD I use for Xdandroid. Will format it and see what happens swapping.
But then, when it went to sleep it just crashed.
I tampered with the startup, added pmsleepmode=2, this worked, tried =1 and works quite well.
As I expected, BT doesn't work on my RHOD100.
This neopeek build comes nearly all from xdandroid, so it seems it's not as up to date.
But while that guy takes most of development from XDA, he must work a lot on tweaks, therefore XDA should take something back ...
I'll try cleaning the other SD and check what happens.
Installed on extra card. Rhodium 400 . It is fast. Boots quicker. The initial setup screens are very friendly. Power off and other buttons work more like winmo. Bluetooth will not turn on. Phone works. Data does not work. Have to use WiFi for data. USB while in Android does work (sweet). Key board backlighting not working. I am going to reinstall with bluetooth enabled initially in winmo.
Neopeek SuperFroyo Repack into system.ext2
arrrghhh said:
I'd be interested to see if BT works fully. I've seen some where they scream that BT works, but then when they actually try to use BT... it fails. So if it pairs and nothing else, that's what state our build is in as well.
Click to expand...
Click to collapse
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
reinstalled Bluetooth not working. Rhodium 400
Only things that could make improvements to XDA android are Speaker phone is working. USB in android does work. Buttons function as they should. It works with SIM card installed. Speed. Boots faster. Screen adjusts to right profile on start lockscreen.USB headset works without line in startup.
Still not working
Data does work but have to manually set APN. Headset does not work ( Does work with line in Startup and calling during boot). Problems with the market downloading.
Does work tethering. pretty much everything
One nice thing is they have a seperate install folder so if your system is corrupted you just reinstall with file manager in winmo. It reformats the ext2 partition on the card. I assume the sizing of partition is in place of the sizing the data.img file on the card.
Being open source borrowing a few items should not be considered crossing a line.
d0nate110 said:
Here it is, a repack of SuperFroyo in system.ext2 file.
http://narod.ru/disk/27385762000/system.zip.html
I didn't test it yet. But if some one want to try out - please download and report back !
Click to expand...
Click to collapse
wait a minute.. you didnt test it and are spreading it like wild fire ?
before you cry wolf, at least pretend you saw one ..
First Full Day Of Testing
[ACL] said:
wait a minute.. you didnt test it and are spreading it like wild fire ?
before you cry wolf, at least pretend you saw one ..
Click to expand...
Click to collapse
I've tested this strange build a whole day today... I must say...I'm confused...
First of all I charged my battery to full 100% in WinMo. Then I've just replaced old system.ext2 with this one (my other files incl. kernel were untouched) and booted a clean Haret and saw, that this Android Learning Demo just didn't want to go on if I taped on it...
My device was locked and I must reboot it...then I delete my data.img file and tried again... success - SuperFroyo booted well.
- Bluetooth doesn't work as pessimistically expected
Other stuff works same like in our Froyo Reference.
- flash 10.1, loudspeaker, camera, usb connection and headphones don't work
- sleep_mode=1, wifi, phone, wake up on call and Market are working.
But Battery life was little better according to JuicePlotter... and I had a feeling, that all the system works little bit faster... I don't know if it is just placebo effect, but I thing its true...
I'll keep testing it for another 3-5 days and report back... and BTW you can test it too.
d0nate110 said:
I've tested this strange build a whole day today... I must say...I'm confused...
First of all I charged my battery to full 100% in WinMo. Then I've just replaced old system.ext2 with this one (my other files incl. kernel were untouched) and booted a clean Haret and saw, that this Android Learning Demo just didn't want to go on if I taped on it...
My device was locked and I must reboot it...then I delete my data.img file and tried again... success - SuperFroyo booted well.
- Bluetooth doesn't work as pessimistically expected
Other stuff works same like in our Froyo Reference.
- flash 10.1, loudspeaker, camera, usb connection and headphones don't work
- sleep_mode=1, wifi, phone, wake up on call and Market are working.
But Battery life was little better according to JuicePlotter... and I had a feeling, that all the system works little bit faster... I don't know if it is just placebo effect, but I thing its true...
I'll keep testing it for another 3-5 days and report back... and BTW you can test it too.
Click to expand...
Click to collapse
I'm on nand, so i cant run that abomination. However i did run the real cyanogen and it was a lil faster. But it took too many changes to the rootfs to get it to run.. i havent tried it since..
Also im not sure why neopeek isnt using our rootfs structure so you can swap the system.imgs easier .. maybe you should ask him
too buggy things would work then stop working. I could plug in a usb headset have it work in a call or music unplug it then plug it back in and it does not work. Many other things like that. Same with the 3.5 jack trick it would work sometimes then sometimes not. If u left it stock it works great and is very fast. Diamond users were happy. I have a diamond that I will try it on sometime next week, but it is not good for rhodium. It did something to the usb on my Rhodium in winmo would not work so gave me a chance to jack in energy rom like that so far.
[ACL] said:
I'm on nand, so i cant run that abomination. However i did run the real cyanogen and it was a lil faster. But it took too many changes to the rootfs to get it to run.. i havent tried it since..
Also im not sure why neopeek isnt using our rootfs structure so you can swap the system.imgs easier .. maybe you should ask him
Click to expand...
Click to collapse
Sorry for silly question, but what do you mean with "being on nand"?
And, lol, why abomination!?!?!?
It's clearly taken from FRX02 Xdandroid build, but tweaked to be more speedy.
These tweaks are something that Xdandroid should port back to main project.
I have only one crash a day with Neopeek's FRG83.R5, while Xdandroid FRX03 is not only slower on my TP2 rhod100, even with around 100Mb ram free, but keeps slowing down even more while using, so that I have to restart.
In the last week this led to process ".acore" crashing almost immediately after boot, with no solution known to me except reinstalling.
That's once a day.
Neopeek did this only once.
Still have to understand what leads to ".acore" process chain crashes.
I would prefer to use Xdandroid FRX03, because it's more up to date and standard compliant, but, strangely, it's not as stable as Neopeek's FRG83, on my phone.
Cheers.
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Sorry about that
sad0felix said:
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Click to expand...
Click to collapse
First of all I AM NOT Donate - I'm donatello written with numbers
I don't want any donations and hate money
Second I apologize, but I can't implement FRG83.R5 to use without formating my SD-card thats why I use a SuperFroyo. The member DmK75 gave me this link to system.ext2 file with SuperFroyo release in it...
I try though to repack FRG83.R5 also in system.ext2 file later... I just don't have the know-how yet...
sad0felix said:
Sorry for silly question, but what do you mean with "being on nand"?
And, lol, why abomination!?!?!?
It's clearly taken from FRX02 Xdandroid build, but tweaked to be more speedy.
These tweaks are something that Xdandroid should port back to main project.
I have only one crash a day with Neopeek's FRG83.R5, while Xdandroid FRX03 is not only slower on my TP2 rhod100, even with around 100Mb ram free, but keeps slowing down even more while using, so that I have to restart.
In the last week this led to process ".acore" crashing almost immediately after boot, with no solution known to me except reinstalling.
That's once a day.
Neopeek did this only once.
Still have to understand what leads to ".acore" process chain crashes.
I would prefer to use Xdandroid FRX03, because it's more up to date and standard compliant, but, strangely, it's not as stable as Neopeek's FRG83, on my phone.
Cheers.
EDIT:
uh, oh, d0nate, I think we are messing it a little bit here. I am testing FRG83.R5, not SuperFroyo.
They are 2 different builds.
What are you effectively testing?
Click to expand...
Click to collapse
Ahh you poor soul.. nand meaning i no longer have wince so i cant run his installer. Abomination is a strong word.. so i take it back . But i do think it's wicked and it's not a child of xdandroid like you think. The main chunk of the project comes from cyanogen. The only parts that were pillaged from xdandroid appear to be some of the roofs files (including the hardware libs). And of course, our kernel runs the whole show.
Now why would i run some hacked up version if i can run cyanogen directly? Plus cyanogen has everything open, so we can easy work and modify it as we need. I have not seen anything shared by neopeek, so i dont feel its fair to the xdandroid team since we pretty much share everything.
If it's stable for you.. awesome.. maybe there is future for it.
[ACL] said:
Ahh you poor soul.. nand meaning i no longer have wince so i cant run his installer. Abomination is a strong word.. so i take it back . But i do think it's wicked and it's not a child of xdandroid like you think. The main chunk of the project comes from cyanogen. The only parts that were pillaged from xdandroid appear to be some of the roofs files (including the hardware libs). And of course, our kernel runs the whole show.
Now why would i run some hacked up version if i can run cyanogen directly? Plus cyanogen has everything open, so we can easy work and modify it as we need. I have not seen anything shared by neopeek, so i dont feel its fair to the xdandroid team since we pretty much share everything.
If it's stable for you.. awesome.. maybe there is future for it.
Click to expand...
Click to collapse
Woah ... I am feeling soooo noob ... dang you!!!
Since I wrote my previous post my knowledge grew about ten times ... from 0.001% to 0.01%, so now I can see what you mean about Cyanogen and all the rest.
I know it's everything but a good excuse, but please notice that I got to Android just in the form of Xdandroid, and only in the last few weeks.
So I am learning. Maybe faster than mean people, still much slower than hardcores like you or the other devs.
----------------
In the meanwhile I reverted back to FRX03.
Mainly because of stabilities (better, instabilities are regular so that can be forecasted and behaviors provoking them can be avoided with good success rate).
Still I think that maybe (and I cap it, MAYBE) Xdandroid could (I don't say should, it would be excessive) benefit from the Neopeek/Cyanogen "thing".
You know, like when you have a crate of stuff, you dive hands in it and choose and pick up just the good things/those you like.
I just dream a Xdandroid snappy like Neopeek's whatever build (I tried 2).
... the speed ... the speed .... (put here Marlon Brando's voice in Platoon, when he repeats "the horror" ... ).
Cheers!
EDIT:
I fear that you did it all by yourself, but in any case I ask you.
Is there any public documentation about going nand? What are the advantages?
You put a thermite in my left ear, you know?!?!?!
Here's the PPCG thread on NAND boot testing. Not for the faint of heart...
sad0felix said:
Woah ... I am feeling soooo noob ... dang you!!!
Since I wrote my previous post my knowledge grew about ten times ... from 0.001% to 0.01%, so now I can see what you mean about Cyanogen and all the rest.
I know it's everything but a good excuse, but please notice that I got to Android just in the form of Xdandroid, and only in the last few weeks.
So I am learning. Maybe faster than mean people, still much slower than hardcores like you or the other devs.
----------------
In the meanwhile I reverted back to FRX03.
Mainly because of stabilities (better, instabilities are regular so that can be forecasted and behaviors provoking them can be avoided with good success rate).
Still I think that maybe (and I cap it, MAYBE) Xdandroid could (I don't say should, it would be excessive) benefit from the Neopeek/Cyanogen "thing".
You know, like when you have a crate of stuff, you dive hands in it and choose and pick up just the good things/those you like.
I just dream a Xdandroid snappy like Neopeek's whatever build (I tried 2).
... the speed ... the speed .... (put here Marlon Brando's voice in Platoon, when he repeats "the horror" ... ).
Cheers!
EDIT:
I fear that you did it all by yourself, but in any case I ask you.
Is there any public documentation about going nand? What are the advantages?
You put a thermite in my left ear, you know?!?!?!
Click to expand...
Click to collapse
nand is for the brave.. so if you are just starting. then stay away since we already had a brick happen. I also corrupted something myself so it can get nasty. Once we stabilize it will get better. The main advantage is that you no longer have windows. lol.. but the disadvantage is that you dont have windows to fall back on. It also lets us develop as if the phone would be native to android. Believe it or not but wince does alot of the dirty work for us. So the nand project lets us recreate all that ourselves.
Cyanogen is just a different animal. Xdandroid is based of pure google code as it was meant to be. It also lets us modify it for our devices that were never meant to have android. Cyanogen only supports devices that already came with android. You can modify it to run on other devices, but the main builds themselves are for specific devices. Xdandroid supports all with just 1 build. We forget sometimes about our other winmo htc brethren like topaz and blacstone. But they need a build too.. .
If you are really interested in this, you can clone both codes and compare just how different we are. If you find something you think will benefit, try it out and see what happens. Gotta love opensource.
[ACL] said:
nand is for the brave.. so if you are just starting. then stay away since we already had a brick happen. I also corrupted something myself so it can get nasty. Once we stabilize it will get better. The main advantage is that you no longer have windows. lol.. but the disadvantage is that you dont have windows to fall back on. It also lets us develop as if the phone would be native to android. Believe it or not but wince does alot of the dirty work for us. So the nand project lets us recreate all that ourselves.
Click to expand...
Click to collapse
Hep, I am just a curious guy.
One of those many that want to put their nose everywhere, but also one of the few that:
a) most of the times will need to read the guide just once (if guide isn't enough there are FAQs and Google),
b) will follow instructions easily because normally understands what they mean/what they are for
c) will never give it up until success
d) will never come to the forum writing: "I have a phonez, tried to put some android on it, doesn't work HELP1!!1!!1!"
Moreover, my TP2 is just 6 months old, is a gift, I use it for work, so to not void the warranty I didn't even install HardSPL on it.
So do not worry.
I am just curious to read how you can do it.
But will not die if I don't know yet
Cyanogen is just a different animal. Xdandroid is based of pure google code as it was meant to be. It also lets us modify it for our devices that were never meant to have android. Cyanogen only supports devices that already came with android. You can modify it to run on other devices, but the main builds themselves are for specific devices. Xdandroid supports all with just 1 build. We forget sometimes about our other winmo htc brethren like topaz and blacstone. But they need a build too.. .
If you are really interested in this, you can clone both codes and compare just how different we are. If you find something you think will benefit, try it out and see what happens. Gotta love opensource.
Click to expand...
Click to collapse
Basically you are suggesting me that all the (amazing) speed of Neopeek's builds comes just from using direct EXT/SWAP partitions on SD.
So, is there anyone trying to build a Xdandroid with EXT/SWAP structure?
sad0felix said:
Basically you are suggesting me that all the (amazing) speed of Neopeek's builds comes just from using direct EXT/SWAP partitions on SD.
So, is there anyone trying to build a Xdandroid with EXT/SWAP structure?
Click to expand...
Click to collapse
Not to my knowledge. I guess we should *try* it just to see if there's a big difference... perhaps Neopeek can help us here muhahahahaha!
But I think the theory was the tradeoff would be small - a lot more work for very little reward. However, I would be interested to see if there is a difference, and if it is big or not. At the very least just to know if it's our build or just the ext2 partition that's making it feel snappier.
In addition, AFAIK swap partitions on SD cards should be avoided, unless they have a write-levelling scheme (I believe they only put these in SSD's... I don't think any SD card has this tech because it's typically unnecessary) - I've heard swap partitions can just destroy a normal SD card because of writing and re-writing to the same area of the card many, many times... I mean physically on the card, not just logically in the folder hierarchy.
Just installed it on my diamond Bluetooth does work but it doesnt pair. The screen eventually graduates to the center dividing it in opposite. I thought maybe because I was running the hot version. Repartitioned reinstalled the normal clock version runs for a time then the same. Its no better than XDA
Hello everyone...I'm planning on trying to develop a gingerbread kernel for AOSP because we don't really have support anymore and everyone has moved onto developing for ICS (not that this is a bad thing). I figure in my spare time I might as well try to learn and develop for our phone. Let me start by saying I was never really into phones/smartphones/rooting, or software development, but I've always been fascinated by Linux in general. I've played around using a number of Linux distros, but I've never really done anything intensive with them (modified their kernels, etc.) but I am vaguely familiar with terminal usage.
Anyways that was just my introduction. I've been running an ICS kernel on my AOSP GB system (specs/stuff in my signature) and while most advised against it, I find it to run pretty well. I'm not sure why it seems to run so well on my phone, but it's basically solved most of my problems (or at least it appears to have done that), but I know the kernel isn't "optimized" for my phone. Some major things people have said are that the ramdisking operations/system is totally different when comparing ICS and GB. This kernel that I'm using is running pretty well, even knowing this fact. What I was wondering is if I could basically get the ICS kernel, then "merge it" with a GB kernel's parameters that pertain to the ramdisk/other major options of GB. That would probably make it better. Also, people stated that multitouch issues for the DINC2 occured on Aeroevan's 0.8 kernel, but not on the 0.7 kernel. This was the changelog stated by aeroevan:
v0.8: Upstream CyanogenMod changes + small touchscreen driver update from HTC. Only tested on my CM7.2 Kang build.
Click to expand...
Click to collapse
So maybe this "small touchscreen driver update" is the thing that caused it, but I'm assuming many other kernels applied this update too? Maybe there is a way to roll back to whatever was in 0.7 in this sense to get rid of the multitouch bug that plagues some people.
I have a pretty powerful laptop, so development shouldn't be too bad. I plan on running Ubuntu 11.10 (or whatever people find suitable these days) in a Virtual Machine and I plan on compiling stuff from there. I am not claiming I know everything or that these things are correct....I am simply just throwing out some brainstorming to get some ideas out there. I know GB is "old", but I (and some others as well) enjoy it's stability and that it generally functions perfectly. Maybe this thread will get a look from popular devs, or maybe it'll get a look from people who just know this stuff. Thanks for reading, and sorry for the length of the post.
Looking forward to your progress on this.
Sent from my ADR6350 using xda premium
It would be nice to have another kernal for AOSP other than aero.
Your help in developing AOSP kernels would be fantastic.
Thanks given. Because I am hard of hearing I cannot use any of the kernels (even Evan's) and have to stick to Sense
Figured I'd make a new thread so Fuzz\Skankwitch ports and problems with them aren't mixed up in Quarx's CM9 thread. Helps keep relevant info and fixes for their respected rom easily available and findable. And to put Defy Porting in a centralized place (hopefully) All the relevant Defy Porting, especially CM9, is extremely scattered around here. I know, I wrote most of em. I'll post better porting guide eventually.
The latest build (0616) looks like its gonna be pretty awesome since it merges in even more of Linaro build environment. If you don't know, in a nutshell, Linaro is a new toolchain to compile CM9 with fixes and optimizations to the build environment that allows the compiler to use exotic flags, which in turn makes software run faster.
I'm off today and tomorrow, so I plan on starting that Aroma installed Kang in the next few hours. If you've never build a rock wall, they're a pita and will wear you out, especially when you're alone and the rocks are 200+ft away and you push them in about 260-300 pound loads (slightly) up hill to the wall -- damn I missed having the truck that day. Each rock weighs between 60-180 lbs, and I weigh 180 btw. For you metric guys, multiply by 2.2 to get the kilo version, provided my weed math is correct (~2.2 kilos a pound).
Once the initial framework is done, weekly updates won't be that hard to do since it will only be replacing the core rom and updating a few mods that affect system files (volume step, pdroid if it'll patch).
(reserved for later)
Updated:
here's a port I just made: http://www.sendspace.com/file/hh74un (June 28 FuZZ)
Looking forward to the port with the aroma installer. Hopefully linaro is gonna make our devices more smooth. Thanks skeevy!
corvx said:
Looking forward to the port with the aroma installer. Hopefully linaro is gonna make our devices more smooth. Thanks skeevy!
Click to expand...
Click to collapse
Not sure if its Linaro or the build.prop tweaks I did, but the roms feeling really smooth and hardly any lag -- even when opening the app drawer. Base rom and tweaks are done. Currently going over the scripting and changing it as needed, and it needs quite a few since it started as GB Miui, adapted and extended for V4, and now being used for CM9
Almost done with the scripting. I plan on doing a test install later this evening.
Also working on a deal to get a $40 Defy + shipping -- has a cracked screen, but my Bravo's cracked screen is worse Hopefully the deal is able to go through -- seller is in Australia and my online currency is Pre-Paid Visa.
Any Australian Bravoers able to help me out and pay for it for me and I'll hook ya up with an American Pre-Paid Visa #, with it comes full access to the American Market...It's only $40+ shipping. Seller doesn't know much about pre-paid cards, so I sent more info on them, hopefully I'm over worrying about it and the pre-paid card will work.
I plan on getting a Defy or Defy+ as the "upgrade" to my Bravo. Yes, I know that they're the same phones, but I want a damn torch flashlight, 720p recording, and a Gingerbread kernel with 4 Vsel's.
If this doesn't work out, I'll just get one off ebay in a few weeks.
What sucks is doing a GiS for Defy on shopping leads to a few scam sites selling them (Defy) for $120 -- you're lucky to find them on ebay for that price.
skeevy420 said:
Almost done with the scripting. I plan on doing a test install later this evening.
Also working on a deal to get a $40 Defy + shipping -- has a cracked screen, but my Bravo's cracked screen is worse Hopefully the deal is able to go through -- seller is in Australia and my online currency is Pre-Paid Visa.
Any Australian Bravoers able to help me out and pay for it for me and I'll hook ya up with an American Pre-Paid Visa #, with it comes full access to the American Market...It's only $40+ shipping. Seller doesn't know much about pre-paid cards, so I sent more info on them, hopefully I'm over worrying about it and the pre-paid card will work.
I plan on getting a Defy or Defy+ as the "upgrade" to my Bravo. Yes, I know that they're the same phones, but I want a damn torch flashlight, 720p recording, and a Gingerbread kernel with 4 Vsel's.
If this doesn't work out, I'll just get one off ebay in a few weeks.
What sucks is doing a GiS for Defy on shopping leads to a few scam sites selling them (Defy) for $120 -- you're lucky to find them on ebay for that price.
Click to expand...
Click to collapse
Glad to hear that you are upgrading, please dont stop developing for the Bravo. Looking forward to your realease. I tried syllogyking's release, and battery life is amazing, even wifi tethering is working. With all the scriptings you are adding and modifying I can only expect it to be smoother and better. Thanks.
On a side note: I'm not australian, but I use a local pre-paid visa, to buy online on the US, I use paypal though (ex. transfer from the visa to my paypal account).
corvx said:
Glad to hear that you are upgrading, please dont stop developing for the Bravo. Looking forward to your realease. I tried syllogyking's release, and battery life is amazing, even wifi tethering is working. With all the scriptings you are adding and modifying I can only expect it to be smoother and better. Thanks.
On a side note: I'm not australian, but I use a local pre-paid visa, to buy online on the US, I use paypal though (ex. transfer from the visa to my paypal account).
Click to expand...
Click to collapse
I'm not gonna stop, that's the whole reason I want to "upgrade" to a Defy.
I'll try and make it a point to finish the rom by tomorrow evening -- I have things to do tonight.
I did have an idea hit me yesterday -- an aroma installer that contains only the bootloader, our baseband, a few mods, and does basic Defy Rom Porting. It would be a Bravo repair, mod, and porting tool to make it easy for noobs to use Defy roms w\o the hassle of having to port it yourself and be able to tweak whatever rom you're installing. The hardest part would be the build.prop, but I could include generic props for cm7, cm9, miui 2.4.20. Anyone interested in something like that?
After going to the Defy forums, I find it kind of funny that a lot of the posters giving help are Bravo usres....but it makes since since we need to know a bit more about the phones because we have to do a lot more digging around in order to get the roms working.
very good idea to use Aroma with Defy Roms.
I'd like to test it when it will be done.
Also I'm interested will KANG team accept Bravo for rom develompent ?
Unfortunelly CM, MIUI currently stopped
PsyClip-R said:
very good idea to use Aroma with Defy Roms.
I'd like to test it when it will be done.
Also I'm interested will KANG team accept Bravo for rom develompent ?
Unfortunelly CM, MIUI currently stopped
Click to expand...
Click to collapse
I put doing the actual rom on the backburner for the moment -- I only have time to for the one project now since I have things going on everyday IRL now.
I decided to do the recovery tool since, other than volume step mod, everything else in the aroma rom was universal and a port tool means users can update, have mods and tweaks, and not have to either rewrite or remod the rom for updates -- which occur every few days with Defy Skank roms.
The recovery tool is about 1\4 - 1\3 done.
Planned features include
Defy CM9, CM7, MIUI (GB) Porting
Bravo Greenbread Mod (for MS2)
Reinstall the kernel\devtree\bootloader
Mods for ICS and GB roms
Basic Rom Backup and Restore in Aroma
/data/app backup\restore (for keeping apps in between flashes)
andriod secure backup\restore
system\data\andriod secure\cache\dalvik\sdext wiping (all separate)
Bootmenu Fixes for all roms
Apps only available on XDA or other forums (or banned by google; only legal apps, nothing pirate)
Add init.d support to stock roms
Multiple touch recovery options ??? (a new cwm touch is being worked on, need to use and test it first)
build.prop tweaks
Multiple gps, wifi drivers and settings
init scripts for performance
custom overclocks
add multiboot support to roms
Maybe more??? Will take requests
Still have much to do, as I only have the basic aroma layout done. I still need to finalize the aroma layout, add in a few of the mods, write the updater-script, write the language file, test, test, and test again....
A few of the features I have planned have never been done or attempted with Aroma as far as I know, and may not be in the release (full system backup and restore); but they technically should work. I'm going to try and make the backups CWM compatible, but don't quote me on that, as the md5 scripting may be a pita to do for first release and proof of concept.
I quite surprised Quarx hasn't released an updated 9 yet, with all the updates his git-hub page has had over the past few weeks. I was hoping that he'd stay with the every 2 weeks-ish that he was doing up until now -- not a big deal since we're Defy porting again. I suppose he's just more interested in the Novo7 tablet than the Defy\Bravo roms for the moment. I'd like to hear his review of it, since a dev's review holds more stock with me than a random website catered to end users.
Not sure if the Kang team will accept the Bravo, never asked or even heard it brought up until now. If someone here has a Linux Build Environment setup, go ahead and ask them if they'll help get it setup to start building Bravo Kangs. You'd get better results offering to build it yourself versus asking one of them to do it for you. I might ask when this is done, but might not since I'd be able to run the roms w\o even having to edit the zip once this is finished -- just flash Defy Kang, run Aroma Recovery, port and mod the rom, reboot and enjoy...easy enough I think.
Can we have MIUIV4?
glucky said:
Can we have MIUIV4?
Click to expand...
Click to collapse
Easier said than done....the Defy Miui v4's that we port from are based on Quarx CM9 from March 08. The newer CM9's don't like to be the base rom for v4 porting. Miui v4 is based on pure AOSP roms, not CM9; where GB Miui was based on CM7 and more compatible with CM7 porting.
Since it only takes 30-40 minutes to port and see if it works, I'll attempt porting v4 with the latest skank rom I ported last night. Maybe it'll work, maybe not.
In the meantime, I'm about to upload the yesterday's skank slightly tweaked with 30 step volume mod, Motoinspired CM9 Theme, HWA Selector --- I also have the srs mod installed with it, but frankly, the srs mod has washy treble that I don't like so I'm going to remove it first. I should begin that upload in 40 minutes, with it finishing 40 minutes after that. BTW, the lastest Skank (0628) is really stable and battery efficient (I fell asleep lisnening to music, woke up 8 hours later with 65% battery -- 45% loss with wifi on, radio on, 2 hours web surfing on wifi, 8 hours of music, 6 reboots, full brightness, and installing 20 apps from google sync is very acceptable to me -- means I can listen to music while driving for 12 hour, have about 4-8 talk hours, and have that last for at least 2 days on a single charge.
EDIT: Call of Duty being played in the other room, need to wait for the bandwidth to be freed up before I can upload.
As far as the Port Project is concerned, I have the Aroma layout almost finished (just need to add in an install rom feature), its completely translated for English and ready for multilingual. The rest of the Aroma part will only take 5 minutes or so to complete, then its on to the edify scripting and shell scripting; followed by actual testing of the tool. If I had to guess, 50%+ of what I'm trying to do has never been done in Aroma as far as I know; and if they work as expected, you'll soon start seeing Aroma Roms that install from Nandroid Backups as that's a feature I know Walter79 and espaciosalter20 both want. Expect something in the next 4-5 days as all I really have left is a ton of edify scripting and shell scripts (around 20-30 shell scripts I assume).
Skankport 0628 (NOW UP)
Port to Bravo of Skank CM9 0628
Does anyone here still need install instructions???
--If so, feel free to look in any other damn CM thread, they're all the same
Gapps not included, so flash it as well.
30 step volume mod
Motoinspired 1.4 Theme
HWA Selector 1.5 Beta
Bravia Engine
Vibhinna 1.01 Beta (Multiboot Manager Reloaded)
Defy Apps Removed (Torch, Rom Updater)
DOWNLOAD HERE
I don't think that Bravia Engine is working with ICS roms due to there being no Bravia being mentioned at all in logcat output; you can see it loading on GB Roms; also my first time trying Bravia on ICS. Everything else, however, is working perfectly*. Before enabling it in HWA, Chrome actually loaded and let me enter an address, but only showed a grey screen instead of fark.com which did load....Chrome's almost there.
*Except for camera....
camera isn't connecting for me...when I tried making my own skank port based on your instructions, it didn't connect either. any advice?
also, sio wasn't present (only noop and cfq) according to no frills, so I flashed the droidx zip to get it
syllogyking said:
camera isn't connecting for me...when I tried making my own skank port based on your instructions, it didn't connect either. any advice?
Click to expand...
Click to collapse
Not as of yet....I do know the problem -- its not loading the kernel module correctly. I've already tried the Defy modules, replacing camera.kobe.so with a renamed camera.jordan.so, using the Kobe CM9 camera app, swapping init scripts with Quarx CM9...I'm kind of stumped for the moment, but I've only been at it for about 10 minutes now. I never actually tested the camera, just ported over like usual, which usually works.
I'm just hoping that there isn't a new step in camera porting....
For sio, I didn't fully tweak the overclock.sh like I normally do as a test to see if the scripting would work like its supposed to. Apparently it doesn't....You can remove the 2 governors from the DX zip and also remove the 2 insmod lines for the Governors in the init script to save a bit of ram....and the boosted governor works as well as boostedass anyways. I'm not sure what Epsylon did, but he did do something to it.
Perhaps a better option would be to ask Fuzz for some help in starting up a Bravo build environment. I've built my own CM7's in the past. I'd already be doing the same for CM9, but I've been getting sync errors every time I try to sync with Quarx's Bravo repo since he's been releasing CM9 (usually due to MotoMagic, then I fixed that and couldn't sync with Quarx's personal repo).
The building and compiling isn't hard at all, its just a matter of syncing the repo (which I can't do) and knowing how to use git (which I don't). I'll send Fuzz a pm shortly and we'll see what happens from there.
EDIT: PM Sent; Hopefully he'll help me out in setting up a Kang build environment.
Yeah, I'm fearing there might be some further tinkering that now needs to be done to get the camera to work again. Since Fuzz basically adds cherry picks to epsylon's commits (he pushes mostly tpruvot commits in git), I'm thinking all of this is going to quickly change. The reason being because epsylon has already stated that jelly bean is going to be ported to defy in a few weeks, and that I can believe. But because the camera app is further "improved" in jb, it might still require some more steps to keep us on pace with the "bleeding edge".
anyways, I wish I had the time to read up on Android dev and get started on git, but unfortunately real life is taking priority atm
thanks for the pm initiative. hopefully, fuzz imparts some insight.
Oh the fun fun world of porting never ends when you own a Bravo.
From what I've understood, Jellybean isn't that big of an update so I'm not surprised that they're doin it (and doin it and doin it well). I actually expect them to keep coding until the platform just can't handle the new software any longer without updating the kernel...
I figured out my github sync problems -- the manifest.xml linked to the bravo repo was out dated, so I switched it to Quarx's manifest.xml on his github and have now fully synced it with no problems.
I was thinking that if I was going to ask for help, I might as well try to build it from the repo first (or at least have it all on hand).
If all goes well it should compile in while I'm sleeping.:fingers-crossed:
I'm referring to CM9 & not a Skank Kang, btw.
EDIT: NOW COMPILING, time to smoke a bowl and go to bed.
EDIT2: Didn't compile correctly...
EDIT3: Think I found that problem as well, been compiling for 3+ hours now. Problem was I followed the Bravo ICS instructions to the letter & and they're now wrong. Using Quarx's Defy+ Instructions, modified for the Bravo, are working.
EDIT4: Successfully compiled CM9, going to test it in the next hour or so -- took over 5 hours to build.
My First CM9 Compile
Here ya'll go -- my first compiled CM9 rom. This is basically Quarx 0526 with an updated CM app base. Haven't tested it much, but camera works, it synced with Google and installed all my apps, and it hasn't FC yet. It doesn't have the new hwui.allow feature yet, as I'm still learning git and want to do this all in the proper manner.
Once I learn how to properly sync the Defy repo to the Bravo repo and not screw up the camera is when I'll start to be able to make Bravo Kangs.
DOWNLOAD HERE
Install as usual, gapps not included.
While I don't want to start doing too much too fast, I'd like to add in Pdroid support, use Motoinspired as the default theme (I really like it), add in what ever the Skank roms do, and maybe add in Paranoidandriod to the mix.
I've actually wanted to do this since CM9 was released but I got caught up with v4 porting that went nowhere, v4 Patchrom that's being a pita but getting somewhere albeit slowly, found some work, and finally got COD Elite. I'd post my gamertag, but I'm currently using my Dad's since my PS3 is out of commission for the moment (it fell out of my truck door).
/Dammit, all this has done is set my other project back a few days, but I think we'd rather have Kangs from Bravo source rather than a tool to port them from the Defy.....Anyone disagree with that?
Great works skeevy420 ...congratulation..