Database Develop

[Q] Is gingerbread(Android 2.3) coming to the Galaxy S I9000?

Roms based on froyo or gingerbread?
The discussion in the thread "30/Jun r1 (JFB) - MoDaCo Custom ROM for Samsung Galaxy S with Online Kitchen" is a bit confusing so I thought it best to make it a new topic to get it straight.
Will it be possible to make roms based on froyo, gingerbread or any other coming android version, before Samsung makes an update? As I understand psychoace it will be ”near impossible to get roms from other sources like Sense roms or Froyo”. Others are not so sure.
This is important as Samsung is known for its lack of interest in OS updates. Who knows if they will take gingerbread to GS? If they won't can it be done by the really smart guys?

I don't think even HTC will update there top line to V3 (ginger bread). Froyo is coming any way to GS in near future. Now ginger bread should be possible too as GS is power full enough to run. When? we should wait and see. Nexus just got updated to 2.2.
Will see how things go in future.

Samsung has released there kernel sources and there software sources. I haven't had a chance to look in to it deeply but if it has the code of the drivers etc.. it should be possible to merge (with some work obviously) sources and to compile froyo.

kimatrix said:
Samsung has released there kernel sources and there software sources. I haven't had a chance to look in to it deeply but if it has the code of the drivers etc.. it should be possible to merge (with some work obviously) sources and to compile froyo.
Click to expand...
Click to collapse
But don't those drivers only work with 2.1 and just simply won't with any version higher unless samsung releases new source and drivers for 2.2 and then 3.0. So if say samsung never releases anything any source/drivers that work with 3.0 then you would be out of luck to actually get everything to work.

MrDSL said:
But don't those drivers only work with 2.1 and just simply won't with any version higher unless samsung releases new source and drivers for 2.2 and then 3.0. So if say samsung never releases anything any source/drivers that work with 3.0 then you would be out of luck to actually get everything to work.
Click to expand...
Click to collapse
That is true but if you have the full sources you are able to look what the differences are and maybe patch those by your self. Assume a wlan driver is using an function that has changed or is gone in 2.2, then you can try to patch that by finding the new one for it to work with. If you don't have the sources it's much harder to do those kind of things.
As I sad you have the sources so you can play by your self even if samsung does not do anything. It does not mean it's easy and it does not mean it can be done fast. But it does mean it could be done.

kimatrix said:
That is true but if you have the full sources you are able to look what the differences are and maybe patch those by your self. Assume a wlan driver is using an function that has changed or is gone in 2.2, then you can try to patch that by finding the new one for it to work with. If you don't have the sources it's much harder to do those kind of things.
As I sad you have the sources so you can play by your self even if samsung does not do anything. It does not mean it's easy and it does not mean it can be done fast. But it does mean it could be done.
Click to expand...
Click to collapse
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.

psychoace said:
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.
Click to expand...
Click to collapse
Can they be decompiled and made to work? Of course!
Will someone be motivated to do all this work? Unknown.
Besides drivers arent the only issue to getting a new version of Android on a phone. If you dont have source for any proprietary userland daemons/apps (like radio?) that communicate with the hardware you will be SOL on that as well.

MMMMMMMMM if we can do it for the G1 we can do it SGS...the question is when and how much work. The Galaxy S will be Samsung's flagship device for A YEAR so I'd hope to get Gingerbread...unless Samsung are really stupid. Especially with a lot of US launches, they'll be able to relaunch with Gingerbread as it comes is my hope.

psychoace said:
But the video drivers are already compiled. Can they be easily decompiled? It's not a source file if it's already compiled.
Click to expand...
Click to collapse
Who told you that??? The source code of the GPU as well as every other coprocessor is there.
The two .o file that started this all fiasco are ok and you as long as the make file include them in the build they would work perfectly.
All they have inside is a simple elf code to tell the s3c*** to do whatever it needs to do. A source code wouldn't have been beneficial as it would have to be compiled differently for a different ARM instruction set .

kitsune223 said:
Who told you that??? The source code of the GPU as well as every other coprocessor is there.
The two .o file that started this all fiasco are ok and you as long as the make file include them in the build they would work perfectly.
All they have inside is a simple elf code to tell the s3c*** to do whatever it needs to do. A source code wouldn't have been beneficial as it would have to be compiled differently for a different ARM instruction set .
Click to expand...
Click to collapse
But when you need drivers for 2.2 the source code would be optimal because these drivers are not going to work without some hacking.

They are going to work as they are non kernel bound ELF files.
Guys this isn't a driver ,if it was a kernel module ( or "driver" s you call it) it would have been a .ko file and had a slightly different structure ( use readelf on a kernel module and then on this to see the difference). So no matter what it is when can use the compiled version as it not kernel bound
From quick inspection it seems like the injection code for the s3c*** . so basically its there so the kernel could reference to it when the code tells it to do so . So Basicly all we have to do is put it in the proper place when building the kerne.
So please DON'T PANIC

well the TP2 just got 2.2 FroYo (2.1 has more working drivers ATM).. but if we have it, how would it be different for the SGS to get FroYo?

You need to remember that while other companies can update kernel quite easily ( all the work is done for them by the chip manufacturer and some member of the community ) this isn't possible here as this is a chip only used in one android/other linux platform device and the company making the device also make the chip.
So give them a few weeks to work on it

J-Hop2o6 said:
well the TP2 just got 2.2 FroYo (2.1 has more working drivers ATM).. but if we have it, how would it be different for the SGS to get FroYo?
Click to expand...
Click to collapse
let's just say it will be the first time a non Samsung Rom has worked on a Samsung Android phone.

psychoace said:
let's just say it will be the first time a non Samsung Rom has worked on a Samsung Android phone.
Click to expand...
Click to collapse
Not true.
Look here: http://forum.samdroid.net/f28/lkmod-v-2-5-1-based-jce-en-upd-03-30-a-336/
I see a custom ROM made for the i5700
Everything is possible.

clubtech said:
Not true.
Look here: http://forum.samdroid.net/f28/lkmod-v-2-5-1-based-jce-en-upd-03-30-a-336/
I see a custom ROM made for the i5700
Everything is possible.
Click to expand...
Click to collapse
Did I say custom rom? No i said specifically non samsung based roms on a samsung device. That custom rom is based off of a Samsung rom.

This is the closest we have got to a Hero rom on a Samsung device.
http://androidforums.com/all-things-root-behold-2/60408-port-htc-hero-behold-2-wip.html
He couldn't get Rosie to boot so who knows what other problems he would of had after that (from the picture you can see he never got any network connection)
So there don't say I didn't give you any hope.

Froyo is offical. That's good, but we need to be looking past it to Gingerbread.
Froyo is announcedm confirmed, and now dated for the end of September, and that's great. But to me, that's not the question we need to be asking Samsung anymore, we need to be thinking past that.
The question people need to be asking Samsung, so we can get them on the record committed to it now, is will you release a Gingerbread update for the phone as long as the hardware is capable of supporting it. The OS is only 2-3 months from being unveiled if Google sticks to their time table, and if the rumors are true it'll be a much bigger overhaul than 2.1-2.2 is.
So unless we want our phones to be outdated before the end of the year, we need to start making a push as a community to get a commitment from Samsung to support not just the OS that was released 4 months ago, but also the much bigger one that's right around the corner.

2.2 is good.. proves everyone wrong who said "ooh its Samsung, of course they won't release Froyo."
but somehow, I doubt that samsung will somehow not upgrade SGS to 3.0. If they do, it might be a few months (at least) after everyone else gets it. The reason is, they could have new flagship devices out that they wanna push to the mass-markets, so putting gingerbread on that will boost the sales.
However, considering that they marketed the SGS so well, and have it well on its way, they might just put gingerbread on it
seriously, i see ads for SGS EVERYWHERE online.

mjgunn said:
[....]
So unless we want our phones to be outdated before the end of the year
[....]
Click to expand...
Click to collapse
I totally expect that my phone will be outdated by then. That's a consequence of the world we live in But then again, i'm a nihilist

[Q] lima drivers for mali 400 GPU

A question to the "pro":
Do you think the lima drivers, scheduled to be release next week after FOSDEM in Brussells, will be of some interest for our SGS2, running a mali 400 GPU ?
This project is open source drivers ARM Mali 200/400 from reverse-ingeenering.
http://limadriver.org/
http://www.phoronix.com/scan.php?pag...tem&px=MTA1MjQ
http://www.codethink.co.uk/
Any opinion on this?

Moved To Q&A​
Please post all questions in the Q&A section​

It probably won't be of general interest for a long, long while as it seems it's not even actually functional yet. And there are multiple devices with Mali chipset already out in the wild so getting the binaries for use with custom ROMs isn't really a huge issue.
Of course in the future having open-sourced drivers will be quite beneficial in the sense that it'll be even easier to do custom ROMs, and the open-source drivers could possibly be faster than the proprietary ones if the devs manage to optimize them well. It remains to be seen, though.

WereCatf said:
...there are multiple devices with Mali chipset already out in the wild so getting the binaries for use with custom ROMs isn't really a huge issue.
Click to expand...
Click to collapse
Sorry if this is hi-jacking the thread a little, but I'm interested in this area myself. The binaries (which I assume are like hardware drivers?) for hardware like the mali, they are the .ko files? Are the .so files needed too? I've got mali.ko and mali.so files on my devices stock firmware. Apparantly there's newer mali drivers out and I wanted to try to put them in a rom for my device that doesn't have an updated fw yet.
Would appreciate any help with this. Thanks

Once official ICS is out, wht's involved for camera fix

Anyone know what's needed to get the camera fixed once Samsung releases the official ICS ROM over the next few days? Does the kernel have to be re-compiled with a driver for the camera, or do you just drop in a drive file and presto, it works?

harry_fine said:
Anyone know what's needed to get the camera fixed once Samsung releases the official ICS ROM over the next few days? Does the kernel have to be re-compiled with a driver for the camera, or do you just drop in a drive file and presto, it works?
Click to expand...
Click to collapse
Once they get a work able ROM to kinker with it should be a just taking apart the driver

What does that mean, taking apart the driver. Is it a file? And if so, why do they have to take it apart rather than drop it where it goes?

Half the problem we have is that current ICS ROMs use an old kernel because we dont have a Samsung ICS kernel and no one has created fully custom one. Its really holding back the AOSP and AOKP ROMs, and its why they are slow in real usage. The camera drivers in the old kernel are probably not compatible with ICS.

rovex said:
Half the problem we have is that current ICS ROMs use an old kernel because we dont have a Samsung ICS kernel and no one has created fully custom one. Its really holding back the AOSP and AOKP ROMs, and its why they are slow in real usage. The camera drivers in the old kernel are probably not compatible with ICS.
Click to expand...
Click to collapse
Samsung today released the source code for ICS on galaxy tab 2 of 7 and 10 inch. Does this help for complete builds of aokp and aosp?

Galaxy Tab 2 has different SoC, so i don't see how this will be useful for us.

[Q] Building / porting for a "unusual" device

Good Afternoon, people.
I am brazilian and I have a smartphone that did not get into US and European market. It's name is "Motorola D3" and the number associate to it is "XT920".
Motorola Brazil were suposed to provide de newest rom for this device (marketing promissess). It took they almost 1 year to launch the Android Kitkat version 4.4.2.
The problem is: We want the Cyanogenmod in our device and all the newest ROM's.
That been said, I start to study to try yo port or Build a AOSP ROM to XT920 and, therefore, a CM11.
No threads on "how to port / build" a rom for a New device went trhough this problem. This device runs as a Mediatek MTK6577. I've seen that the kernel for this processor was released, but I don't know how to handle the kernel with the device and ROM properly.
Another doubt is: what is the difference between port and build a ROM? I've seen videos of porting and building and it is not clear to me.
I have reached the point where I have to download the drivers, but, in the tutorial the person was dealing with a NEXUS, wich is much easier to build, since it have a native android support.
Anyway, I want to keep this project going, and I really need some help with this questions.
Thankyou

digo_santista said:
This device runs as a Mediatek MTK6577.
Click to expand...
Click to collapse
You're screwed. MTK devices are extremely nightmarish to work with. Their kernel source is a mess and the platform source is an even bigger mess.
Even people who have had access to a complete OEM source code tree for an MT6589 device didn't succeed in getting the hacks to play nice with an AOSP source tree.
Android One has helped somewhat with devices that are released as part of the One program, but non-One MTK devices are still a nightmare.
The process of doing an AOSP bringup for a new device isn't particularly well defined because it is different for every device in existence. The only way to learn is by doing.
It helps a lot if a device with a similar chipset to yours is supported by whatever project you're trying to work with - for example most mid-to-high-end Qualcomm chipsets are not very difficult to work with. But MTK devices were nearly impossible to support with AOSP-derivative projects prior to One, and even after One, it seems like only Android One devices are "clean" enough to leverage Google's improvements to MTK support.

:/ should I waste more time or just drop it?
Entropy512 said:
You're screwed.
Click to expand...
Click to collapse
What should I do? I just quit without trying? I understand that this is a huge problem. But, if I decide to take the chalenge, is there a chance to succeed?
I am trying to figure this out and I didn't found an answer to this question: can I use the kernel that is packed with my stock ROM (provided by motorola) to build or port a CM11 ROM?
Sorry to bother, but I is really keeping me up at night
Regards,
Cassio Rodrigo

Nexus 6 Kit Kat Possible?

This probably sounds like a crazy question, but wondering whether it would be possible to build/run AOSP 4.4.4 on Shamu?
The factory firmware for Shamu is 4.4.4, so it should be possible afaik.
The only reason I can think of for why it wouldn't work is proprietary binaries, as 5.0 are the earliest available.

Q9Nap said:
This probably sounds like a crazy question, but wondering whether it would be possible to build/run AOSP 4.4.4 on Shamu?
The factory firmware for Shamu is 4.4.4, so it should be possible afaik.
The only reason I can think of for why it wouldn't work is proprietary binaries, as 5.0 are the earliest available.
Click to expand...
Click to collapse
Factory firmware for Shamu was 5.0. Thats what it shipped with. Their was never a 4.X for Shamu.
As for 4.4.4, anything is possible. Will you be able to find a dev willing to work on it? Most likely not. Makes no sense other than the challenge of it. Might be a project you can take up yourself if you like. There are tons of tutorials, information, and devs around to give advice.

Q9Nap said:
This probably sounds like a crazy question, but wondering whether it would be possible to build/run AOSP 4.4.4 on Shamu?
The factory firmware for Shamu is 4.4.4, so it should be possible afaik.
The only reason I can think of for why it wouldn't work is proprietary binaries, as 5.0 are the earliest available.
Click to expand...
Click to collapse
sure, its possible.. do you havd a kitkat driver for the n6 to make it work? if not, then itll never work. btw, google never released the drivers.

christianpeso said:
Factory firmware for Shamu was 5.0. Thats what it shipped with. Their was never a 4.X for Shamu.
As for 4.4.4, anything is possible. Will you be able to find a dev willing to work on it? Most likely not. Makes no sense other than the challenge of it. Might be a project you can take up yourself if you like. There are tons of tutorials, information, and devs around to give advice.
Click to expand...
Click to collapse
Yes, Shamu shipped with 5.0, but there is a 4.4.4 factory firmware file that is available for use by repair centers.
I've tried it, and it is a very minimal build. It isn't worth using as a daily driver at all.
I'm sure I could repo sync and compile aosp 4.4.4, but I don't want to take the time and effort if it won't work lol.
Besides the lack of 4.4.4 proprietary binaries, there is also no official 4.4.4 kernel source, so I'm basically wondering if it could work with 5.0 proprietary binaries and kernel source?

simms22 said:
sure, its possible.. do you havd a kitkat driver for the n6 to make it work? if not, then itll never work. btw, google never released the drivers.
Click to expand...
Click to collapse
Right, the lack of 4.4.4 drivers and kernel source are my main concern as far as whether it would work.
I'm wondering whether it would be possible to extract the necessary driver files and kernel from the factory buid?

Q9Nap said:
Right, the lack of 4.4.4 drivers and kernel source are my main concern as far as whether it would work.
I'm wondering whether it would be possible to extract the necessary driver files and kernel from the factory buid?
Click to expand...
Click to collapse
theres no kitkat driver, period. if there is, google has it. no, you cant extract a past driver from a newer os.

simms22 said:
theres no kitkat driver, period. if there is, google has it. no, you cant extract a past driver from a newer os.
Click to expand...
Click to collapse
I have a 4.4.4 pre-release build from Motorola; would it be possible to extract the drivers and use its kernel/boot image?

Pre-release build of what from Motorola? Unless that pre-release build is specifically for the Nexus 6, you won't be able to use its kernel with the device.

*removed*

Q9Nap said:
I have a 4.4.4 pre-release build from Motorola; would it be possible to extract the drivers and use its kernel/boot image?
Click to expand...
Click to collapse
nope. drivers are very device specific. it has to be a nexus 6 driver, or you will not get any of the software to work with the hardware and with the physical device.

simms22 said:
nope. drivers are very device specific. it has to be a nexus 6 driver, or you will not get any of the software to work with the hardware and with the physical device.
Click to expand...
Click to collapse
Ok, I'll say it again; I have official 4.4.4 Motorola firmware for the Nexus 6. See the build.prop in the previous post.
Is it possible to extract the drivers and kernel from this and include in AOSP 4.4.4?
It is factory test firmware and isn't really viable to use as a daily driver, which is why I want to use parts from it to build AOSP.

Q9Nap said:
Ok, I'll say it again; I have official 4.4.4 Motorola firmware for the Nexus 6. See the build.prop in the previous post.
Is it possible to extract the drivers and kernel from this and include in AOSP 4.4.4?
It is factory test firmware and isn't really viable to use as a daily driver, which is why I want to use parts from it to build AOSP.
Click to expand...
Click to collapse
you can try, thats the best that i can say..

As @simms22 already said, you can try it. However, according to the build.prop, ro.product.model is an XT-1080,which is a Droid Ultra. The hardware for the Droid Ultra is completely different from the N6, with specs more applicable to a Samsung Galaxy S3, and thus its drivers and kernel will both be different. Neither will work on the Nexus 6.
I'm sorry, but I highly doubt this is a genuine Nexus 6 pre-release ROM. Posting the build.prop is insufficient proof, as the build.prop can be easily edited to have it say whatever you choose. You'll have to find another way to persuade the audience.

I'm not trying to persuade anyone, lol. I'm just asking whether it's theoretically possible or not.
You are welcome to have access to the full firmware if you like, sheesh.
Why would I bother faking a build.prop?

It's not, as the Droid Ultra hardware is totally different. As to why anyone would want to fake a pre-release ROM, your guess is as good as mine. But at least you provided something when asked, unlike one guy in the S4 forums who claimed he could reset the Knox efuse after it was tripped, something not even Samsung can do.

Strephon Alkhalikoi said:
It's not, as the Droid Ultra hardware is totally different. As to why anyone would want to fake a pre-release ROM, your guess is as good as mine. But at least you provided something when asked, unlike one guy in the S4 forums who claimed he could reset the Knox efuse after it was tripped, something not even Samsung can do.
Click to expand...
Click to collapse
This is not for droid ultra. Yes, one line in the build.prop says xt1080, but everything else says shamu. Apparently, xt1080 was the working model number during testing.
For you and any other doubters, here ya go:
https://drive.google.com/file/d/0B-53iD-71B3iMElKNWdybC1aanc/view?usp=sharing

Wow, this thread is hilarious.
First off, there is no such thing as a driver that is linked specifically to a version of Android. The driver is between LINUX and HARDWARE.
While newer versions of Android may be more demanding of the kernel, they are not intrinsically tied together. You can run Android 2.0 on Kernel 4.6 if you want. Nothing is going to stop you from doing that.
Now the place where you could run into some stickyness, is in the **hardware abstraction layers**. These are not the drivers. These are the bits of code that talk Android API on one side, and Linux on the other side. Most of the HALs are open source, so could be converted if need be.
Most of the HAL changes are things being added into the new versions that didn't exist in the old. As a result, in most cases, you could take a 5.0 HAL and stuff it into a 4.4 system image -- and it should work.
But the big question is.... why would you ever want to do that? 4.4 is obsolete and dead. LEAVE IT BE!

doitright said:
Wow, this thread is hilarious.
First off, there is no such thing as a driver that is linked specifically to a version of Android. The driver is between LINUX and HARDWARE.
While newer versions of Android may be more demanding of the kernel, they are not intrinsically tied together. You can run Android 2.0 on Kernel 4.6 if you want. Nothing is going to stop you from doing that.
Now the place where you could run into some stickyness, is in the **hardware abstraction layers**. These are not the drivers. These are the bits of code that talk Android API on one side, and Linux on the other side. Most of the HALs are open source, so could be converted if need be.
Most of the HAL changes are things being added into the new versions that didn't exist in the old. As a result, in most cases, you could take a 5.0 HAL and stuff it into a 4.4 system image -- and it should work.
But the big question is.... why would you ever want to do that? 4.4 is obsolete and dead. LEAVE IT BE!
Click to expand...
Click to collapse
This is the kind of response I was looking for, thank you!
Yeah I know KK is obsolete; the main reason I am interested, besides theoretical curiosity, is the holo dark ui; really don't like the bright material white ui, and the material dark ui doesn't look that great either.
I know I can use cmte, layers, or substratum to install a dark ui theme, but I haven't found a theme yet that doesn't have issues and/or inconsistencies, and they don't look as good as og holo dark imo.
Anyway, it definitely sounds like more trouble than it's worth, lol.