I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Aou said:
I've been watching and waiting for the G900TUVU1ANCH source code on Samsung's website, but all they have available right now is G900TUVU1ANCD. Two questions:
1) How long does it typically take Samsung to release the latest version of source code after the firmware has been pushed to devices (or manufactured with said version)?
2) Are there any other avenues to obtain the source code (i.e. through carrier, via leaks, per request)?
I'm looking at trying my hand at porting native Ubuntu Desktop to the S5, but I would like to start with the current/latest kernel.
FYI, one of the reasons I moved from the S4 -> S5 was because of AT&T's ridiculously locked bootloaders, making native booting to Ubuntu Desktop or Ubuntu Touch very difficult - and impossible to make an "easy" way of switching between this and Android seamlessly (i.e. via a boot menu of sorts).
Click to expand...
Click to collapse
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
zaventh said:
Not sure about the platform source, but the CH release appears to use the same kernel sourced in the Samsung released labeled CD. They're both (rather erroneously) tagged as kernel version 3.4.0. I used the current source to build a kernel here http://forum.xda-developers.com/showthread.php?t=2729338 which works exactly as expected. I'm guessing CH was just a baseband release at this point.
Samsung has historically been pretty timely about pushing new sources, usually within a week or so.
Good luck.
Click to expand...
Click to collapse
Gotcha. If it was indeed just a baseband update or something irrelevant to the open-source parts of the firmware, then I guess there wouldn't be anything to update on Samsung's website. I'll probably stick with the *CD source and use it like you did. Thanks.
For that matter, has anyone captured the *CD -> *CH update as a .zip? Would have required root at that time to snag it, and I came into the S5 game a few days late (not sure on the sequence of events here)... In any event, if it were captured, it would tell us exactly which components were updated, and if building stuff from the *CH source is required for anything specific.
Lastly, minor updates typically don't touch the kernel, so I think you are absolutely right, @zaventh.
Related
hi guys, did HTC ever release the source code for the 2.1 update?
No. htc are bell-ends and don't even release driver source code, let alone code for their "superior" gui. Hence why it takes a while to port newer versions of android to the hero. Developers have to implement loads of dirty hacks and backports using kernel binary blobs they manage to extract from the 2.1 upgrade.
TheReverend210 said:
No. htc are bell-ends and don't even release driver source code, let alone code for their "superior" gui. Hence why it takes a while to port newer versions of android to the hero. Developers have to implement loads of dirty hacks and backports using kernel binary blobs they manage to extract from the 2.1 upgrade.
Click to expand...
Click to collapse
well thats just bad news!!
but they did afaik release source code for the kernel for many of their phones didn't they, what i would like to know is what does this mean to developers, what can they do with the kernel source?
The kernel is just a modified linux kernel, which has been open source since the early 90's.
Developers can do quite a bit with the kernel, is is basically the bridge between hardware and software.
However, despite running Debian since Etch was the latest stable release, my knowledge of the linux kernel is limited, so you would have to ask a developer for specifics.
TheReverend210 said:
The kernel is just a modified linux kernel, which has been open source since the early 90's.
Developers can do quite a bit with the kernel, is is basically the bridge between hardware and software.
However, despite running Debian since Etch was the latest stable release, my knowledge of the linux kernel is limited, so you would have to ask a developer for specifics.
Click to expand...
Click to collapse
thanks for your help
info on webkit source please..
i was at HTC's Developer Center and i noticed that HTC released the "webkit source code" for several "Sense UI" models, including the HTC Droid Eris, which very much shares our beloved Hero's specs...
i was wondering is this webkit compatible with our GSM Hero, and why didn't HTC release the webkit source for the GSM version?
the reason i'm asking is because i want to take out libwebcore.so alone and patch it, and replace the one in Hero...
Just trying to understand the game here... previously I had a Sprint Galaxy Nexus and as I understood it the entire source for the image was available and thus the devs could do a full build roughly equivalent to what an OEM would do. On the other hand with a device like my Galaxy Tab 10.1 there were certain things that were always flaky (running non-OEM roms) and the devs claimed they just didn't have the real drivers to properly support the hardware.
So what is the actual deal with the DNA? To run something like 4.1.2 what would be the procedure to generate the image? Nevermind the unlock/s-off details of actually getting it on the phone, how would you go about getting the DNA-specific drivers from the stock image and combining that with the aosp mainline? Would this involve disassembly of the stock image? Or is there a way to somehow use binary modules directly from the stock image?
Bump
Sent from my ViperVivow
from what I understand the hardest thing to get aosp (i believe thats what you were referring to in the OP?) will be cracking the RIL
[email protected] said:
from what I understand the hardest thing to get aosp (i believe thats what you were referring to in the OP?) will be cracking the RIL
Click to expand...
Click to collapse
That's what I'm trying to figure out though, what is the actual process of doing this? I'm a Windows kernel dev, so in my world if I had one Windows machine up and running I could grab the binary .sys files and copy them into another similar OS (from Vista to Win7 perhaps) and things would just work. If I were moving between two imcompatible platforms (say from Windows to OpenBSD) then I'd have to disassemble the .sys to figure out what it actually does and then rewrite something functionally equivalent for BSD. I know nothing about Android development so I'm trying to understand how all this works here. We obviously have full stock image that includes all necessary drivers for the screen, radio, etc. And we also have generic, hardware independent aosp. So how do we combine the peanut butter and the chocolate to get the Reese's?
The issue is the RIL like has been stated. The problem is that HTC Sense uses a different telephony package than AOSP ROMs so the closed source ril.so and rild.so (radio interface layer and radio interface layer daemon object files) won't work with an AOSP ROM's telephony package (telephony.jar). There also may be some other hardware issues besides the radio like the camera that are different, but the radio is the biggest one.
Mazer
Sent from my rooted and debloated Droid DNA.
So in the past with other devices, how is this bridge crossed? Would a new telephony.jar be developed to interop with the existing ril/rild binaries? Or would the ril/rild binaries be reverse engineered and rewritten to be compatible with the existing telephony.jar?
HiBoost said:
So in the past with other devices, how is this bridge crossed? Would a new telephony.jar be developed to interop with the existing ril/rild binaries? Or would the ril/rild binaries be reverse engineered and rewritten to be compatible with the existing telephony.jar?
Click to expand...
Click to collapse
The telephony binaries would be decompiled and somewhat interpreted/understood and modified (usually involves a lot of guesswork and error log reading) recompiled then tested. If the build works then it is released. Usually there'll be two preliminary builds one that just has voice/text service, one with 3g, then one with 4g (all three working.) All three are completely separate and are huge milestones.
Mazer
Sent from my rooted and debloated Droid DNA.
Thanks for your responses!
HiBoost said:
Thanks for your responses!
Click to expand...
Click to collapse
Sure thing.
Sent from my rooted and debloated Droid DNA.
Hi all,
i'm a noob to android, but i have nit of experience on other unix based systems.
I was wondering, why there is no custom roms for GT-S5690?
What's the problem?
Is bootloader locked some other way or is it somehow different from example Gio/GT-S5660?
There is a bunch of roms for gio..
I have one xcover, wich has no screen and covers, i thought i could use it for testing.
I think there are too less people who have a xcover, and I was actually pretty disappointed when I say there is a successor to the xcover available only in the US (Rugby Smart / Pro <-- with ICS!).
From the technical side, I don't know. Even the source code of the firmware is available at opensource.samsung.com. The Bootloader seems pretty much unlocked.
For me, the xcover is the best phone ever, it takes so much abuse. Maybe someday someone will port a newer ROM from the Ace/Gio/idk. It's a shame Samsung abandons their old phones :crying:
xkawer said:
I think there are too less people who have a xcover, and I was actually pretty disappointed when I say there is a successor to the xcover available only in the US (Rugby Smart / Pro <-- with ICS!).
From the technical side, I don't know. Even the source code of the firmware is available at opensource.samsung.com. The Bootloader seems pretty much unlocked.
For me, the xcover is the best phone ever, it takes so much abuse. Maybe someday someone will port a newer ROM from the Ace/Gio/idk. It's a shame Samsung abandons their old phones :crying:
Click to expand...
Click to collapse
I didn't were aware of successor models, now i'm very dissappointed.
I'm downloading these source codes at the moment, i'll check these out.
I'm not a developer, atleast YET..
AFAIK, hardware of s5690 is way different from any other samsung phones,
correct me if i'm wrong..
jonezy82 said:
AFAIK, hardware of s5690 is way different from any other samsung phones,
correct me if i'm wrong..
Click to expand...
Click to collapse
Seems like it's the only one with a Marvell MG2.
Let me know if you do anything interesting with the sources
Just flashed my xcover to XXLJ2 yesterday. At least it seems a bit faster now, but I have a weird bug when scrolling. If I give a list (for example settings) momentum, it doesn't stop when I put my finger on it again. But it does stop if I release the finger the second time.
jonezy82 said:
I'm downloading these source codes at the moment, i'll check these out.
Click to expand...
Click to collapse
Did the same. The GT-S5690_Platform.txt says:
Code:
How to build platform
1. Get android open source.
: version info - Android gingerbread 2.3.6
( Download site : http://source.android.com )
2. Remove external\webkit module in android open source which you got.
And then execute "clean build"
2. Copy files and modules to original Gingerbread source tree (overwrite)
3. build
- ./build.sh user
So wouldn't it be possible to download the JB sources, and compile them with the original kernel? Would be so cool.
Edit: It seems you need device specific binaries (drivers) since ICS. see: http://www.freeyourandroid.com/guide/compile-ics
Found a git https://github.com/manakeri/android_device_samsung_xcover, there is a
Code:
cyanogen_xcover.mk
file, this seems interesting. Apparently someone is trying to port it.
Edit2: In this git, there is also a "extract-files.sh"-file, which is neccessary to pull the proprietary files from the phone! With this I think we actually have everything we need to compile ICS/JB, like in the "freeyourandroid" tutorial.
I have never done this before, but someone must try it lol.
Oh look, there are more people who care about it!
http://www.droidevelopers.com/f338/14412-gt-s5690-opensource-kernel-available.html
Someone discovered my link and made a overclock kernel from the sources! This is so cool.
I hope we are going to see more :good:
xkawer said:
Oh look, there are more people who care about it!
http://www.droidevelopers.com/f338/14412-gt-s5690-opensource-kernel-available.html
Someone discovered my link and made a overclock kernel from the sources! This is so cool.
I hope we are going to see more :good:[/QUOTE
I own an xcover too a developer on another forum looked at some files i pulled using adb to try to port clockworkmod but no success. Told me the files i sent weren't standard android img but he would continue to look into it. Apparently the teamhacksungs goal is to port cyanogenmod for every Samsung device surely they can get it done. I've been waiting a long time to see some development for the awesome xcover
Click to expand...
Click to collapse
If its possible on the galaxy mini its got to be possible on xcover!. Ive tried to get involved and learn to port cyanogenmod but when it comes to git, repo, source tree, source code e.t.c e.t.c its a bit behond me for now.
Step in the right direction it seems. Fingers crossed
Hi all,
Now that CM is dead (RIP) and official Lineage OS for the Wileyfox Swift 2 has not yet happened, i've been looking into other alternative OS's that are compatible with the Wileyfox Swift 2 [marmite].
However i'm not seeing any that are compatible for this device (Resurrection Remix, Dirty Unicorn, LineageOS (yet) and wondered if anyone has had any experience with any other custom OS's that they know are compatible?
Thanks
There are none because there is no source code for this device. You must be patient and wait until Wileyfox releases (Before the end of this month?!) the promised Android 7.1 update, and hope they also release the source code with it.
I did several modifications to stock CyanogenOS 13.1 version for myself, but I found not worth it sharing that, since we're going to receive the new update really really soon. If the update is a disaster, or they do a OnePlus (release the update on the 31st, late in the night before the end of the month, and full of bugs), I'll consider sharing it. But until then, just wait for it.
Thanks for the update. :good::good:
linuxct said:
since we're going to receive the new update really really soon.
Click to expand...
Click to collapse
I live in hope. :fingers-crossed:
linuxct said:
There are none because there is no source code for this device. You must be patient and wait until Wileyfox releases (Before the end of this month?!) the promised Android 7.1 update, and hope they also release the source code with it.
I did several modifications to stock CyanogenOS 13.1 version for myself, but I found not worth it sharing that, since we're going to receive the new update really really soon. If the update is a disaster, or they do a OnePlus (release the update on the 31st, late in the night before the end of the month, and full of bugs), I'll consider sharing it. But until then, just wait for it.
Click to expand...
Click to collapse
Thats not true there is maybe not a source code but the chips inside the device (and drivers) are also used in other devices wich are so you can make roms for this device.
There are no roms because this phone isn't used by many peaple yet or the community isnt big at the moment for this device but we can port roms from the xiaomi redmi 3s for instance
draakwars said:
Thats not true there is maybe not a source code but the chips inside the device (and drivers) are also used in other devices wich are so you can make roms for this device.
There are no roms because this phone isn't used by many peaple yet or the community isnt big at the moment for this device but we can port roms from the xiaomi redmi 3s for instance
Click to expand...
Click to collapse
WTF? Do you think that by having same CPU means we should have the very same source code? I know there's source code for the SD430 in codeaurora, and that Xiaomi released sources for land, but that doesn't mean anything. It'd require a lot of dirty and unnecessary stuff to get it working here (it's not only about the CPU, right?), and since Wileyfox is REQUIRED to release the source code (all OEMs are) we can avoid it by just waiting patiently. From there, building Lineage will be easier, but hey, if anyone wants to do the hard job, use land-m source code and try to port it, is free to do so! :laugh:
linuxct said:
Wileyfox is REQUIRED to release the source code
Click to expand...
Click to collapse
Manufacturers need to release kernel source as it's under a GPL license, but Android itself is under the Apache License 2.0 and manufacturers are not required to release any source code. In fact the vast majority of manufacturers do not release any of their internal Android code.
And having kernel source does not magically allow you to make custom ROMs. In fact you shouldn't even need the manufacturers kernel source unless they are using some obscure hardware.
flibblesan said:
Manufacturers need to release kernel source as it's under a GPL license, but Android itself is under the Apache License 2.0 and manufacturers are not required to release any source code. In fact the vast majority of manufacturers do not release any of their internal Android code.
And having kernel source does not magically allow you to make custom ROMs. In fact you shouldn't even need the manufacturers kernel source unless they are using some obscure hardware.
Click to expand...
Click to collapse
I know, but it's better having and working with it, isn't it? I know we will need to bring up a device tree, and that it's not that easy, but starting out of a good base is better than mixing sources from other phones, at least that's my opinion.
The kernel sources are already available for a long time (slowpokes?): https://bitbucket.org/wileyfox/kernel-wileyfox-msm8937
BeYkeRYkt said:
The kernel sources are already available for a long time (slowpokes?): https://bitbucket.org/wileyfox/kernel-wileyfox-msm8937
Click to expand...
Click to collapse
Oops. You made my day man. I swear I wasn't able to find that, I had no idea they published it already, they didn't mention it on social media, and whenever I asked them on the support chat they were like "Sorry, we don't have that".
linuxct said:
Oops. You made my day man. I swear I wasn't able to find that, I had no idea they published it already, they didn't mention it on social media, and whenever I asked them on the support chat they were like "Sorry, we don't have that".
Click to expand...
Click to collapse
Because I do not think that the public (where most users are not geeks, probably) will be interested in the post that the developers have released the source code of the kernel. Or someone beforehand, before closing Cyanogen Inc, released the source code for the kernel. And support is usually not answered to such questions, because they do not have such information.
But in any case you need the information you need to find in all available ways.
Hello!
I have been following annual Google I/O 2017 and heard about all the benefits of Google's Project Treble.
I cannot help but wonder how are developers (for example here at XDA) able to create custom roms or unofficial Android updates. Why Google can't make official Android Nougat update for Nexus 7 2013, but you here at XDA can. What is different between your work and Google's when it comes to these things, as far as neither has access to hardware manufacturer's code support.
I have to say I am not a professional software developer, so I understand if this topic is beyond my comprehension.
Thank you!
"Why Google can't make official Android Nougat update for Nexus 7 2013"
Planned obsolescence.
"neither has access to hardware manufacturer's code support"
Google is obliged to release kernel source code because Linux(the kernel powering Android) is released under the GPL. The kernel is responsible for letting Android "talk" to the hardware. Developers at XDA can then modify the open-source kernel to "fit" newer versions of Android.
I'd like to chime in on this.
Let's use the Nexus 7 2013 as an example. The difference between what an official build of Nougat from Google would be and what a build of Nougat from XDA is that the Google released one will have updated devices drivers that are made specifically for Nougat, while the XDA released one simply uses the older device drivers and hope they work. In some cases they work flawlessly (mostly on Nexus devices), however other times there are things that don't work so they either need to be disabled or worked around. So essentially a Google released OS has everything updated and tested to work with the new OS, while XDA releases are more 'hacked' together to work (simply because the device drivers aren't Open Source). Google may not have access to the hardware drivers, but they still get them updated.
Now let's touch on Project Treble (and why I am so excited about it). Instead of each and every device driver needing to be upgraded and tested for each new OS version, the OS version will specify which version of the drivers (HAL's) will work with the OS. This means there will be a separate space where all the device drivers will reside, and the OS will simply load those when booting (no more proprietary binary blobs to include in the ROM! hopefully...).
This means on any Project Treble compatible device (all phones that ship with Oreo, and some that update to Oreo) with an unlocked bootloader, a user can simply compile AOSP and flash it directly to the device with no modifications and have the device work. I believe this is actually a requirement to pass Google's certification process for new devices with Oreo. That means, say, with the LG v30 if the bootloader is unlocked, there can be an AOSP ROM on day one of its release.
So instead of Android being strictly a per device compile, it is just a general compile (sans device specific features). However, this doesn't remove the old driver issue. If the drivers in their respective partition no longer are updated by the manufacturer, the later AOSP code will need to be modified to work around these (and accept them). This is still easier in my opinion than the binary blobs.
As for official updates, Project Treble allows device hardware manufacturers to work on updating the device drivers while the OS Dev (Samsung, etc) works on updating their OS. So it is a parallel development instead of a serial one (hardware AND os instead of hardware THEN os).
A question.
Do the Nexus 5X devices have the Treble system or project incorporated with Oreo?
I do not understand the other manufacturers that cheaper excuses are giving, it is true that they are not obliged but I think it would be good practice, maybe they think as before that you will not buy them a phone.
Does someone make a Change.org or similar campaign to ask all Android manufacturers to make a minimum effort?