Database Info

Debian instead of android... can it be done?

I have been a linux user for years, love it. so when i heard about android i bought a g1 as soon as i could... and honestly i HATE the java base... it sucks. For a while ii have been using debian on my sd and i think i have found a way to read ( but not send ) texts from within debian. any chance of developing debian to the point where we could use it as the primary system ? can the g1 g1 boot loader load it ?

No.........

damageless said:
No.........
Click to expand...
Click to collapse
Thanks ****, how about some reasoning or logic ? nothing cannot be done it is just a matter of how much effort is required to achieve the desired result.

modem_over said:
I have been a linux user for years, love it. so when i heard about android i bought a g1 as soon as i could... and honestly i HATE the java base... it sucks. For a while ii have been using debian on my sd and i think i have found a way to read ( but not send ) texts from within debian. any chance of developing debian to the point where we could use it as the primary system ? can the g1 g1 boot loader load it ?
Click to expand...
Click to collapse
Yes.
Seriously.
I haven't looked at Android in ages, but regardless - debian is just a packaging and deployment system. It has little to do with the actual code and configuration of what is deployed in the end. It's work, but it's trivial work.
As for your disdain for the Java - how about some elaboration there? Do you really think you feel a performance hit?

i do really feel that java does slow the system down for one, and second, i don't want to learn another language...

...
no..............

yes, the bootloader will load it just fine.
i have played with nothing but debian on my phone... although, it's fairly useless.
until someone reverse engineers some way to talk to rild and control the wifi module and its userspace components you're pretty much tied to the java environment if you want... well, anything but a fancy embedded debian computer.
anyway, initramfs-tools package is your friend, as well as the android development environment. the bootloader will load the kernel + initramfs, and from there the sky (and linux) is the limit.

and i had to comment on the java performance... seriously, does anyone doubt that there is a *huge* performance hit? while a register based vm is fancy and fairly efficient as far as non JIT vm's go, it's still ridiculously slow and wasteful for the operating specs of this machine. 96mb of usable ram? dalvik forks off separate processes for each vm instances, so not only do you incur major pain for the COW operation, but enough changes in the working set to almost eliminate any helpfulness of COW. it's confusing as the point of zygote is to have a basically mostly started vm, but i'm not entirely sure how that's working in the background.
FWIW, when you clock this beast up to full CPU spec speed (528mhz) interface responsiveness doubles in fluidity.

Of course there is a huge performance hit, few people saying no are google's blind lovers.
Im sorry for this useless post..

The issue to me is the time it would take to develop debian to full working capacity with all the hardware. Possible? Yes. Fun? Depends on who you ask. Probability high for it to be actually completed better than Android? Doubtful.
JMO

i agree with you in most points, however, there are already standard non-android mobile linux stacks. the only hardware specific areas that need to be addressed are the wifi and telephony libraries.
the graphics are simple, it's a standard linux framebuffer, and an x server will run directly on it. if that's too heavy for the g1 (likely) directfb can also be used.
in the end - will it be better than android? probably not. too much development has gone into android.
will standard native apps utterly outperform android apps? believe it.
though, without either: a port of an x server to interface with surfaceflinger, or: a modified version of surfaceflinger to talk to an x server running on the framebuffer, you will never get the best of both worlds without some intermediate transport like vnc.
i'm in no way an advocate of 'debian only!' however, the poster of this thread was smacked down by some people who obviously had no real knowledge in the matter, so i sought to inform him.
the better direction i think, is someone to write a nice tight little c api for the binder surface flinger interface so people can start writing some more memory conscious native apps for people with rooted phones. streaming daemons, etc. while i think the stock development capabilities of the android platform is much better than the stock iphone's, a jailbroken iphone is 100% cooler than a jailbroken g1 at this point, but once there is enough community drive - that can change.

Booting into debian primarily which then runs android ontop of it should be possible, and then using android for things until more is developed on debian. Should work.
Still the original post was more about strictly debian only.

modem_over said:
Thanks ****, how about some reasoning or logic ? nothing cannot be done it is just a matter of how much effort is required to achieve the desired result.
Click to expand...
Click to collapse
Temper tantrums aside, if you knew the answer to your question already what's the point of this thread? There's already a thread for people running debian on their G1, ask it there.
http://forum.xda-developers.com/showthread.php?t=444419&highlight=debian

nolageek said:
Temper tantrums aside, if you knew the answer to your question already what's the point of this thread? There's already a thread for people running debian on their G1, ask it there.
http://forum.xda-developers.com/showthread.php?t=444419&highlight=debian
Click to expand...
Click to collapse
Guess he can't now - been banned. Shame, too, I am sure we'll miss his pleasant demeanor.

davecanada said:
Yes.
Seriously.
I haven't looked at Android in ages, but regardless - debian is just a packaging and deployment system. It has little to do with the actual code and configuration of what is deployed in the end. It's work, but it's trivial work.
As for your disdain for the Java - how about some elaboration there? Do you really think you feel a performance hit?
Click to expand...
Click to collapse
OMFG yes there is a performance hit.

Yes i do bring certain special qualities to this forum don't I. at any rate i have began to build a port to be able to run directly off the jf bootloader.
vettejock99 said:
Guess he can't now - been banned. Shame, too, I am sure we'll miss his pleasant demeanor.
Click to expand...
Click to collapse

Yes i do bring certain special qualities to this forum don't I. at any rate i have began to build a port to be able to run directly off the jf bootloader.
Click to expand...
Click to collapse
cool i can't wait to try it out

modem_over said:
Yes i do bring certain special qualities to this forum don't I. at any rate i have began to build a port to be able to run directly off the jf bootloader.
Click to expand...
Click to collapse
Cool - that sounds great

modem_over said:
Yes i do bring certain special qualities to this forum don't I. at any rate i have began to build a port to be able to run directly off the jf bootloader.
Click to expand...
Click to collapse
any bootloader will work. there is no verification done by the bootloader during the bootstrap process, only during the flash process. flashing of the modified boot image with a debian initramfs instead of an android initramfs can be done from a functioning rooted android os, or from a test-keys enabled recovery partition. the method i used was to do a normal debian install on a partition of the sd card, installing initramfs-tools, building an initramfs, built a new boot.img with the stock android dev environment.

i've also compiled a kernel with full namespace support and a custom init that launches the android init and debian inits in separate namespaces allowing them to run concurrently. not much use since they can't talk to each other, but it is somewhat neat. virtuozzo like containers on your g1 =)

Strip it down and Make it Work

Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.

thebeastglasser said:
Hey, I'm a noob, let's get that out of the way first.
Alright, so I'd like to know, why is it so hard to get special ROMs working on certain devices?
For example, I have an Evo 3D (HTC Evo V 4G, whatever), so why is it so hard to get, say, stock ICS running on it?
Inthe end, isn't the hardware all the same, other than say processors and screen size? To get a stock ICS ROM working, couldn't you just pull it off of a similar phone with an S3 processor and a 4.3 inch screen?
Or is it not that simple? Are different codes baked into the hardware that make it impossible to just modify the pixel density, size of the screen and have the ROM work with the processors?
I understand the cameras are different, hence cameras not working on early builds of CM9... but considering many phones run the same processors, couldn't they just all work?
Please explain... thanks, thebeastglasser.
Click to expand...
Click to collapse
Is not that easy! I'm an EVO user/rom porter and I hear this alot where users such as yourself think is an easy process BUT is not. Same processor, same screen size maybe the same BUT at times the kernel is not there. Either the kernel for the device doesn't support ROM A or ROM B and therefore it can't be ported to whatever device or the libs keep it from running half way decent.....i.e WiFi doesn't work, sound is **** up or whatever the case maybe...just not functional to say the least.
Take for example Sense 4.0 on the One V....it was ported to the EVO4g and the ROM barely works! Both the One V and the EVO4g have similar hardware but one runs Sense 4.0 like a dream and the other one struggles with simple things like WiFi and Sound.
Now I'm sure someone else with a bit more knowledge on this can get into the specifics and the why's and what's of WHY this can't happen BUT that's it in a nut shell.....the kernel and 9/10 times libs
See ya around dude!

Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?

thebeastglasser said:
Hey first off, thanks! Second...
Another question then. If they all have relatively similar hardware, why isn't it that a universal kernel for similar phones can't be created?
Or better explained, what about the phone, makes it so that the kernel doesn't work? Or why couldn't you just take the kernel from device A and shove it on device B?
Sorry if I'm overloading you with questions, but hey I'm curious. Ya know?
EDIT: Or if they're practically both the same phones, why is it that you can't just take the ROM AND the kernel from phone A and put it onto phone B?
Click to expand...
Click to collapse
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.

Theonew said:
It's the manufacturer of the device who would need to release the kernel sources for the certain firmware version which they won't do continuously. In other words, device A may get ICS, hence the kernel sources may be released, but device B may be stuck with gingerbread and may not have a kernel which supports ICS. Back-porting can be done, but in many cases it is very difficult and in the end there still could be a lot of bugs.
You can't just take a kernel and "shove" it in another device. If you did this, it's quite likely nothing would work. The device would not even boot. Remember, the kernel is the center of android (Linux), so everything needs to be "linked" and correspond with each other exactly for it to work (I'm trying to make it as simple as possible ).
If they are the same devices, that would not be necessary. They would use the same roms/kernels. If they are just very similar (e.g. the a100 and a500) you may have some luck with the roms, but not the kernel. Some a500 roms can be flashed onto an a100 and work flawlessly BUT the device's original kernel must be restored for the device to boot.
Click to expand...
Click to collapse
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!

thebeastglasser said:
I have the strangest feeling I just tried to jump into the shallow end of the swimming pool, and yet instead was shot out of a cannon into the middle of the sea without a scuba diver's suit... If only I could understand this more!
Click to expand...
Click to collapse
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.

mf2112 said:
Think about it this way. The Android OS could be run on a number of different devices that run slightly different hardware such as cameras, touchscreens, processors, etc...but the OS has to be able to communicate properly to that hardware using device drivers. Just like Windows from a 30000 foot view. It can run on a Dell or Acer computer, but must have the proper drivers.
If the manufacturer's of those devices do not write ICS drivers or preferably furnish their source code, then it is incredibly difficult if not impossible for someone without the internal company documentation to write such a driver.
Click to expand...
Click to collapse
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...

thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Hmmm, I am not as familiar with the Nexus devices, but I suspect that Google has released the hardware spec details and the source code for the drivers for Nexus phones, so the source code can be modified and included for the ports. HTC unfortunately has not been as open with some of their phones.
If you were to put a phone together, you would need to use hardware in it that you had access to the specs and source code for. This is not a great analogy, but I think it will serve. The camera app tells the OS, "take a picture", then the OS tells the driver, "make the camera take a picture", and the camera device driver controls the hardware parts like the shutter, the focus, and zoom to cause the picture to be taken and handed back to the OS to be saved and then the OS notifies the app, "here is your picture, awaiting next command".
If you do not have access to the camera driver source code and camera hardware specs to create a driver, or an actual driver from the camera manufacturer, then you are missing the crucial third part and you cannot make the camera take a picture even if you get an OS loaded and an app installed there.
Check out The Tricorder Project for an excellent example. Create your own Star Trek "tricorder" with various sensors and a touchscreen that runs on Linux for around $200 and some work putting it together.

thebeastglasser said:
Ohhh... so say you decided to put your own little phone together according to your own prerequisites, it'd be simple for you to do something on it, but not so much for someone who only has the hardware to look at... correct?
Another question, why is it so easy to port things onto Nexus Devices? Are they just more compatible with all drivers? As I've heard from one of my friends that he has a fully working Sense 4 ROM on his Nexus S... and yet it's tough to find one for my Evo V.
EDIT: I'm out of "thanks" I'll give you one as soon as I get some more...
Click to expand...
Click to collapse
Its easy to develop for nexus devices since Google always releases their sources and those devices are easily unlockable (the bootloader). This is one reason why they are usually referred to as development/developer devices.

So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?

thebeastglasser said:
So in other words, the software communicates with the hardware, but without the proper code embedded in the hardware, it's not possible for the software to communicate with it? And without source code given from the developer of the hardware, you're making software that hypothetically should work, but because of the different device hardware it may or may not work...?
And that's also big because some guy on the portal recently found out that all of the eight mega pixel cameras on HTC devices are the same, so it should now be easy to use working cameras on ported and newly created ROMs...
Am I getting anywhere with this?
Click to expand...
Click to collapse
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).

Theonew said:
Yes, you got it a bit better now. The software needs to have the same codes embedded in the hardware to correspond with it. The source code is not from the hardware but of the software (kernel source).
Yes if the ROM was ported to other HTC devices with the same/similar camera (some libs will still need to be changed though).
Click to expand...
Click to collapse
Alright that makes a bit more sense. Thanks for your help guys!

Difference between Nexus S

The Nexus S has the same CPU as our phones, same storage, same screen and they get OTA updates right to jellybean. What is the difference between that phone and ours that would make using their ROM's to help with our phones?

One of the reasons the x86 platform has been so successful is that there are thousands of pages of requirements that make most versions of computers running with an x86 CPU "look the same" to an operating system. For example, the video card always has to implement the same set of instructions and the same way to draw things on the screen.
Unfortunately, phones aren't as generous.
While other phones use the same CPU, they often use different chips to handle things like the keyboard, screen, audio, GPS, phone radio, WiFi, Bluetooth, USB,... Each of these requires a different driver (the code that lets the kernel "talk" to the chip in a standard way). Remember Windows 9x when every time you bought a new mouse, video card, or whatever you had to search for the right driver?
Worse than that, there are hundreds of pins on the CPU and no "wiring diagram" for the devs to work from. Some of the big puzzles the devs are working with are figuring out which pin goes where when making these drivers connect up right. Not only is it knowing which pin goes where, but is it rising edge means "1" or falling edge, should the pin be inactive high, or low. How fast can the device take data?
Then are the "proprietary bits" -- this is the biggest "lie" about devices claiming to be "open source." Even though parts of the device may use Linux or have source available for the dev to look at, some things are just "binary blobs" that the manufacturer wrote themselves, or obtained from the chip vendor and added to their device. No source is available. In some cases, they can be re-used with a later kernel version. In others, they are just "too old" and you're stuck because they don't implement certain instructions that a newer kernel needs, or implement it in the "wrong" way -- think trying to use a Windows 95 driver with Windows 7 -- It just isn't going to work.
For the SGS4G, some of the proprietary bits we are stuck with include:
Boot loaders -- the code that runs when the phone starts up that knows how to read the flash and start the kernel
RIL -- The code that runs the "phone" radio
GPS
TV Out
WiFi Calling
I know I've got all three of the Samsung source drops for our phone on my machine, as well as two versions of kernels from AOSP (semi-official Google source), two versions of Linaro, mainline Linux, CyanogenMod, Team Hacksung, and a few more, all of which include drivers for several phones similar to ours. It chews of a bit of disk space, but sometimes can provide insight.
We can't "just build JellyBean" as there have been some very significant changes in the kernel between the 2.6.35 version we have now, and the 3.x line that JellyBean needs to run. For example, how "events" are handled by the kernel has changed. These are things like pressing a key, so they are sort of important to get right.

Thanks. I was just cruising around looking at Sammy phones and saw that and it looked similar specs. I know all about drivers/pcs/different devices/chips used in things, run a repair shop fixing electronics/pc's, I do reflowing, reballing, etc. Just didn't realize they made the Nexus so different. That's fine, I'm happy with the Remi ICS for now.

So... you can remove and replace bga chips?
Sent from my SGH-T959V using xda premium

Once someone tries and screws it up, please send the remains to bhundven so he can trace out the circuit board
(Joking on trying it, not joking on Team Acid being able to benefit from a destroy-able SGS4G.)

There's a galaxy s 4g main board on eBay right now ending in like 20 min currently at about 5 bucks
Sent from my SGH-T959V using xda premium

looking for interested devs

Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.

so basically you have good intentions, no plan and a home server )
what we really need is a unification of all the different but not really different roms and their devs,
then its possible to see a future for long term support for all devices, or at least many.
anyhting else is jsut another project that will or will not die, based on good will and free time of the maintainer, mostly not even reckognized
due to the chaos of fragmented android and even more fragmented custom rom scene.

godkingofcanada said:
Hoping this is the right section since its not device specific.
Experienced or not, it doesn't matter. I've been on XDA for a number of years. And am noticing things from my own experience and talking to others. Its hard to get help sometimes. Not all devs want to talk. Teach. Or help people all the time. Devices are being dropped from support. Maintainers are leaving the scene. Currently I have an Oreo and pie ROM for s6e+ and note 5. With the list of devices being dropped, and surprising amount of people reaching out to me for support, I decided it may be beneficial to recruit a few people who want to develop ROMs. This is a great chance to learn. I would like to pick up at least partial support for several more devices, and need some help to do it. My goal in this endeavor is to continue to provide ROMs to people who need them, while teaching other users to develop. This will help to bring fresh life to the scene, and allow support for more devices to be added. If you are interested reply below or inbox me. There is a google hangouts set up, and other methods of team communication will follow. I also have a home server with a 24/7 connection and no data limits on my internet, and an ftp set up to host files directly and not need third party sites.
Click to expand...
Click to collapse
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Sent from my Pixel 3 XL using Tapatalk

Atifbaig786 said:
I respect your Idea but I don't think something like this is required.You see I had been using linux for 4+ years and was pretty adapted to it when I switched to a Note 3.Recently I discovered the Modding part of it and the huge development of custom roms and kernels.and despite having no clue what I was doing I could easily develop a Kernel without a hassle.I went even one step further and made a halium port for it.Sure it didn't boot the first time but by using methods on xda already discussed in detail I was able to make it work.So,the main thing is that someone like me who has no experience could make a ROM in 3 hours without any complications(Except those who could be solved by googling).Then anybody could do it.Currently there isn't a ROM bug or a issue that hasn't been discussed on either xda or other android development sites.But that doesn't mean we shouldn't help newcomers.But it is rare for someone to look on the other side of development and there is enough documentations for him to do it.Maybe too much.qq
Click to expand...
Click to collapse
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source

godkingofcanada said:
You can't just make a ROM for any device is 3 hours. It doesn't always work that way. Especially not if building from source
Click to expand...
Click to collapse
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Sent from my Pixel 3 XL using Tapatalk

Atifbaig786 said:
I just followed a guide.On an XL VPS. With maybe 22GB ram and 16 xeon cores
Click to expand...
Click to collapse
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.

godkingofcanada said:
I don't disagree sometimes it is easy. But what if lineage or GitHub don't have all necessary files for the build? And then you need to extract them from your phone manually, or if build won't boot up and needs modifications to the kernel.. fixing drivers that do not work. It's not always so simple as build, flash and finish.
Click to expand...
Click to collapse
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Sent from my Pixel 3 XL using Tapatalk

Atifbaig786 said:
I did face issues.The End of the guide covered the basics of logging stuff and finding things.They were just as same as debugging a linux OS but yeah you're right as I did face the extracting files(dunno what was supposed to do).So I wrote "extract proprietary vendor code from ROM" and boom lineage gave it to me.Also the guide was only for devices that exist on lineage and sometimes we need to start from scratch.And maybe We both are,Who knows what the future might bring,BTW have you heard about Google's new Boy Fuchisa or something like that.I wanted to talk someone in the field of development about this but nobody was bringing up the non-linux version of Google's OS for smartphones.
Click to expand...
Click to collapse
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice

godkingofcanada said:
Yes I heard about it. I stumbled across it by accident looking for a way to shim the s6 edge plus cam on my pie rom. It lead me to reading about vulkan, which showed me a new Google os. It looks nice
Click to expand...
Click to collapse
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Sent from my Pixel 3 XL using Tapatalk

Atifbaig786 said:
Well It seems that it uses a Different type of kernel "microkernel".For someone as stupid as me I don't get it what was the difference between a microkernel and monolithic one on an android device(or a low powered arm processor based board that has a screen attached to it)Will it be performance,Faster loading,Efficiency.I can find a million articles on microkernel vs monolithic but they are in latin for me.But you can just give me the crash course in maybe 3-4 lines.
Click to expand...
Click to collapse
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform

godkingofcanada said:
Device drivers, protocol, file systems moved from kernel to user. It's got less code, more lightweight. And it was created with embedded systems in mind. In theory it should be faster, and more suited to small devices like phones with embedded systems. Giving devices their own dedicated kernel finally instead of butchering a Linux kernel to suit their device needs. It's also universal in terms of cross platform
Click to expand...
Click to collapse
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Sent from my Pixel 3 XL using Tapatalk

Atifbaig786 said:
Now that's more like it.I was afraid that android was finally going to commit close source(or suicicde).But since it's open source and I hear good things from you and 4 other guys who have experience in doing stuff I think,Hope and Pray that it might be a good change.Also thanks for using plain English and being a Open guy.Currently I am thinking that 5 years from now someone gonna run into this post and have a little smirk on his face for you who is reading this,Quote and tell me was it good?Was we good?
Click to expand...
Click to collapse
I think the changes appear good. Less stuff locked away in private, more easily accessible to all. Treble has the vendor stuff available to roms that aren't stock, this will make the kernel tiny and easy to build. One by one the barriers people have to overcome to build their own roms are being taken away.

Arguments for the possibility of a ROM compatible with all (android based?) phones?

I know what you're thinking: "uhmm, GSI.. case closed".
However, I mean a type of OS that would literally be usable on any device with minimum requirements, and thus basically all smartphones on the market these days.
Would this even be possible considering how software & hardware communicate?
I'm a industrial designer/Sound engineer myself and was wondering about this while installing LineageOS onto my lenovo phone. I think more people would like it if they understood what it's good for.
Problem is; most people don't even know what a bootloader is.. There must be a way to make this easy to do for people. An operating system like this would definitely help, right?
I'm looking forward to some well reasoned input!
Greetings, Quince

QuinceDroid said:
I know what you're thinking: "uhmm, GSI.. case closed".
However, I mean a type of OS that would literally be usable on any device with minimum requirements, and thus basically all smartphones on the market these days.
Would this even be possible considering how software & hardware communicate?
I'm a industrial designer/Sound engineer myself and was wondering about this while installing LineageOS onto my lenovo phone. I think more people would like it if they understood what it's good for.
Problem is; most people don't even know what a bootloader is.. There must be a way to make this easy to do for people. An operating system like this would definitely help, right?
I'm looking forward to some well reasoned input!
Greetings, Quince
Click to expand...
Click to collapse
Every kernel hooks differently on every device, every device has different framework... So no that's why they have source code ex lineage that you take your framework and kernel etc and compile it. Even if you made an installer that could compile it on your phone if you trew in the kernel and framework in would take hours and lock up the phone. So this would most likely not be doable until every phone used the same partitions framework kernel etc. Short answer not gonna happen... Gsi is closest thing to it and you still need a gsi for your device set

toolhas4degrees said:
Every kernel hooks differently on every device, every device has different framework... So no that's why they have source code ex lineage that you take your framework and kernel etc and compile it. Even if you made an installer that could compile it on your phone if you trew in the kernel and framework in would take hours and lock up the phone. So this would most likely not be doable until every phone used the same partitions framework kernel etc. Short answer not gonna happen... Gsi is closest thing to it and you still need a gsi for your device set
Click to expand...
Click to collapse
I see, thanks for your reply! Would an AI driven process be able to do these tasks after sufficient trial and error?

QuinceDroid said:
I know what you're thinking: "uhmm, GSI.. case closed".
However, I mean a type of OS that would literally be usable on any device with minimum requirements, and thus basically all smartphones on the market these days.
Would this even be possible considering how software & hardware communicate?
I'm a industrial designer/Sound engineer myself and was wondering about this while installing LineageOS onto my lenovo phone. I think more people would like it if they understood what it's good for.
Problem is; most people don't even know what a bootloader is.. There must be a way to make this easy to do for people. An operating system like this would definitely help, right?
I'm looking forward to some well reasoned input!
Greetings, Quince
Click to expand...
Click to collapse
Such an OS may be "possible" but it isn't practical. To do so would mean that the OS would have to have the resources needed by every type of CPU and every type of architecture built in. This would mean that the OS would be too large for most devices, it would occupy a lot of space on internal storage, some devices wouldn't even be able to contain the OS, much less install additional apps in that OS. That is why each android firmware or ROM is individually built with only the resources that the specific device it is built for needs. Including resources into the OS that it doesn't need, would be redundant.
Sent from my SM-S767VL using Tapatalk