Related
Hello,
I would like to change the HTC Hero's firmware/ROM to match that of the HTC Magic's firmware/ROM. My phone is CDMA, but I'm hoping that somehow, someway it is possible to do this. My reason for wanting this is so that I can finally do mods, like Cyanogen, since the CDMA Hero isn't really that widely supported, yet.
Thanks in advance for any help,
Tyler
Any new ROM will have to be CDMA, you can't change that since it has to do with phone hardware.
I have been.trying to port over gsm roms forever and.with no luck. Theoretically its possible but I haven't the faintest idea how.
Well, then I guess I have to resort to my last and great question. Since I'm stuck with my Hero, unless I go T-Mobile, how long, do you guys suspect, that it will take for more support to role out, like there is for the Magic? I ask because I'm wanting to know rather, or not there is a lot of development happening for the Hero because I really want great functionality and mod availability. At this point, if the answer is "not a lot", I may just drop the Hero for the Magic.
Thanks again for answering my questions,
Tyler
thejedislayer said:
Well, then I guess I have to resort to my last and great question. Since I'm stuck with my Hero, unless I go T-Mobile, how long, do you guys suspect, that it will take for more support to role out, like there is for the Magic? I ask because I'm wanting to know rather, or not there is a lot of development happening for the Hero because I really want great functionality and mod availability. At this point, if the answer is "not a lot", I may just drop the Hero for the Magic.
Thanks again for answering my questions,
Tyler
Click to expand...
Click to collapse
So you're saying you're "STUCK" with a month and a half old phone, unless "more people start supporting it"? i.e. People spending their free time creating mods for the Hero, so that you can get it for free? And if people aren't going to do mods and features for free in the near future, then you're just going to get rid of your Hero and go to T-Mobile for the Magic because it has people who are dedicated to releasing software they dont get paid to spend time working on? Seems like a lot of complaining about something that is completely voluntary, nobody has to work on any mods and nobody has to support any device. If you want to drop your Hero, just do it already. Nobody wants you to keep using it, nobody is forcing you to keep using it. Just do it already, nobody cares to read threads like this.
Wow, you took what I said and totally blew it out of proportion. The reason I wanted to get Android was because I wanted to be able to do things, like root my Android device. I fully support developers in their endeavor to develop applications, mods, ROMS, etc for all Android devices on their time. I do not, however, sit here and feel that the best idea to do is to whine and cry about support for my Android device not yet being fully supported or embraced. I simply asked rather, or not heavy development was going to happen in the near future, so as to ascertain a good decision on rather I should switch. That way I could get the full and best support and benefit from my personal experience with Android. I am not a developer. I've only gotten into this, so I was simply curious as to how development was coming along for the Hero at this time, and rather it may have been a better idea to just switch. Sorry To Have Offended The Offended.
**EDIT**
And understandably, having reread what I wrote, I can understand how what I said may have come off as a little dickish; however, it was not my intention, nor was it my wanting to cause a conflict.
thejedislayer said:
Wow, you took what I said and totally blew it out of proportion. The reason I wanted to get Android was because I wanted to be able to do things, like root my Android device. I fully support developers in their endeavor to develop applications, mods, ROMS, etc for all Android devices on their time. I do not, however, sit here and feel that the best idea to do is to whine and cry about support for my Android device not yet being fully supported or embraced. I simply asked rather, or not heavy development was going to happen in the near future, so as to ascertain a good decision on rather I should switch. That way I could get the full and best support and benefit from my personal experience with Android. I am not a developer. I've only gotten into this, so I was simply curious as to how development was coming along for the Hero at this time, and rather it may have been a better idea to just switch. Sorry To Have Offended The Offended.
Click to expand...
Click to collapse
There are many threads with people making their own roms, and modifications are being made to the hero by various people. Heavy development like going to 1.6 or 2.0 will most likely not happen by any developer, but by HTC itself. Once they release a new version, people will make a new rooted ROM with all the changes. For a fairly new phone, it got rooted fairly quickly (within a month of being released or so). It hasn't even been rooted all that long yet. All of this information is available in various threads. In the end its your decision on if you can wait or not to receive updates. Bleeding edge isn't always the best choice for everybody. If you prefer bleeding edge, perhaps you did get the wrong phone because there will likely be much more activity with, say, the Droid. But as for apps, there should be tons and tons of more apps coming available for the android platform as time goes on. I just cant see why you would want to switch phones based on a really short time period of it being out, jumping ship because it hasn't been hailed and given 100% attention by tons of developers yet. Honestly, as more android phones are released, I think more people will start developing for them and the android community itself will continue to grow. There are still some 7 year old Casio devices that receive updates, if you can believe that.
In all honesty, I knew I was a little quick to jump the gun when I said rather, or not it was a good decision to move from the Hero to the Magic. Again, this is all really new to me. In my mind, my main concern was that because of the Hero's Sense UI, this would make it a lot harder for developers, like Cyanogen Mod, to keep the Hero up-to-date with the rest of the older Android devices. The Magic, seeing it being a lot more supported in just three short months since its debut, made more sense to me to possibly move to. As it had tons of development happening for it, and I simply wanted to be apart of the action.
wouldn't a 1.6 Rom work since it "supports CDMA" out of the box???
@ azfxstb
I took the liberty of looking around, and I ended up finding some links from HTC for 1.6 support. Link: http://developer.htc.com/google-io-device.html
According to the article, though, the next successive version relies on a previous version in order to update properly. In other words, in order to know I have full functionality and support, I would have to start from the beginning of the Magic's support and simply continue updating till I reach the newest update. I may be wrong, but if I'm not, then it may be something worthwhile considering, even if it's a hassle. Anyone have any thoughts about this method?
I'd say stick it out. The Sprint Hero hasn't even been out for 2 months and it is rooted and there are a couple of custom ROM's posted here. I've had my Hero for 2 weeks and have already tried numerous releases, and all have been very stable for me.
I'd love to see some of the improvements Cyanogen come over, and I'm sure they will eventually, but you have to remember how long of a time frame the Magic had to work with.
azfxstb said:
wouldn't a 1.6 Rom work since it "supports CDMA" out of the box???
Click to expand...
Click to collapse
We don't know that HTC's shoehorned CDMA support into 1.5 is compatible with the built-in CDMA support in 1.6. What that means is that there's a potential that even if we did get a 1.6 build on the phone, HTC's proprietary (i.e., not required to release source code for) software that sits between the Android framework and the linux kernel (which in turn talks to the hardware) might be speaking a different language that Android 1.6 can't understand. That's the problem with their hacked-together 1.5 build. Make note that I do not know this for certain, but it's certainly a possibility, and if that's the case, we'd have a broken phone until those HTC layers could be translated from hacked-1.5 to native-1.6.
That's why, as already stated above, those moves probably won't happen until HTC releases a 2.0 build (which means we might never see 1.6 run on this phone even after the 2.0 release, since we'll never have the HTC software that is written specifically for the 1.6 platform).
To break it down, the phone has 2 processors: ARM9 and ARM11. ARM9 runs the radio hardware, and the radio controls literally *everything* that makes this phone usable. Think of ARM9 like your computer's BIOS chip. Except in a very rare case of someone who really really wants to hack on their phone, the ARM9 will never be modified by us.
The ARM11 is the next layer, and that's what actually runs the OS, recovery images, etc. The ARM11 is able to communicate with the ARM9 using a series of two-way communication channels (shared memory) and hardware interrupts.
The linux kernel contains drivers that on one side talk to the ARM11 and other hardware in the phone, and then expose controls on the other side that allow the rest of the OS to work with those things (e.g., turn the screen on/off, register touches on the screen, play sounds, vibrate, make calls, etc).
For some things, that's enough to let Android take over and actually make use of some of those things (LCD, touchscreen, sound, ...). Still, there are other things that require intermediate controllers between the devices exposed by the kernel and Android. For example, "rild" is in charge of managing the modem as far as things like issuing commands to your carrier, getting online, telling the modem to make a call, finding out signal strength, etc. But HTC wrote their own ril that interacts with the modem -- and they aren't required (in fact, they're not allowed!) to release the source code for that, because a) it was developed using proprietary information given to them (under NDA no doubt) by Qualcomm, and/or b) it contains information that HTC themselves want to keep private, protecting their intellectual property, etc. There are several other userland libraries like that, which are NOT part of the kernel, and therefore are not required to be released as open source. Yet they are required for Android to work, as android will speak directly to those libraries, which translate the messages in order to communicate with the kernel, which communicates with the ARM11, which talks to the ARM9, which makes it happen.
The breakdown happens at the "android speaks to the libraries" step, because Android 1.5 speaks a certain language, and that's (potentially) different from the Android 1.6 language. Yes this phone is CDMA, and yes Android 1.6 has native support for CDMA... So, you say, putting Android 1.6 on the phone should "just work". But the HTC libraries that are on our phones are not designed for 1.6, they're designed for 1.5. And they're not even designed for the "standard" GSM 1.5, but for a "hacked" CDMA 1.5! If we put Android 1.6 on the phones, we could *try* to reuse the existing binary form of the HTC libraries, but if 1.5 and 1.6 talk different languages (most likely they do), the 1.5 version of the binary libraries are going to get confused and reject it. Then we're left with a 1.6 platform that can't talk to the 1.5 libraries, and we get major functionality meltdown. To be fair, it would be possible to write an additional translation layer that would convert the 1.6 messages into something that we "think" the 1.5 libraries will understand, but is it really worth the effort? (hint: it's not a small effort ) Then try doing the same with 2.0, and the potential for translation problems are even worse...
And not to mention, 2.0 also requires the 2.6.29 kernel, which (surprise, surprise), does not exist (for this phone) in the wild. We could theoretically get 1.6 running, since we already have a working 2.6.27 kernel (the phone shipped with it, and if we assume that the shipped kernel is "good enough", we can simply reuse it -- we already do that with the recovery image and even MoDaCo's rom). But as soon as we think about either modifying the kernel as it is, or god forbid, upgrading to 2.6.29, we hit a roadblock because we don't have the source code yet for the 2.6.27 kernel. Once that code is released, we could hypothetically port that support to 2.6.29. Or once HTC releases an Eclair build for this phone, it'll be guaranteed to have a ready-made 2.6.29 kernel buried inside, as well as the binary HTC libraries that are required for our phone. Until one of those two things happens (or, admittedly, someone reverse-engineers what's required... which quite frankly is not worth anyone's time considering we know that HTC *will* release both of those things eventually), Eclair is absolutely out of the question.
The short version (go ahead, admit it, you skipped to here even though I didn't put a "short version at the end" disclaimer at the top): 1.6 will absolutely require reverse-engineering the HTC libraries, just to get an already outdated (albeit still an upgrade) version of the OS on the phone -- not worth the effort. 2.0 will absolutely require reverse-engineering (both the kernel AND the binary libraries), just to get Eclair running on the phone maybe a couple weeks before HTC gives it to us on a silver platter -- And you're still likely to have a partially gimped phone at that point!
And the moral is: this **** is hard. HTC is already doing the work we need. HTC will make everything work "reasonably well". And they'll give it to us when they're done. Thus, no one *wants* to waste the effort doing it themselves. Ergo: we wait.
maejrep said:
We don't know that HTC's shoehorned CDMA support into 1.5 is compatible with the built-in CDMA support in 1.6. What that means is that there's a potential that even if we did get a 1.6 build on the phone, HTC's proprietary (i.e., not required to release source code for) software that sits between the Android framework and the linux kernel (which in turn talks to the hardware) might be speaking a different language that Android 1.6 can't understand. That's the problem with their hacked-together 1.5 build. Make note that I do not know this for certain, but it's certainly a possibility, and if that's the case, we'd have a broken phone until those HTC layers could be translated from hacked-1.5 to native-1.6.
That's why, as already stated above, those moves probably won't happen until HTC releases a 2.0 build (which means we might never see 1.6 run on this phone even after the 2.0 release, since we'll never have the HTC software that is written specifically for the 1.6 platform).
To break it down, the phone has 2 processors: ARM9 and ARM11. ARM9 runs the radio hardware, and the radio controls literally *everything* that makes this phone usable. Think of ARM9 like your computer's BIOS chip. Except in a very rare case of someone who really really wants to hack on their phone, the ARM9 will never be modified by us.
The ARM11 is the next layer, and that's what actually runs the OS, recovery images, etc. The ARM11 is able to communicate with the ARM9 using a series of two-way communication channels (shared memory) and hardware interrupts.
The linux kernel contains drivers that on one side talk to the ARM11 and other hardware in the phone, and then expose controls on the other side that allow the rest of the OS to work with those things (e.g., turn the screen on/off, register touches on the screen, play sounds, vibrate, make calls, etc).
For some things, that's enough to let Android take over and actually make use of some of those things (LCD, touchscreen, sound, ...). Still, there are other things that require intermediate controllers between the devices exposed by the kernel and Android. For example, "rild" is in charge of managing the modem as far as things like issuing commands to your carrier, getting online, telling the modem to make a call, finding out signal strength, etc. But HTC wrote their own ril that interacts with the modem -- and they aren't required (in fact, they're not allowed!) to release the source code for that, because a) it was developed using proprietary information given to them (under NDA no doubt) by Qualcomm, and/or b) it contains information that HTC themselves want to keep private, protecting their intellectual property, etc. There are several other userland libraries like that, which are NOT part of the kernel, and therefore are not required to be released as open source. Yet they are required for Android to work, as android will speak directly to those libraries, which translate the messages in order to communicate with the kernel, which communicates with the ARM11, which talks to the ARM9, which makes it happen.
The breakdown happens at the "android speaks to the libraries" step, because Android 1.5 speaks a certain language, and that's (potentially) different from the Android 1.6 language. Yes this phone is CDMA, and yes Android 1.6 has native support for CDMA... So, you say, putting Android 1.6 on the phone should "just work". But the HTC libraries that are on our phones are not designed for 1.6, they're designed for 1.5. And they're not even designed for the "standard" GSM 1.5, but for a "hacked" CDMA 1.5! If we put Android 1.6 on the phones, we could *try* to reuse the existing binary form of the HTC libraries, but if 1.5 and 1.6 talk different languages (most likely they do), the 1.5 version of the binary libraries are going to get confused and reject it. Then we're left with a 1.6 platform that can't talk to the 1.5 libraries, and we get major functionality meltdown. To be fair, it would be possible to write an additional translation layer that would convert the 1.6 messages into something that we "think" the 1.5 libraries will understand, but is it really worth the effort? (hint: it's not a small effort ) Then try doing the same with 2.0, and the potential for translation problems are even worse...
And not to mention, 2.0 also requires the 2.6.29 kernel, which (surprise, surprise), does not exist (for this phone) in the wild. We could theoretically get 1.6 running, since we already have a working 2.6.27 kernel (the phone shipped with it, and if we assume that the shipped kernel is "good enough", we can simply reuse it -- we already do that with the recovery image and even MoDaCo's rom). But as soon as we think about either modifying the kernel as it is, or god forbid, upgrading to 2.6.29, we hit a roadblock because we don't have the source code yet for the 2.6.27 kernel. Once that code is released, we could hypothetically port that support to 2.6.29. Or once HTC releases an Eclair build for this phone, it'll be guaranteed to have a ready-made 2.6.29 kernel buried inside, as well as the binary HTC libraries that are required for our phone. Until one of those two things happens (or, admittedly, someone reverse-engineers what's required... which quite frankly is not worth anyone's time considering we know that HTC *will* release both of those things eventually), Eclair is absolutely out of the question.
The short version (go ahead, admit it, you skipped to here even though I didn't put a "short version at the end" disclaimer at the top): 1.6 will absolutely require reverse-engineering the HTC libraries, just to get an already outdated (albeit still an upgrade) version of the OS on the phone -- not worth the effort. 2.0 will absolutely require reverse-engineering (both the kernel AND the binary libraries), just to get Eclair running on the phone maybe a couple weeks before HTC gives it to us on a silver platter -- And you're still likely to have a partially gimped phone at that point!
And the moral is: this **** is hard. HTC is already doing the work we need. HTC will make everything work "reasonably well". And they'll give it to us when they're done. Thus, no one *wants* to waste the effort doing it themselves. Ergo: we wait.
Click to expand...
Click to collapse
WOW...did you stay at a Holiday Inn Express last night????....J/K thanks for the in depth explanation
Does anybody have any clues why we haven't seen any new froyo firmwares so far? (we had a wave of jp1 to jp3 and then silence)
Is it because
a. Such new firmwares exist but are not leaked anymore (samsung detected the leak) or
b. Such new firmwares do not exist in the sense that they are still being developed and not even nightly builds exist? (which I doubt).
I would have expected Samsung to have given something to its beta testers to play with..
Just a thought..
There were a lot of tweets about your question.
Sadly, the correct answer is A.
Here is the latest:
http://twitter.com/SamsungFirmware/status/21474133152
It's probably more complicated (and I have a theory).
Firstly, the firmware's were probably leaked because Samsung got sick of the people who kept running around saying they were liars and were simply telling people what they wanted to hear. So, they possibly released JP# themselves. It's also possible a carrier requested them for internal testing with Froyo, and they were leaked by the carrier (after all, carriers also want to work on their own customisations, and leakers get an adrenaline rush).
Secondly, having hung around the Songbird project before, Songbird stopped releasing early betas because people are morons. People would post duplicates of known bugs dozens of times wasting resources, and would make ridiculous assumptions based on unfinished code.. It's probable that many people are returning their phones in part because they don't see evidence of change in leaked firmwares. Even now, despite saying they are still working on the GPS fixes, there are a few people running around screaming "it wont get fixed, because Samsung are only making minor changes in leaked firmware".
Then, it's also possible the tree is too broken at the moment to release to anyone, some of the programmers are on leave (it isn't impossible to believe they were working 24/7 up to the launch date of the phone), or they are working on GPS problems and such, which are so complex that they need to be merged in one shot.
Anyway, we can't know for sure, but its a good thing actually if Samsung don't release every single build they compile..
I do not want to upset anybody, just trying to get some understanding of the entire upgrade to a new OS version.
I'm a programmer myself, but on Windows platform and mostly do middle tier business server side apps. Do not know a thing about Linux and android. But had some java experience in the past.
I wonder why we cannot get Froyo so long? Ain't the sources open? Even if we do not have some drivers, these parts cannot change dramatically from version to version. Published API must be stable...
Is this about Dalvik JVM? But, I guess this must be in released ROMs for other phones in the line.
What's the deal? Will appreciate some explanation here.
Android is open source, but that is only the operating system and the kernel, but the drivers and RIL that make the device actually functional are the issue as far as I'm aware. From what I've read here and in IRC, Samsung gave us a hack-job RIL, which is causing many of the issues with getting an AOSP ROM fully compiled and working. I think there may be some driver issues as well to be worked out yet, but I feel those are less important than getting things like phone/data/messaging working. I'm guessing there are more technical reasons why they can't just get 2.1 or 2.2 built from source, but those are probably the big issues.
Honestly, it boils down to Samsung.
Put simply, they're crappy coders (as HTC once was many moons ago), or they're just hella lazy (I strongly believe its the former, given RFS and this RIL mess). Most companies are pretty crappy coders, but most of the time, it doesn't interfere with major things, like OS upgrades.
That, plus the lack of effort or support on Samsung's part, has me never wanting to buy another Samsung phone again, or ever recommending an Android phone from Samsung....
I'm gonna do my best to find in my next phone another quick processor with a nice super AMOLED screen and be done with Samsung, I've had enough, and I'm a very patient person....
What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)
CNemo7539 said:
What is RIL? Is this Radio Interface Library?
Is it linked into kernel or other module? Not extractable at all?
As I imagine it to myself, if it is some sort of dll or package, it shouldn't matter if we do not have source, because it's interface have to be already strictly defined. It doesn't matter if it is buggy. It should work with any android version.
Please correct me if I'm wrong.
P.S. I have Dell Axim v50x and people already created ROM from scratch! However it doesn't have RIL. ;-)
Click to expand...
Click to collapse
if it could have been done, birdman would have done it already
Well I think it's a valid question. Some might think it tedious or obnoxious, but absolutely valid. This is a development forum after all. The reason we don't have 2.2 isn't a hardware limitation, so it must be a practical one -- or yes it would be here.
But I'll just speak from speculation in the hopes that someone will correct me. For god sakes this is a development forum! We've got releases, we have fixes, we have patches, we have complaints, we have gossip. I'd love to see all the _development_ discussion I can get.
From a wider puzzle-piece perspective, I would like to know what is missing. We have working drivers. We have working hardware. We have full source from Google for the operating system. There are several other android phones on Verizon, a few even have Froyo. Sprint currently offers a CDMA Galaxy S phone (Epic) with android 2.2, and that phone possibly shares some hardware (though the WIMAX radio is totally irrelevant to us).
I'm not up to speed on exactly what the RIL is, or how it gets plugged into the android kernel. The RIL (Radio Interface Layer) is a software layer between android itself and the drivers controlling the phone hardware. Google provides some samples for a carrier to create one to govern communication on their network. I'd expect one issue of randomly hacking something like this, is if you are taking over your radio hardware's communications, then you have the capability of putting unwanted data on the network, which might even be criminal. Am I being extreme? So, perhaps we can't touch the RIL and need to wait for it to be spoonfed to us by those that bought the radio band from the FCC. Perhaps this code is inexorably married to particular hardware, unavailable for reading, or even encrypted. Maybe the primary limitation is the royal pain in the apricots that it is to inspect, decompile, and reverse engineer binary code.
But what if we could do something?
My understanding is the RIL is only a carrier-specific interface to the underlying hardware. Shouldn't it be similar between phones, even with wildly different hardware? Shouldn't its interface also be similar between close versions of android? The Droid 2 is a verizon phone with a RIL that does indeed work with Froyo. What I'd like to know is A) can another phone's RIL be extracted within the same carrier, and B) Being the abstract entity that it is, what prevents it from being married to the Fascinate's hardware base?
To be honest, I ardently believe a frank discussion (sans opinions, complains, problems, just productive discussion w/ a smattering of facts) BELONGS in the Development forum.
I'll stop here, in case this thread dies, as so many of mine do.
Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App
I don't know anything about how the RIL works, but I would assume that it could only be easily ported from one device to another if they were using the same chipset in the underlying hardware for the phone. I doubt you'd be able to take the Droid 2/X RIL, and take it to the Droid 2 Global or Droid Pro. Given that, I'm guessing that you can't really take a RIL from one phone and put it on another without extensive work, since most OEMs tend to use different hardware in their devices. From what I've heard, there is a semi-working AOSP build floating around, so the devs are trying, but Samsung's crappy source to work from is not making things easy for them.
There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App
ksizzle9 said:
There are actually some semi-working builds of aosp floating arpunfld but the last time I checked one out it was missing one thing that I consider to be kind of a biggie. It couldn't quite make calls. I'm sure they have it to make calls now but there is a reason its not out to the forums yet. I agree withstand nuts up there. Thanks you Samsung.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
i believe there was still no radio at all in aosp, and the hope is that 2.2 can fill in the gaps
Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?
CNemo7539 said:
Wow, wow, wow!
Why do we need another phone RIL? Current one from SF at hand should do perfectly. Did Google changed something in android API related to a RIL? I don't know for sure, but never heard or read anything making me think they did it. Android should call RIL and that is set in stone. ALL calls signatures must to be known. Something new may be added, but it is not show stopper.
So, I still do not understand - is it not extractable or what?
Even if not and it is somewhere in protected memory, encoded or whatever, Froyo slapped on top must work, IMHO. And sources available. So, why we stuck waiting for Samsung?
I know, one may say - do it yourself if you are so smart... Once again, I just want to understand root of the problem. I probably can do something, because I have degree and experience. But, it will take me forever. From what I've tried and seen learning curve is very steep.
On the other hand, skilled developer might simply need fresh look at the problem... May be guys just hitting wrong wall?
Click to expand...
Click to collapse
is it possible? perhaps...but the 5 or so guys who really develop for this phone havent been able to get it to work....nor is aosp working 100% on any galaxy s phone
Response from developers?
Anyone?
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
Agree get your ass moving so we can have teh honeycombzzzz. Quit being such a lazy stingy jerk and get us our AOSP!
ksizzle9 said:
Jt1134, adrynalyne, and fallingup(angel12) are all very capable as well. This is solely the fault of none other Samsung.
Edit: to answer your question, i think that.the answer about RIL is no, although i dont have a good qualified answer about why the RIL from D2 cant be ported im sure that if it could have, it would have. Sorry thats not a better answer.
Sent from my ADR6300 using XDA App
Click to expand...
Click to collapse
yes i was just pulling one dev name out for the heck of it
but i subscribe to the "if it could have been done, it would have been done"
adrynalyne said:
Yes, you know so much, we are waiting for you to fix it.
Hurry the hell up.
Click to expand...
Click to collapse
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
that may be a problem for those who just stay here as virtually everything is irc only these days...or the majority of it anyway
CNemo7539 said:
I don't care what you did for community! But you behave like f****g jerk.
No real explanation for the rest of us? Stay on irc, we will survive without your comments here.
Click to expand...
Click to collapse
How many different ways do people need to say that "it's being worked on"? The devs are doing a lot of work on our device, but also working with other stuff, all in their free time. Follow the stuff they do on Twitter and github, or join in on IRC.
Attitudes such as your's are precisely why the devs have stopped posting stuff here. You act as though it's a simple process to do things, when it isn't, especially when Samsung gives you a crappy base to start from. The devs have to first get Samsung's source fixed and cleaned up, then start on whatever it is they want to work on, all while finding more bugs and issues that need fixed, primarily all stemming from the crappy source. If you want to be angry at someone, make it Samsung, not the few devs that are working on our device.
Sent from my StupidFast Voodoo Fascinate
As I said - I will survive. I'm OK even with not rooted stock.
Was it so difficult to answer what the real problem is? I don't know what is the problem with this generation? Do I need to be on FB, irc or whatever to get the answer? Why do not answer in place? Ain't it this forum purpose?
No, seems like I need to kiss somebody ass to get meaningful response these days... That way he can maintain his "super god" status.
I do believe I've been pretty polite stating my question, even though English is not my native language. What generated so much sarcasm?
I'm hoping somebody will be able to educate me a bit here on some deep technical questions. I've been searching for some information on this topic for a while now but without any luck. In a nutshell what I am curious about is this.. if I were to, lets say, build my own new handset, what would be entailed in getting android to work on it?
I know a kernel must be built with all the drivers and modules to communicate with any specific hardware/radios etc. But once you've got the kernel, is there still more porting that has to be done in the core android code? Are there significant CPU architectural differences or some other major differences between handsets that require more porting within the rest of the OS code? (Side question: if I want to build a kernel from source, what tools do I need)
To ask my question more specifically with the Epic, what is going to be necessary to get Gingerbread on it? If we already have the source for Eclair, or when we get the source for Froyo on the Epic.. what is it that makes it more than just a matter of pulling the drivers from those versions to make things work. Is android not built in a modular enough way to enable that?
I am myself a developer, but as I'm sure is obvious from my questions.. I'm not very experienced at OS level development. And what limited knowledge I do have mainly comes from making correlations to desktop OS, which is probably what is leading me astray.
I'm just really craving to know more about this stuff, so thanks ahead of time to anyone who takes their time to school me and help me understand. If there is any material out there that I should just go RTFM, I'd like to do that but please point me in the right direction.
Thanks!
FYI, your post/s do not pertain to any direct development. They are just generalized questions that can be answered with a simple search.
See Here
Reported as belonging in Q&A/general.
The most difficult part is porting drivers (if they're not already part of the kernel mainline) and device-specific glue code to the new kernel base. This is difficult becuase (i) it's a fair amount of code, (ii) the kernel does not have a stable API, so the necessary changes may be somewhat far reaching, and (iii) bugs that crop up are often more difficult to pin down and fix than in userspace programs. It also doesn't help the matter that Samsung's portion of the kernel code is messy, buggy, and just generally not in a state that would make it easy to port over to a new tree.
The reason why we can't just port Eclair drivers to Froyo, or Froyo drivers to Gingerbread, is that there's a fair number of proprietary modules on the phone (LCD, WiMAX, the entire storage stack, etc.) to which we don't have the source code. These modules are compiled against a specific kernel minor version (e.g., 2.6.29 for Eclair) and won't load in Froyo or Gingerbread. The version number can be faked, but if there's any change in the module API, or in the "API" (which isn't even formally defined) of dependent kernel code, all bets are off.
In theory if there's any Galaxy S device with a Gingerbread release, it might be possible to get a limited-capability kernel up and running, depending on how much the proprietary drivers change across devices (hopefully not much). The Nexus S doesn't count though as Google replaced the entire proprietary flash stoage stack with a GPL-based one. While we might be able to get such running on Galaxy S hardware, it would be incompatible with the existing storage layer and would necessitate a full device flash. Not really something you want to do when an official update with a complete set of drivers is going to be made in the "near" future.
Aside from the kernel, you would have to modify the parts of the Android userland that interface with hardware specific components, for example the "4G" (WiMAX) settings menu and such. I think much of the modem interaction also happens in userland. Then you have to port over whatever custom skin (e.g., TouchWiz) you have.
For some reason this is often believed to be the most difficult and time consuming part of a port, i.e., it's commonly complained that "HTC & Samsung delay releases to port Sense & TouchWiz, if they just dumped them and went AOSP updates would be a lot faster." Honestly it's not. It's an API update like any other Android app, and third party launchers don't seem to have significant problems here.
Mind you, I mention the difficulties of kernel porting without having actually attempted to do it myself, largely becuase it is so daunting. I know there's folks interested in doing this, and perhaps they have some tricks that make it a bit easier in a specific scenario. In general though, these are the difficulties one enounters when trying to port new Linux versions to any embedded platform.
I've often wondered this myself, as well as wondered why Google seemed to get caught with their pants down.
Now granted I don't know the nitty gritty details, but I don't understand why android wasn't written in a manner where as much of it as possible is just apps, and anything that is core is written where the handset makers just need to do the very low level stuff.
On top of that then it could have been made to be more easily themed, even rather dramatically.
Samsung/HTC should only be maintaining the low level "android wants the gps location, I know how to work this specific chip and give it back" and Sense/TouchWiz should just be a theme, and some custom widgets. Android itself should be virtually untouched between those two layers, and updates that don't change how it has to interact with the hardware or the themes should come straight from google.
Thankfully things have at least started to move this way. (you don't need to roll out a ROM update through sprint because Google updated the market like you used to, etc)
If Dell wants to customize Win 7 they add onto it, they don't roll their own copy of it, creating god knows how many fragmentation issues in the meantime. (And yes, I know Windows isn't open source, so they can't, but you get what I'm saying.) Because the second they did that they'd then take on a much larger QA burden, on top of everything else.
If android is untouched for the most part, it works, or it's a bug for everyone. You'd only need to test calls to your low level updates, which could for the most part be automated. The second you start changing a line here and there in the source code, now all of a sudden you have to do the "If I make a calendar item while on a call on a leap year the phone reboots" type QA/Support as well.
Edit: And of course it's very possible that is more or less how it is and the handset makers just flat out take longer to update then anyone imagined they would.
What language/s do you have to know to do all this?
nubsors said:
What language/s do you have to know to do all this?
Click to expand...
Click to collapse
C for kernel and Os. Java for apps(sdk). C and java(ndk/sdk) for apps that require native code implementations of things (eg. The VLC player that is coming. It wasn't possible until the latest edition of the ndk.)
Sent from my SPH-D700 using XDA App
Thank you mkasick for a great detailed answer. I didn't think about the fact there are closed source drivers to worry about as well, and that explains a lot.
@ghostrid3r: I did plenty of simple searches which did not answer my questions before posting, but thank you for the link. Also, not that it matters to me.. but is the development section just for releasing custom roms or something? If questions directly pertaining to development details don't belong there, seems to me the section should be renamed to "Epic 4G Custom Roms" instead.
Firstly, I'm NOT a Developer - I want to make that very clear
I have been trying to get data/info about what ever happened to the Original Samsung Galaxy S4 'TouchWiz'
Camera feature/ability to be able to 'Simultaneously' record videos (not talking about taking pictures here)
with both the front and back cameras on the phone.
This question has been asked before by a very very very small number of people on the net including in XDA
developers forums, However these questions only have been asked on forums relating to NEXUS phones/devices.
When i originally bought my S4 (second hand) i used the recording feature, i absolutely love it, i think it it brilliant,
it is one of the reasons why the S4 has such appeal for me.
I later upgraded to CyanogenMod, because of privacy concerns relating to Samsungs Involvement with the NSA over
their KNOX security.
The OS seemed fine to me, but this security concern was the basis of WHY i moved over to CyanogenMod.
Then i found out, that CyanogenMod does NOT Support the Dual Camera feature.
I contacted Samsung, and they told me that the Camera app was not really an app at all, but was in fact part of the OS itself.
But remember, the Genuine Samsung Galaxy is actually model number GT-i9500, which uses the Exynos Chip, unlike the Samsung Galaxy S4
variant known as the S4 LTE GT-i9505, which uses the Qualcom Chipset.
It has also been said by some XDA developers, that Samsungs 'TouchWiz' is not Open Source, it is Closed Source.
Well belonging to the company, this is no surprise, I'll also bet that it is probably Patented as well.
I say, so what ?, CyanogenMod does NOT need the original samsung 'TouchWiz' code, it only needs to know the HardwareSpecs of the Qualcom
Chip, then programming/developing can begin.
The S4 is already Superceeded by the S5 (and any possible variant(s) of that), i feel that the GT-i9505 is getting left out of the picture.
Are there any answers to this mystery ???
The7Suggester said:
Firstly, I'm NOT a Developer - I want to make that very clear
I have been trying to get data/info about what ever happened to the Original Samsung Galaxy S4 'TouchWiz'
Camera feature/ability to be able to 'Simultaneously' record videos (not talking about taking pictures here)
with both the front and back cameras on the phone.
This question has been asked before by a very very very small number of people on the net including in XDA
developers forums, However these questions only have been asked on forums relating to NEXUS phones/devices.
When i originally bought my S4 (second hand) i used the recording feature, i absolutely love it, i think it it brilliant,
it is one of the reasons why the S4 has such appeal for me.
I later upgraded to CyanogenMod, because of privacy concerns relating to Samsungs Involvement with the NSA over
their KNOX security.
The OS seemed fine to me, but this security concern was the basis of WHY i moved over to CyanogenMod.
Then i found out, that CyanogenMod does NOT Support the Dual Camera feature.
I contacted Samsung, and they told me that the Camera app was not really an app at all, but was in fact part of the OS itself.
But remember, the Genuine Samsung Galaxy is actually model number GT-i9500, which uses the Exynos Chip, unlike the Samsung Galaxy S4
variant known as the S4 LTE GT-i9505, which uses the Qualcom Chipset.
It has also been said by some XDA developers, that Samsungs 'TouchWiz' is not Open Source, it is Closed Source.
Well belonging to the company, this is no surprise, I'll also bet that it is probably Patented as well.
I say, so what ?, CyanogenMod does NOT need the original samsung 'TouchWiz' code, it only needs to know the HardwareSpecs of the Qualcom
Chip, then programming/developing can begin.
The S4 is already Superceeded by the S5 (and any possible variant(s) of that), i feel that the GT-i9505 is getting left out of the picture.
Are there any answers to this mystery ???
Click to expand...
Click to collapse
What mystery? That Cyanogen doesn't offer the ability to record with the front and back cameras at the same time?
That's not a mystery. It's that only 1 person out of a million would ever want to do that so no one is devoting their development time to integrating that feature.
Dual Camera Support - i9505
Skipjacks said:
What mystery? That Cyanogen doesn't offer the ability to record with the front and back cameras at the same time?
That's not a mystery. It's that only 1 person out of a million would ever want to do that so no one is devoting their development time to integrating that feature.
Click to expand...
Click to collapse
I'm afraid I'm not completely sure i know what you mean?
Do you mean that there would only be 1 Developer out of a million who would use this feature, and therefore no support would be actioned for this ?
OR do you mean that in your opinion there are hardly any people who would own a phone like the S4 that would want to use this feature.
Why would anyone *NOT* want to do this. It's fun for one thing.
Maybe I've made a mistake but, i thought that one of the things that XDA devs were all about, was trying to fix or patch areas on OS's
where the mainstream had overlooked, and especially about importing and bringing new features about to free OS's such as CyanogenMod.
Could you please clarify i bit more carefully about, this.
Skipjacks said:
What mystery? That Cyanogen doesn't offer the ability to record with the front and back cameras at the same time?
That's not a mystery. It's that only 1 person out of a million would ever want to do that so no one is devoting their development time to integrating that feature.
Click to expand...
Click to collapse
You are pretty close minded even though I don't use that feature myself.
V-bloggers love using that feature.
But I do agree with you. AOSP is suppose to provide a clean experience
Dual Camera Support - i9505
Thank you for backing me up on this issue
MrAndroid12 said:
You are pretty close minded even though I don't use that feature myself.
V-bloggers love using that feature.
But I do agree with you. AOSP is suppose to provide a clean experience
Click to expand...
Click to collapse
The insults aren't needed.
I stated a fact. There is not enough desire for this feature for developers to devote time to coding it instead of coding something else that is more heavily requested.
If there were a strong desire for it developers would be looking to fill that need.
But there are alternate methods to getting this feature...like using touchwiz. So there aren't many devs who want to spend time coding a little used feature that is already available elsewhere. Especially one they don't intend to use themselves, and not when there are more popular mods that people are asking for in droves like gps fixes and updated kernels and theme manager fixes.
Keep insulting me if you like for telling it like it is. But this is the simple reason why this feature hasnt been widely developed.
If the OP really wants to do this on an AOSP rom, he can learn how to develop. Many many many people here learned how to code specifically to create a feature they wanted.
Skipjacks said:
The insults aren't needed.
I stated a fact. There is not enough desire for this feature for developers to devote time to coding it instead of coding something else that is more heavily requested.
If there were a strong desire for it developers would be looking to fill that need.
But there are alternate methods to getting this feature...like using touchwiz. So there aren't many devs who want to spend time coding a little used feature that is already available elsewhere. Especially one they don't intend to use themselves, and not when there are more popular mods that people are asking for in droves like gps fixes and updated kernels and theme manager fixes.
Keep insulting me if you like for telling it like it is. But this is the simple reason why this feature hasnt been widely developed.
If the OP really wants to do this on an AOSP rom, he can learn how to develop. Many many many people here learned how to code specifically to create a feature they wanted.
Click to expand...
Click to collapse
I didn't really back him up or said you were an insult.
I said that AOSP rooms should be free of non Google modifications.
But I am just telling you again that there are probably more than a million in one desiring for that feature because some people like to v-blog
Sent from my GT-I9505 using Tapatalk
Skipjacks said:
The insults aren't needed.
I stated a fact. There is not enough desire for this feature for developers to devote time to coding it instead of coding something else that is more heavily requested.
If there were a strong desire for it developers would be looking to fill that need.
But there are alternate methods to getting this feature...like using touchwiz. So there aren't many devs who want to spend time coding a little used feature that is already available elsewhere. Especially one they don't intend to use themselves, and not when there are more popular mods that people are asking for in droves like gps fixes and updated kernels and theme manager fixes.
Keep insulting me if you like for telling it like it is. But this is the simple reason why this feature hasnt been widely developed.
If the OP really wants to do this on an AOSP rom, he can learn how to develop. Many many many people here learned how to code specifically to create a feature they wanted.
Click to expand...
Click to collapse
OK, Fine your point is now made.
But just remember, at least on the Samsung series of phones, the S1, S2, and S3 did NOT have this feature, the S4 was the first phone by Samsung to have this feature, and the S5 is now officially the 'Flag Ship' phone for Samsung.
As with continued development of multi-media standards, i.e. 4K for a start now available on the Sony Experia Z2 phone for one,
the demand for ever increasing video recording features and abilities will continue to increase, so it would not really surprise me, if later
on this feature were to start appearing in later makes & models of phones down the line.
You really have to consider what % of people will even know or find out about free AOSP OS's like CyanogenMod, for one thing,
and even then what % of those people will even upgrade to such OS's.
The demand for Dual Camera Video Recording will probably go up and up amongst the general populace of phone users.
Right now the demands are other things, things like theme development, bug fixes, etc.
Having ones 'foot-in-the-door-now' so to speak, could be a worth while investment for later on.
Sure the demand NOW is very little, but if devs wait till later on to do this, then when the demands get bigger (presumably with newer
models of phones), devs will be flooded with all sorts of bugs to have to sort out on all the different OS types and versions,
- while the demand is great -, thats a lot of pressure on devs, which would also slow down development in other areas.
I think now, i have made my point. While this does sound purely like an argument just so i can gain something for myself - it's for ALL other people. I dont and cannot claim to represent what people in the world who own phones want. But logic sais that if i want this, then there are lots of people in the world who want this, just because XDA devs have not heard of such people, does not mean that they dont exist.
Besides I'm talking about being able to record video with 2 cameras at the same time, is that really such a grand feat ?,
Hell the XPrivacy program i use that XDA devs made was a Major Feat, Dual Camera support cant be THAT difficult to implement.
As for your other comments:
"But there are alternate methods to getting this feature...like using touchwiz." - well i think i already explained why i went to CyanogenMod in
the first place.
"If the OP really wants to do this on an AOSP rom, he can learn how to develop. Many many many people here learned how to code specifically to create a feature they wanted.[/QUOTE]" - Actually when i was a kid i programmed BASIC, but i have brain damage due to seizures affecting
my long and short term memory, so sorry, your claim that any OP can program is incorrect.
My Point Made
Your point made? I still don't even know what your point is.
Look, I get that this feature is important to you. But that does not mean that it's important to a large percentage of everyone else.
The Samsung AirView features are far more requested to be ported to AOSP roms but even then the demand is so small compared to the demand for things like floating windows, hover notifications, theming fixes, Knox workarounds, etc. No devs even want to tackle the AirView features, which get asked about at least once a week on the various S4 forums, because there isn't enough demand. And there's even less demand for simultaneous duel camera use.
In the years I've been here this is the first time I've ever heard of a request for simultaneous duel camera use. And I read nearly every post here nearly every day. So while I appreciate that this feature is something that's really important to you, it's just not in high demand.
And there is zero incentive to develop it now before it becomes high demand later. There's no money to be made in rom modding. If people suddenly want this feature down the road it'll get developed then. There is no early investment incentive in this. Phone modding is a hobby. Like fishing or model trains. We do it for fun, not for money.
As for the difficulty of simultaneous duel camera use...yes, it could be THAT hard to develop. It's not just an app. Something like this that controls 2 pieces of hardware at once would have to be coded into the kernel. And while kernel tweaking is fairly common, completely new kernel features are scarce because it's a very limited number of people who can do it. (And the stock kernel is closed source so it's not like the code can just be lifted from the Samsung version)
Second, once you had the ability to do it in the kernel you'd need an app that could take advantage of the support. You couldn't use the stock camera. You'd need something new. So that's a second layer of development. So this isn't a quick 1 hour project. It's a lot of hours that someone would have to put into it, for something that isn't being asked for very much.
This is the reason it's not being done yet. Don't be mad at me for giving you the honest answer.
Skipjacks said:
Your point made? I still don't even know what your point is.
Look, I get that this feature is important to you. But that does not mean that it's important to a large percentage of everyone else.
The Samsung AirView features are far more requested to be ported to AOSP roms but even then the demand is so small compared to the demand for things like floating windows, hover notifications, theming fixes, Knox workarounds, etc. No devs even want to tackle the AirView features, which get asked about at least once a week on the various S4 forums, because there isn't enough demand. And there's even less demand for simultaneous duel camera use.
In the years I've been here this is the first time I've ever heard of a request for simultaneous duel camera use. And I read nearly every post here nearly every day. So while I appreciate that this feature is something that's really important to you, it's just not in high demand.
And there is zero incentive to develop it now before it becomes high demand later. There's no money to be made in rom modding. If people suddenly want this feature down the road it'll get developed then. There is no early investment incentive in this. Phone modding is a hobby. Like fishing or model trains. We do it for fun, not for money.
As for the difficulty of simultaneous duel camera use...yes, it could be THAT hard to develop. It's not just an app. Something like this that controls 2 pieces of hardware at once would have to be coded into the kernel. And while kernel tweaking is fairly common, completely new kernel features are scarce because it's a very limited number of people who can do it. (And the stock kernel is closed source so it's not like the code can just be lifted from the Samsung version)
Second, once you had the ability to do it in the kernel you'd need an app that could take advantage of the support. You couldn't use the stock camera. You'd need something new. So that's a second layer of development. So this isn't a quick 1 hour project. It's a lot of hours that someone would have to put into it, for something that isn't being asked for very much.
This is the reason it's not being done yet. Don't be mad at me for giving you the honest answer.
Click to expand...
Click to collapse
"And there is zero incentive to develop it now before it becomes high demand later. There's no money to be made in rom modding. If people suddenly want this feature down the road it'll get developed then. There is no early investment incentive in this. Phone modding is a hobby. Like fishing or model trains. We do it for fun, not for money."
Well i think that everything i said above are _VALID POINTS_ points i would have though would have been important enough for XDA devs to consider.
It seems to me that there simply is TOO MUCH demand on the XDA devs in general.
"There's no money to be made in rom modding."
As for 'INVESTMENTS' - I did _NOT_ mention business or money making at all - I meant your investment in coding/programming, your time put into work.
"There is no early investment incentive in this. Phone modding is a hobby. Like fishing or model trains. We do it for fun, not for money."
Well, i guess i will have to turn to people i CAN pay money to, to make it more 'worthwhile' for minority's such as myself, if not a dev.
Ben.
The7Suggester said:
Well, i guess i will have to turn to people i CAN pay money to, to make it more 'worthwhile' for minority's such as myself, if not a dev.
Ben.
Click to expand...
Click to collapse
Nothing wrong with that! Try to find a group of likeminded people who want this on AOSP and put a bounty together to offer to a developer.