Hi everyone,
I bugged HMD about not releasing more recent source code for the Nokia 8 and a few days ago they updated their site with links to code for the Android 9 builds. Note they still haven't published the latest build (5.150) nor and 4.88 builds nor any Android 7.1x builds.
I checked the archives and they are different from the previous 4.84 release, but I've no idea if they are buildable. They still look like they might be missing some useful bits, from my limited knowledge. Those of you who know what to do with this can test it and see if it's useful to you.
Let me know if you would like me to keep bugging them about the 4.88 build's code, or even any earlier 3.x builds.
Have fun!
Cheers
Thanks for bugging them!
Sadly it still contains the same device tree typos that the previous NB1 and even A1N sources contained, so without fixing them those trees do build but won't work correctly as the display won't be accessed correctly (half the screen will be white IIRC).
To be clear, this is what I mean: https://github.com/resident-nokia/u...f68ad2f#diff-6ea71fa79b281dd80cbab0bea96d9472
Also, as a funfact: A quick diff I did showed that the 5140 source is identical to the 4120 kernel source from Nokia 8 Sirocco that was released around December if I am not mistaken (minus the device tree files and some places where device names were hardcoded). That would mean that our kernel hasn't seen an update since December (actually even September, since thats the first CAF tag (Qualcomm upstream) that has changes you can find in those sources). Customer service I guess ¯\_(ツ)_/¯
Hi @THMSP!
Thanks for checking it out, shame it's still got errors in it. That's very interesting about the comparison with the Sirocco and the last change being in September. I suppose a new build doesn't automatically mean a new kernel though.
Since both the Android 8 and 9 source contain errors my only wonder is if the Android 7 source would also have errors, or if it might actually work?! I will ask them for it.
Cheers
EDIT: So the device tree is there after all? I had obviously misunderstood some of the other conversations I'd read, I had always thought it was missing. So it seems the device tree is there, but broken? Or only partially there, and what is there is broken?
The device tree files are all there, but they contain four serious typos that cause them to not actually work when you boot your compiled kernel. The rest of the source code does work. Correcting those typos is not much of a deal, but it is annoying (and personally I wonder how on earth they even maintain these sources).
The other annyoing issue is that for any custom or mismatching kernel the wifi driver won't load (because of signature enforcement for kernel modules), so if you want to make a kernel that doesn't break wifi, you need to add the Qualcomm wifi driver yourself (which then requires additional patches to actually work as well).
When you do those two things, the kernel will work just like the one that Nokia is shipping. For example, my TWRP builds for NB1 actually use the kernel source code for Sirocco, but with the (corrected) device tree files from NB1, and a patched version of the qualcomm wifi driver compiled into the kernel directly.
I am not sure if the nougat sources would help that much to be honest. It's not like those sources are broken because HMD / FIH don't know how to fix them, I bet they break them on purpose (or they get broken by the tool they use to package them). So any further release by them will probably contain the same stupid errors.
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
madb1lly said:
Wow! That's a lot to do to make them usable. I agree that I have many questions about QC and QA in the software for these phones, not only because of the source code releases.
You did very well making the device tree for the NB1 then and getting TWRP running, well done! And thanks
Like many I'm interested in the possibility of running other OSes on the NB1, particularly /e/ and any that run on Halium. I presume it will still take a lot of work to get another OS running on the NB1, but is it doable? I think in all cases these projects start from a LOS base.
Cheers
Click to expand...
Click to collapse
Most of the work regarding TWRP and the kernel was actually done by @dg28gadhavi - I just tried to update everything a bit and adapt it to all the new bootloader bugs features that were introduced over time. He deserves all the credit, otherwise I would've had nothing to learn all this stuff from.
Regarding custom ROMs: Sure it is possible. But it is a huge amount of work, that requires you to risk your device (Snapdragon chips are unbrickable, but you couldn't use it as a daily driver), with potentially very few people actually caring (or even donating etc.). When you reached the point where you are able to port a ROM, you have the knowledge to make the changes that you need yourself with Magisk as well. So the only real reason to port a ROM is to give something to the community. And the Nokia 8 community simply isn't big enough that anyone would do that, imo.
Well thanks for @dg28gadhavi as well then!
Yes, I have read that Magisk can do most of what a custom Android ROM might have done. I have some reservations about Magisk, since it's not open source I don't know if I fully trust it, but that could also be the case for most of the software I use! Personally I'm interested most in /e/, which is currently built of a LOS base, but I don't know if all the customisations they've done (mainly to remove any communication with Google services) can be done with Magisk.
As for Halium-relate OSes (Ubuntu Touch, Plasma Mobile, Sailfish OS, LuneOS... some others too), Magisk can't recreate those as they're basically completely different from Android, they just run off the Android kernel and use libhybris to interface with the Bionic library drivers; the rest of Android is not used.
Anyway, this is all beyond my available time at present, so I will just have to carry on with stock Android maybe with some Magisk customisations until my phone breaks!
Cheers
madb1lly said:
I have some reservations about Magisk, since it's not open source I don't know if I fully trust it
Click to expand...
Click to collapse
Magisk is completely opensource, it has always been: https://github.com/topjohnwu/Magisk
You might be thinking about SuperSU which was / is indeed closed source
Related
Hey guys!!
I was waiting to get this awesome device but was very susceptible about AOSP
support on it.
Guess we dont have to worry anymore!!
There are developments on the github already, and guess..its codeworx again! seems he didn't give us up as of yet!We might be in for official support pretty soon!!
Will wait until it happens and get this device!
All the best dude....
Sent from my GT-S6102 using xda app-developers app
aamitabh28 said:
Hey guys!!
I was waiting to get this awesome device but was very susceptible about AOSP
support on it.
Guess we dont have to worry anymore!!
There are developments on the github already, and guess..its codeworx again! seems he didn't give us up as of yet!We might be in for official support pretty soon!!
Will wait until it happens and get this device!
Click to expand...
Click to collapse
Just seen codeworkx twitter and he insists he will never work on a samsung device so can u link to ur info?
mxn- said:
Just seen codeworkx twitter and he insists he will never work on a samsung device so can u link to ur info?
Click to expand...
Click to collapse
yes sure i can
https://github.com/CyanogenMod/android_device_samsung_i9500
see this link on their github
its Faryaab and codeworkx working on it. this is great
Faryaab got the i9500 and i9505 variants so we most definitely will see a CM build for the device.
So far looks like it's only useful for recovery. May stay that way like a lot of the Note2 repos were for quite some time.
@Entropy512
What's does the CM team actually say about using user-made device trees instead of Samsung's sources? Just saying cause I'm busy doing a bare-bone kernel and dissecting the sources, partly also merging them correctly from outside sources. You pretty much have a 90% complete commit history minus some 5410 specific parts which aren't public that get committed as some bigger chunks.
AndreiLux said:
@Entropy512
What's does the CM team actually say about using user-made device trees instead of Samsung's sources? Just saying cause I'm busy doing a bare-bone kernel and dissecting the sources, partly also merging them correctly from outside sources. You pretty much have a 90% complete commit history minus some 5410 specific parts which aren't public that get committed as some bigger chunks.
Click to expand...
Click to collapse
The closer you can get to some sort of reference branch point you can track, the better. Unfortunately for Android, tracking mainline Linux usually causes more problems than it solves.
On Qualcomms, nearly any CM device tracks CAF to some degree. It's standard procedure to find the "closest" CAF tag to a source release and then drop a manufacturer tarball on it, and I personally chunk up the tarball at least somewhat (see the Oppo find5 kernel).
Longterm goal on most Qualcomms is a rebase of manufacturer changes onto newer CAF. cdesai is doing that for Sony Xperia Z, I'll be starting that soon on find5, CM did it on the d2 family a few months ago (that one was nasty because they had to copypasta entire megachunks of Samsung code, like the camera drivers, because Samsung hacked them up so badly.)
There is no viable reference source to track for 5410 devices, which is a big problem. Tracking korg instead of CAF can often do really wonky things. (I personally never patchup from korg unless I absolutely have to - like when I patched the CM 4412 tree up so I could kang d2's wifi patches, and that was due to the d2 kernel being patched upwards.)
The github repo that you gave stands for CWM Tree.
cm 10.1 for now its not that good, because of camera features(for me a least).
but for new android comes next month thing changes
Entropy512 said:
The closer you can get to some sort of reference branch point you can track, the better. Unfortunately for Android, tracking mainline Linux usually causes more problems than it solves.
On Qualcomms, nearly any CM device tracks CAF to some degree. It's standard procedure to find the "closest" CAF tag to a source release and then drop a manufacturer tarball on it, and I personally chunk up the tarball at least somewhat (see the Oppo find5 kernel).
Longterm goal on most Qualcomms is a rebase of manufacturer changes onto newer CAF. cdesai is doing that for Sony Xperia Z, I'll be starting that soon on find5, CM did it on the d2 family a few months ago (that one was nasty because they had to copypasta entire megachunks of Samsung code, like the camera drivers, because Samsung hacked them up so badly.)
There is no viable reference source to track for 5410 devices, which is a big problem. Tracking korg instead of CAF can often do really wonky things. (I personally never patchup from korg unless I absolutely have to - like when I patched the CM 4412 tree up so I could kang d2's wifi patches, and that was due to the d2 kernel being patched upwards.)
Click to expand...
Click to collapse
I'm not working over mainline linux, I'm working over Samsung's android-exynos-3.4 branch. It doesn't contain the 5410, but it's the closest thing we've got until Linaro gets things going with the Arndale Octa.
AndreiLux said:
I'm not working over mainline linux, I'm working over Samsung's android-exynos-3.4 branch. It doesn't contain the 5410, but it's the closest thing we've got until Linaro gets things going with the Arndale Octa.
Click to expand...
Click to collapse
If that branch is far away from where your kernel source was branched from, you could be in a world of pain...
I have been working on getting a build environment to be able to see if I could build from source. I have an XT905 (basically an XT907 with different mobile frequencies), which can almost use an XT897 ROM. Just need to replace the Bluetooth and screen drivers and some build props. Anyway, I finally managed to produce a built ROM from source. So I looked into what would need to be done to bring in the CPU overclocking from @arrrghhh kernel.
Surprisingly, the higher CPU clock frequencies were already defined in the code, but turned off with a build flag. So, on my last build (and now the only one I have actually flashed), I turned the OC flag ON. And when I booted, installed Kernel Adiutor, and checked the available frequencies, sure enough they were there!
In short, I can now build an OC'd Lineage 6.0.1 ROM from Source! and anyone else can too!
Now don't get too excited, as i wont be releasing any build I do too soon (and my build is for XT905), but the source is there for anyone taking the time to build it for themselves, or if another dev wants to build it for you. I may release one in the future. But without regular releases, all would be best to stick with the official build. Even better would be to convince the official builds to include the OC option.
The real purpose of this thread is simply to let people know the option is there, and the code is there. I have been running it for the last few minutes, and unusually, it has not hit deep sleep, while my daily version hits deep sleep almost the instant the screen is off
Hey there! Any updates on this? I'd really like to help, and I have some Java/Android Framework knowledge so please tell me if you need help. Unfortunately, I can't build a ROM from source because my internet is reaaaaaally slow (100KB/s of download at much) and I don't have enough storage. I really, really want a somewhat stable Marshmallow ROM for my xt907 (I'd prefer AOSP, but LOS is vanilla enough, at least), it's my development phone and I can't upgrade to something better/newer.
BTW, do the xt897 builds boot right away in your xt905? Could you provide me those drivers (compiled) so I can try in my xt907?
EDIT: Well, they actually boot! The touchscreen doesn't work, though (that's what the drivers you were talking about are for, I suppose), I think I'll create a script that adds the necessary changes to the zip, once I find out what files need to be replaced, or are the drivers tied to the kernel?
After a month of back and forth with Barnes and Noble support and numerous references to the GPL, I think I've managed to acquire a copy of the kernel source for this tablet. It's published as a ZIP on Barnes and Noble's website. I haven't spend a whole lot of time with it, as I currently do not have the resources to build it, but from a cursory glance it seems to be reasonable, if in a weird format. I've also mirrored the source on GitLab (unfortunately, GitHub doesn't work with files over 100 MB nicely) for you guys to play with in case the Barnes and Noble link goes down or you'd like a faster download. If you see anything crucial missing, let me know and I'll try to get it fixed by pestering them to give it to me!
saagarjha said:
After a month of back and forth with Barnes and Noble support and numerous references to the GPL, I think I've managed to acquire a copy of the kernel source for this tablet. It's published as a ZIP on Barnes and Noble's website. I haven't spend a whole lot of time with it, as I currently do not have the resources to build it, but from a cursory glance it seems to be reasonable, if in a weird format. I've also mirrored the source on GitLab (unfortunately, GitHub doesn't work with files over 100 MB nicely) for you guys to play with in case the Barnes and Noble link goes down or you'd like a faster download. If you see anything crucial missing, let me know and I'll try to get it fixed by pestering them to give it to me!
Click to expand...
Click to collapse
What resources do you need. I picked up the new bn 7 tablet the other day. It's the 650 model. I have Ubuntu and superr kitchen
Edit: screen smashed...will donate the board to someone for Dev...
I have no idea what to do with it, actually. How can I do something useful with this?
saagarjha said:
I have no idea what to do with it, actually. How can I do something useful with this?
Click to expand...
Click to collapse
If we had a build of twrp, we could probably start building custom roms with this kernel I bet. I'm gonna ask B&N about getting the source for BNTV460 since that is the one I have.
A big issue that i'm having with this source is I can't figure out which defconfig to use for this device
I have recently built LineageOS 15.1 for the Nook Tablet 7" (Only st18c7bnn/bntv460) and have looked over the kernel source and found that this source code is essentially useless because it is missing the lcm code, which controls screen and touchscreen. I do not see them releasing full kernel source for this device or for the oreo model in the future as every time I've called I have had no luck getting anything from them. If anyone else is willing to try to ask for kernel source from them, please do since it is not only their legal obligation to give it with all of their modifications, but also a huge help for development. The st16c7bnn & st18c7bnn both use the same LCM, although for some reason, st16c7bnn(the marshmallow device) is 64bit while st18c7bnn(oreo) is 32bit only.
turtleletortue said:
I have recently built LineageOS 15.1 for the Nook Tablet 7" (Only st18c7bnn/bntv460) and have looked over the kernel source and found that this source code is essentially useless because it is missing the lcm code
Click to expand...
Click to collapse
So, if I'm understanding correctly you have a non-functional LineageOS? Or is it that the st18c7bnn is the only one that needs the LCM code, and it already works on st18c7bnn (if so, would you mind sharing the build)?
I'd be happy to contact them again (maybe they'll see my old ticket and redirect it to the person who handled that issue), but I would have to know exactly what to ask for because otherwise they are really slow and ask a bunch of questions.
saagarjha said:
So, if I'm understanding correctly you have a non-functional LineageOS? Or is it that the st18c7bnn is the only one that needs the LCM code, and it already works on st18c7bnn (if so, would you mind sharing the build)?
I'd be happy to contact them again (maybe they'll see my old ticket and redirect it to the person who handled that issue), but I would have to know exactly what to ask for because otherwise they are really slow and ask a bunch of questions.
Click to expand...
Click to collapse
Sorry for the long delay in response. Basically, I have an almost perfectly functioning build of LineageOS for st18c7bnn (Nook Tablet 7" 2018 Android Go Edition only), but I wanted the kernel source so I could rebuild the kernel and attempt to merge in security fixes for it. If you have the 2018 model of the device, I'll gladly send the TWRP zip of the rom to you. Seems to work fine, and imo is better than using a gsi. I still have to do more testing, but I'm currently busy with another device. I just want to have the full kernel source (which would include necessary dtb and lcm drivers) for the st18c7bnn and st18c10bnn (Nook Tablet 10.1) like the license the kernel is under should force B&N to do. Since the devices have been discontinued, I figure it's now or never for that, since the longer we wait, the more likely that Emdoor deleted the kernel source off of their machines. But any help is appreciated. Thanks
X86 Atom Android tablet BLISS ROM. Kernel source & HALS, is tha enough to get going?
I have a TX201LA tablet runs Android 4.2. Its a dual device 2 systems in 1. The tablet half is what i am focusing on. NOT the dock as I have windows 10 running fine on that half. The tablet is nearly useless as it is on android 4.2. I've been exploring a few options for getting an android update. My tablet runs an atom x86 cpu with 2GB of ram and is quad core cloevertrail CPU x2560. Plenty of power to run a newer android or even chromeOS, cloudready, or remixOS. I've explored those options but Bliss is the most straight forward as there are already x86 builds of Bliss. I think support should be relatively easy to add for my device.
There are a few caveats however I know ways to overcome them if I can get a rom to load.
1. I dont have a unlocked bootloader but I maybe able to unlock using zenfone 5 unlock method. Still no custom rom has ever been made for my tablet, only for similar devices like zenfone 5, galaxy tab 3 10.1, & dell venue 7.
2. Once I get it unlocked, I can load CWM or use flashfire. My tablet boots with Droidboot, which I can replace with CWN via again a zenfone 5 exploit that I have confirmed works with my tablet.
3. Would bliss load things like my LCD driver, touch screen etc? That is possibly the biggest issue. I have the kernel code here, UPDATED: http://support.asus.com.cn/Download....1LAF&p=3&s=587 OR here original: http://support.asus.com.cn/Download....01LA&p=3&s=587
3A. If the kernel code has all the HALS isnt it possible to build a Bliss rom that would be loaded via CWM/Flashfire and then boot-able?
3B. Could the Bliss team build a rom with the kernel code listed above, that I could then test? Or would the bliss team need to the device (I would think not, i hope). If a rom could be created I would GLADLY donate to BLISS.
Love to find out if this is possible. THANKS
madhits45 said:
I have a TX201LA tablet runs Android 4.2. Its a dual device 2 systems in 1. The tablet half is what i am focusing on. NOT the dock as I have windows 10 running fine on that half. The tablet is nearly useless as it is on android 4.2. I've been exploring a few options for getting an android update. My tablet runs an atom x86 cpu with 2GB of ram and is quad core cloevertrail CPU x2560. Plenty of power to run a newer android or even chromeOS, cloudready, or remixOS. I've explored those options but Bliss is the most straight forward as there are already x86 builds of Bliss. I think support should be relatively easy to add for my device.
There are a few caveats however I know ways to overcome them if I can get a rom to load.
1. I dont have a unlocked bootloader but I maybe able to unlock using zenfone 5 unlock method. Still no custom rom has ever been made for my tablet, only for similar devices like zenfone 5, galaxy tab 3 10.1, & dell venue 7.
2. Once I get it unlocked, I can load CWM or use flashfire. My tablet boots with Droidboot, which I can replace with CWN via again a zenfone 5 exploit that I have confirmed works with my tablet.
3. Would bliss load things like my LCD driver, touch screen etc? That is possibly the biggest issue. I have the kernel code here, UPDATED: http://support.asus.com.cn/Download....1LAF&p=3&s=587 OR here original: http://support.asus.com.cn/Download....01LA&p=3&s=587
3A. If the kernel code has all the HALS isnt it possible to build a Bliss rom that would be loaded via CWM/Flashfire and then boot-able?
3B. Could the Bliss team build a rom with the kernel code listed above, that I could then test? Or would the bliss team need to the device (I would think not, i hope). If a rom could be created I would GLADLY donate to BLISS.
Love to find out if this is possible. THANKS
Click to expand...
Click to collapse
For one, you should ask Bliss OS (x86) related questions in the Bliss OS thread: https://forum.xda-developers.com/bliss-roms/bliss-roms-development/x86-bliss-x86-pc-s-t3534657
Second, I tend to only use source dumps that maintain proper commit attribution. This is our way of giving credit where it is due (the original developers) Most of the source dumps I come across are a bunch of source code, with one commit at best titled, "initial commit" or "dump", and this to me says that there is something not trustworthy about it. I would like to see all the individual commits and changes made throughout the commit history, as this allows us to easily target changes that were made for that specific device.
If others want to go through the trouble of picking out those differences and creating a pull request with the proper attribution attached, we have no issues merging into our releases after testing.
electrikjesus said:
For one, you should ask Bliss OS (x86) related questions in the Bliss OS thread: https://forum.xda-developers.com/bliss-roms/bliss-roms-development/x86-bliss-x86-pc-s-t3534657
Second, I tend to only use source dumps that maintain proper commit attribution. This is our way of giving credit where it is due (the original developers) Most of the source dumps I come across are a bunch of source code, with one commit at best titled, "initial commit" or "dump", and this to me says that there is something not trustworthy about it. I would like to see all the individual commits and changes made throughout the commit history, as this allows us to easily target changes that were made for that specific device.
If others want to go through the trouble of picking out those differences and creating a pull request with the proper attribution attached, we have no issues merging into our releases after testing.
Click to expand...
Click to collapse
Did you look at my source to see if this is a problem? I'm not exactly sure how it needs to look but is this something you have found to be the case with other asus sources in the past? I'd be surprised if it was. I'd love to get a bliss rom for my tablet but I figured this would not be so easy even with x86 support being its base.
madhits45 said:
Did you look at my source to see if this is a problem? I'm not exactly sure how it needs to look but is this something you have found to be the case with other asus sources in the past? I'd be surprised if it was. I'd love to get a bliss rom for my tablet but I figured this would not be so easy even with x86 support being its base.
Click to expand...
Click to collapse
By the time I read your post, the links didn't work. And of the Asus source dumps I've seen in the past, they haven't included any git history
electrikjesus said:
By the time I read your post, the links didn't work. And of the Asus source dumps I've seen in the past, they haven't included any git history
Click to expand...
Click to collapse
Hey Electrik jesus, Here is the new link: https://www.asus.com/2-in-1-PCs/ASUS_Transformer_Book_Trio_TX201LA/HelpDesk_Download/
I'm from Michigan to.. So hopefully you can help another Michigander lol with a bliss build. Asus recently changed up there whole support site and the source code used to only be available on the international site now it seems its also on there US site. The Tx201LA was sold more overseas then in the US. It so similar to about 50 other devices (same Soc) asus made but mostly a lot of them are phones.
madhits45 said:
Hey Electrik jesus, Here is the new link: https://www.asus.com/2-in-1-PCs/ASUS_Transformer_Book_Trio_TX201LA/HelpDesk_Download/
I'm from Michigan to.. So hopefully you can help another Michigander lol with a bliss build. Asus recently changed up there whole support site and the source code used to only be available on the international site now it seems its also on there US site. The Tx201LA was sold more overseas then in the US. It so similar to about 50 other devices (same Soc) asus made but mostly a lot of them are phones.
Click to expand...
Click to collapse
I checked it out, and it is just as I was expecting. no .git folder or anything to show what commits were made on top of the standard kernel source. I guess the only thing we can do about it though is set an example of how to do it...
Example of how a kernel commit history could look: https://github.com/BlissRoms-x86/platform_kernel_common/commits/k4.15.10-ipts
electrikjesus said:
I checked it out, and it is just as I was expecting. no .git folder or anything to show what commits were made on top of the standard kernel source. I guess the only thing we can do about it though is set an example of how to do it...
Example of how a kernel commit history could look: https://github.com/BlissRoms-x86/platform_kernel_common/commits/k4.15.10-ipts
Click to expand...
Click to collapse
So if I understand you correctly the source code needs to be gone through to be pick out the comments etc and then it can be pulled into the bliss x86 source for merging? I think this is above my skill set, what can I do if I dont have the skills to do this?
madhits45 said:
So if I understand you correctly the source code needs to be gone through to be pick out the comments etc and then it can be pulled into the bliss x86 source for merging? I think this is above my skill set, what can I do if I dont have the skills to do this?
Click to expand...
Click to collapse
It's more of a prevention on our end from not giving attribution to the original author. Let's say that someone who worked on a linux project, got the GPU to finally work right with the chipsets in your ASUS. I would like to see that one guy's additions, but even moreso, I would like to see ASUS show that they used his work. Because for all we know, there are hundreds of commits in there that were added, and some of that could be work that someone else deserves to be reimbursed for. The fact that they removed the .git folder shows that they have something to hide. Calling it "trade secrets" shouldn't be allowed when it comes to kernel code.
electrikjesus said:
It's more of a prevention on our end from not giving attribution to the original author. Let's say that someone who worked on a linux project, got the GPU to finally work right with the chipsets in your ASUS. I would like to see that one guy's additions, but even moreso, I would like to see ASUS show that they used his work. Because for all we know, there are hundreds of commits in there that were added, and some of that could be work that someone else deserves to be reimbursed for. The fact that they removed the .git folder shows that they have something to hide. Calling it "trade secrets" shouldn't be allowed when it comes to kernel code.
Click to expand...
Click to collapse
So its about credit and royalties? I understand being upset at asus because they did not or have not credited someone but what can i do about that? Am I stuck at not being able to have my device supported because asus is a bad actor? Is there any way I can get support?
madhits45 said:
So its about credit and royalties? I understand being upset at asus because they did not or have not credited someone but what can i do about that? Am I stuck at not being able to have my device supported because asus is a bad actor? Is there any way I can get support?
Click to expand...
Click to collapse
There is, you could take the route Jakeday has for the Surface line. Since we don't know the author, he created patches to add the support needed to the kernel. It's far from the easy road, but this is what helps developers far more than any source dump
https://github.com/jakeday/linux-surface
electrikjesus said:
There is, you could take the route Jakeday has for the Surface line. Since we don't know the author, he created patches to add the support needed to the kernel. It's far from the easy road, but this is what helps developers far more than any source dump
https://github.com/jakeday/linux-surface
Click to expand...
Click to collapse
What I am confused about is this.
1. Is it a protocol thing? IE asus did not give credit and thus bliss refuses to add support unless they do.
OR
2. Is it an actual road block? IE we cant use the source code as is because it needs more information or reformatting?
Or is it both with more weight on #2?
If its #1 then can we make an exception? and if it is #2 why isnt there some sort of code AI that can redo the code to make it conform to the needed edits, seems like that should be possible. I would hope that if it is #1 only that you would admit that is all it is and help more people instead of forcing people to work around the bureaucracy brought onto them by bad actors like asus.
madhits45 said:
What I am confused about is this.
1. Is it a protocol thing? IE asus did not give credit and thus bliss refuses to add support unless they do.
OR
2. Is it an actual road block? IE we cant use the source code as is because it needs more information or reformatting?
Or is it both with more weight on #2?
If its #1 then can we make an exception? and if it is #2 why isnt there some sort of code AI that can redo the code to make it conform to the needed edits, seems like that should be possible. I would hope that if it is #1 only that you would admit that is all it is and help more people instead of forcing people to work around the bureaucracy brought onto them by bad actors like asus.
Click to expand...
Click to collapse
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
electrikjesus said:
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
Click to expand...
Click to collapse
LOL.. Pretty PLEASE, with big traverse city cherrys on top.
I have also emailed asus to see if they will look at the source code again to properly format it, not likely but worth a shot.
Does this help: https://proandroiddev.com/ooga-chaka-git-hooks-to-enforce-code-quality-11ce8d0d23cb
Is the process of going through the code very time consuming? So even if using git hooks it will take time? Im still trying to understand why there is no AI that can go through it.
electrikjesus said:
It's the third option, I'm too busy to do the work for something that is more important to you than it is to me.
Click to expand...
Click to collapse
It is important for several people. I hope at some point you have enough time to be able to help us. please help.
I am revisiting this conversation after a few months, and for starters, I would like to say I'm sorry for being rude. Secondly, I would like to use this conversation to start change where we need it. Innovation is the key point here. and if any of us are to build off of one another, we must work together to make it all possible. The lack of commit attribution by OEMs is a blatant disregard for GPL and Open Source licensing. As a ROM team, I would love to work with any OEM to help them through the process of adding a proper commit history. As Bliss, we are open to taking on any new device work, and we have in the past with Udoo-x86 & PINE64, but one of our requirements is that we can release full source, commit history, etc. Everything anyone could need to build off our work.
Too many OEM's are using patents as a way to stab eachother in the back, or use it as a "competitive" road block to stop the sale other devices that may have a similar method or feature. We don't agree with this practice and believe it is driven by greed and the wants of a few, not the needs of the majority. We as Bliss will continue to do what we can to act as an example of what should be done to best facilitate the rapid development of mobile technology and software for all parties involved.
I wonder why after roughly 3 years Still no one showing interest in developing a custom rom for our first grade phone? Before they claimed that it is on pause because no has the kernel source code, but now we have access to the official source code and yet no one developed a brand new custom rom for Nokia phone.
Please if anyone could help write a comment below.
to be honest, at this point i simply dont care whatever is happening in this community. If you have knowledge of building a custom rom then why not giving it a go?
i simply dont possess the knowledge at the same time i am also not complaining.
Ok, so first: Nokia 8 launched in September 2017. According to my calculator, thats roughly one and a half year since it came out. Not three.
Then, regarding kernel sources: The official kernel sources for our phone are from the Oreo 8.0 release. It's possible to use older kernels for newer ROMs, but it is really not recommended. And I am not even speaking of the fact that those official kernel sources still require edits to even work. There is no support from Nokia / HMD for development on this phone. Even their unlocker app doesn't work on the majority of versions and completely broke after 2 security patches.
I would be suprised if you can find any developer who is willing to spend their time fighting the stuff that gets thrown between our feet. (broken kernel source, not being able to temporary boot images and having to flash them instead, no working kernel sources from hmd, no reliable bootloader unlock, no official rescue tool etc. etc.) And usually, developers make things because their either need them themselves, or for the joy of creating something and sharing it with people who appreciate it. And when you can port a ROM, you can make the edits you want for yourself with Magisk, so reason 1 is already not applicable.
And as hard as it might sound, this community is by no means large enough to justify porting a ROM you dont need and risking your device stability / userdata in the process.
So the TL;DR; is probably: Either do it yourself, or expect it to never actually happen, as harsh as it sounds, sadly.
THMSP said:
Ok, so first: Nokia 8 launched in September 2017. According to my calculator, thats roughly one and a half year since it came out. Not three.
Then, regarding kernel sources: The official kernel sources for our phone are from the Oreo 8.0 release. It's possible to use older kernels for newer ROMs, but it is really not recommended. And I am not even speaking of the fact that those official kernel sources still require edits to even work. There is no support from Nokia / HMD for development on this phone. Even their unlocker app doesn't work on the majority of versions and completely broke after 2 security patches.
I would be suprised if you can find any developer who is willing to spend their time fighting the stuff that gets thrown between our feet. (broken kernel source, not being able to temporary boot images and having to flash them instead, no working kernel sources from hmd, no reliable bootloader unlock, no official rescue tool etc. etc.) And usually, developers make things because their either need them themselves, or for the joy of creating something and sharing it with people who appreciate it. And when you can port a ROM, you can make the edits you want for yourself with Magisk, so reason 1 is already not applicable.
And as hard as it might sound, this community is by no means large enough to justify porting a ROM you dont need and risking your device stability / userdata in the process.
So the TL;DR; is probably: Either do it yourself, or expect it to never actually happen, as harsh as it sounds, sadly.
Click to expand...
Click to collapse
I can't agree with you more, I was just wondered how this newly released phone still has no custom rom while my LG G3 still after those years received many from lots of developers.
So sad to see our beloved NOKIA has no juice to compete in this race.
error748 said:
I can't agree with you more, I was just wondered how this newly released phone still has no custom rom while my LG G3 still after those years received many from lots of developers.
So sad to see our beloved NOKIA has no juice to compete in this race.
Click to expand...
Click to collapse
We all found out the hard way what Nokia was about by being early adopters. To me they are only interested in pushing their next device and Android One is making that easier for them. So much so the 8 is long since off their radar. It was an 'OK' phone for the money, but there's better now and it's them I'll be looking to this year.
At this point its best to just modify the current stock rom yourself by debloating it, installing kernel tweking modules via magisk, installing themes via substratum and customizing the interface using GravityBox and Xposed Edge. Thats the closest we will come to having a custom rom experience. Ive accepted that no developer will bother with this phone given all the devices that have come out since its release.
Its a lesson learnt. I love this phone but I will never buy another Nokia phone ever again. Im currently saving up for a Xiaomi phone and will use this Nokia 8 as a secondary phone in due time.
MDV106 said:
At this point its best to just modify the current stock rom yourself by debloating it, installing kernel tweking modules via magisk, installing themes via substratum and customizing the interface using GravityBox and Xposed Edge. Thats the closest we will come to having a custom rom experience. Ive accepted that no developer will bother with this phone given all the devices that have come out since its release.
Its a lesson learnt. I love this phone but I will never buy another Nokia phone ever again. Im currently saving up for a Xiaomi phone and will use this Nokia 8 as a secondary phone in due time.
Click to expand...
Click to collapse
Poco or 1+ here
MDV106 said:
At this point its best to just modify the current stock rom yourself by debloating it, installing kernel tweking modules via magisk, installing themes via substratum and customizing the interface using GravityBox and Xposed Edge. Thats the closest we will come to having a custom rom experience. Ive accepted that no developer will bother with this phone given all the devices that have come out since its release.
Its a lesson learnt. I love this phone but I will never buy another Nokia phone ever again. Im currently saving up for a Xiaomi phone and will use this Nokia 8 as a secondary phone in due time.
Click to expand...
Click to collapse
Me too, my next phone would be OnePlus 6T or Oppo.
Never ever ever go around nokia phones again