Develop Bugs

Isn't there any Android version with everything working?

Hey guys,
I'm searching for an Android version that has everything working, i.e. Camera, GPS, WiFi...
I know this was possible with Android 1.6, there were several versions, some had the camera working, some had WiFi working - but none had everything working.
But it proves that it's possible.
Why are people only working on Android 2.x anymore, when there are so many things not working and probably never will?
And why make so many different versions with none of them working 100%? Can people not work together and create ONE version that has everything?
Please, if there is any Android (likely 1.6, cause 2.x seems impossible to get fully working) version that has everything working, direct me to it. If not, why not come together and try it?

If you feel it is this easy, why not do it yourself?
I believe noone has made a fully working distribution yet due to the fact that it is difficult. Add the fact that most of the chefs does this as a hobby, and you might understand why it is hard to get developers to spend a lot of time on it.
My two cents.
-KJ
-------------------------------------
Sent via the XDA Tapatalk App

Well, if you actually read my post, I said all the necessary stuff is there for Android 1.6. It IS possible.
The problem is just that people can't work together. There have been 1.6 versions with the camera working, and others with WiFi working, and others with GPS working, but none with everything.
But it's clear that it would be possible, if people put the pieces together.
Unfortunately, nobody seems to be working on 1.6 anymore. It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
I am sure we could have a fully working Android version. It doesn't have to be the newest one, but at least it would be good for everyday use.

Well camera was never working on Touch HD and stuff you mentioned aren't about Android version. Those hardware issues are mostly linux kernel related and only way to fix them is to write a proper drivers and modules - and that's the tricky part. Simply put: Android version has nothing to do with non-working hardware on our devices.

I remeber I had the camera working... or was that another device? I have too many phones lying around here, but actually I am pretty sure I had the camera working in an older Android version.

shaundalglish said:
blah blah...
I know this was possible with Android 1.6, there were several versions, some had the camera working, some had WiFi working - but none had everything working.
...blah blah...
Click to expand...
Click to collapse
hey man, wake up!
You 're just frustrated but you do not propose anything.
Thx for this usefull thread

shaundalglish said:
Well, if you actually read my post, I said all the necessary stuff is there for Android 1.6. It IS possible.
The problem is just that people can't work together. There have been 1.6 versions with the camera working, and others with WiFi working, and others with GPS working, but none with everything.
But it's clear that it would be possible, if people put the pieces together.
Unfortunately, nobody seems to be working on 1.6 anymore. It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
I am sure we could have a fully working Android version. It doesn't have to be the newest one, but at least it would be good for everyday use.
Click to expand...
Click to collapse
This is a TOTALLY misleading post.
The number of devices, the variation in hardware and memory is quite extensive... yes, somebody MIGHT get the camera working on ONE specific device... this is hardly a version of Android everybody can enjoy.
For the large part most of the developers ARE sharing knowledge, but there are people screaming "why isn't MY device supported, and other saying why are your bothering with old version of Android, and others screaming, where's Froyo???"
XDAndroid's come a long way. But there are only a handful of developers working on it, and they don't have every single phone at their disposal (not to mention every operator variant with slightly different radio code and configuration).
Each week the development takes two steps forward, and one step back... but it's progress. All that you're asking for is more progress.... and the only way you can get that is by contribution the code changes to the dev team.
If you can't do that, then you just have to sit back and wait.

shaundalglish said:
It's clear that 2.x will NEVER be fully working on the Touch HD, so why do people waste their time on that?
Click to expand...
Click to collapse
How is it clear? It's being worked on... perhaps at a pace that's not to YOUR liking, but it's being worked on.
What evidence do you have to suggest it will NEVER be fully working?
It is true that it's proving to be difficult, but it's also true that it's very hard to stay with 1.6 when many new apps stop working with it, or new features NEED 2.x, and all the latest source code will include support for newer devices and 1.6 won't.
The developers aren't working on HD alone, they are working on a release that works on multiple devices. If someone wanted to focus on HD, they'd be welcome to, but nobody is. They are sharing their knowledge for the greater good of all devices.
To be frank, if someone is truly that crazy for Android, then they are fools to be using a WinMo device. They should have bought an Android device.
If I want OSX, I should buy a Mac. The fact that I can run OSX on my PC is nice, but I should expect issues. The same applies to XDAndroid. Expect issues.

TheBrilliantMistake said:
How is it clear? It's being worked on... perhaps at a pace that's not to YOUR liking, but it's being worked on.
What evidence do you have to suggest it will NEVER be fully working?
It is true that it's proving to be difficult, but it's also true that it's very hard to stay with 1.6 when many new apps stop working with it, or new features NEED 2.x, and all the latest source code will include support for newer devices and 1.6 won't.
The developers aren't working on HD alone, they are working on a release that works on multiple devices. If someone wanted to focus on HD, they'd be welcome to, but nobody is. They are sharing their knowledge for the greater good of all devices.
To be frank, if someone is truly that crazy for Android, then they are fools to be using a WinMo device. They should have bought an Android device.
If I want OSX, I should buy a Mac. The fact that I can run OSX on my PC is nice, but I should expect issues. The same applies to XDAndroid. Expect issues.
Click to expand...
Click to collapse
Very well said. These people never stop complaining.

shaundalglish said:
I remeber I had the camera working... or was that another device? I have too many phones lying around here, but actually I am pretty sure I had the camera working in an older Android version.
Click to expand...
Click to collapse
Sorry buddy, but you're not recalling right, the camera has never worked on the Touch HD, no matter how old the version was (and GPS support only came recently a few weeks ago).
Camera support & GPS are a kernel feature (simply put, the kernel is all the drivers for the hardware in the devices and the way to properly communicate with them) it is not an android feature (android operates on top and apart of the kernel).
I can't comment on the other devices but I don't recall having a winmo device having his camera supported in android, they have a really hard time implementing camera support in the kernel, so they did go on with the other things such as better stability, speed and battery life...
But if you have the resources, feel free to help, xdandroid team will be happy to welcome another dev.

Becoming a bit of a flame war and I see no end result.
Thread closed

[Q] How Does the Android OS Work?

Disclaimer: I am only a flasher. I do, however, contribute to the forums, donate to devs and also use the paid version of good apps.
My question is: How does Android work on our phones?
You have hardware (HTC Incredible); you have a carrier (Verizon, in my case); you have an OS (Android, obviously); you have a radio; you have a ROM; you have a kernel; you have themes, you have skins and you have apps. How do all these pieces interact? Just curious.

This is a really good question that should be answered in laymen's terms. I'm surprised it hasn't been answered yet.

I also thought it would have been answered by now. However, I think the developers (who would be the best folks to answer this question) are busy working with the Gingerbread source code to build new ROMs for us.
This is what I have figured out so far but I'm not sure if my analysis is correct:
After selecting your hardware and carrier, the OS is the most important element. Most of us are currently on Froyo (2.2). I have seen some screen shots showing the OS version to be "2.2.1" but I am not sure why. Google (I think) has released the source code for Gingerbread (2.3) and the developers ("devs") are hard at work producing new ROMs as I post this.
I gather that it is best to stay away from trying out different radios ("basebands"). Most of us are using 2.15.00.07.28.
I think the ROM takes the OS and re-works the user interface by adding, removing and changing the various screens and "features" of the OS. For example: the ROM can be written to take out the stock music player and substitute a music player that the ROM developer prefers. I think this is called "baking in an app". I believe the ROM developer can also create an overall "look and feel" that can be quite different from the stock OS. For instance, the ROM can be "colored" in black and red (rather than the stock green) and the stock font can be changed to something the developer prefers. In other words, the ROM is what you see and use on a daily basis.
Now this is where things get a little fuzzy: the kernel. I think this is kind of a behind the scenes element that governs the performance of a ROM. It greatly affects things like battery life, time to charge the battery and the "speed" of the phone. The kernel is where the phone can be "over-clocked" and "under-volted" should you want to do those things. I gather that once you select a ROM, you can try different kernels without changing what the various screens look like on the phone. I believe this is the way most people do it (pick a ROM and try different kernels with it). I don't think the other way really works (pick a kernel and try different ROMs with the kernel).
Next comes themes and skins which really only affect what you see on the various screens without do anything about battery life or the speed of the phone. I haven't played with these much.
Finally, I forgot to put WALLPAPER on the list in the original post. I believe this only appears as a background image on the home screens.
If any reader sees errors in my layman's analysis, please, by all means jump in and correct me. Per my disclaimer in Post #1, I am just an ordinary user and this analysis could be flawed or incorrect in whole or in part.

Everytime I try to answer a question like this, I get too complex about it and leave more questions than answers. Then someone comes along and says "It's like Windows or Linux or MacOS on a PC", and that's that. Well they're right. Those OS's tell the PC's that they are PC's and essentially all OS's do the same things.
Here's my simplified new list:
1) Hardware on phone :: meaningless without OS
-- (android OS - or any other OS)
2) Linux kernel understands hardware like touchscreen, radios, I/O (drivers/modules). Of course it also understands how to schedule processes and all those "kernel tasks".
3) Libraries provide APIs (Application programming interface) to userspace code (like APPS).
4) Userspace (apps, scripts, libraries) provide user control over the phone.
--
Together they work in harmony (we hope) to make the phone realize it is a phone and allow us to use it as such. (well, a smartphone, so many things other than a phone).
Here's a simple example: You touch the phone icon which is in userspace, and it brings up the userspace phone app. As soon (or before) as you touch some buttons, dial a number, it is using the API to the driver in the kernel that actually understands the phone hardware/radio. Also userspace controls GUI which is also requiring API to some form of OPENGL API that is requiring device drivers that get the touchscreen/LCD display. and so on.
--- Hashi
PS: I realize there are a thousand things wrong with this representation, but hey, it's a start. Feel free to fix it up if you're inclined.

Attempting development for Gingerbread. (Long post/discussion)

Hello everyone...I'm planning on trying to develop a gingerbread kernel for AOSP because we don't really have support anymore and everyone has moved onto developing for ICS (not that this is a bad thing). I figure in my spare time I might as well try to learn and develop for our phone. Let me start by saying I was never really into phones/smartphones/rooting, or software development, but I've always been fascinated by Linux in general. I've played around using a number of Linux distros, but I've never really done anything intensive with them (modified their kernels, etc.) but I am vaguely familiar with terminal usage.
Anyways that was just my introduction. I've been running an ICS kernel on my AOSP GB system (specs/stuff in my signature) and while most advised against it, I find it to run pretty well. I'm not sure why it seems to run so well on my phone, but it's basically solved most of my problems (or at least it appears to have done that), but I know the kernel isn't "optimized" for my phone. Some major things people have said are that the ramdisking operations/system is totally different when comparing ICS and GB. This kernel that I'm using is running pretty well, even knowing this fact. What I was wondering is if I could basically get the ICS kernel, then "merge it" with a GB kernel's parameters that pertain to the ramdisk/other major options of GB. That would probably make it better. Also, people stated that multitouch issues for the DINC2 occured on Aeroevan's 0.8 kernel, but not on the 0.7 kernel. This was the changelog stated by aeroevan:
v0.8: Upstream CyanogenMod changes + small touchscreen driver update from HTC. Only tested on my CM7.2 Kang build.
Click to expand...
Click to collapse
So maybe this "small touchscreen driver update" is the thing that caused it, but I'm assuming many other kernels applied this update too? Maybe there is a way to roll back to whatever was in 0.7 in this sense to get rid of the multitouch bug that plagues some people.
I have a pretty powerful laptop, so development shouldn't be too bad. I plan on running Ubuntu 11.10 (or whatever people find suitable these days) in a Virtual Machine and I plan on compiling stuff from there. I am not claiming I know everything or that these things are correct....I am simply just throwing out some brainstorming to get some ideas out there. I know GB is "old", but I (and some others as well) enjoy it's stability and that it generally functions perfectly. Maybe this thread will get a look from popular devs, or maybe it'll get a look from people who just know this stuff. Thanks for reading, and sorry for the length of the post.

Looking forward to your progress on this.
Sent from my ADR6350 using xda premium

It would be nice to have another kernal for AOSP other than aero.

Your help in developing AOSP kernels would be fantastic.
Thanks given. Because I am hard of hearing I cannot use any of the kernels (even Evan's) and have to stick to Sense

[ANSWER] -_/*~Kernel~*\_-

There are many explanations that people will tell you to the answer to the "what is a kernel?" Like this great one from Omnicide
Spoiler
Omnicide said:
The best way i seen it put was, think of the kernel as the engine and the rom as the body of the car. The body of the car (rom) just makes the car look nice and user friendly. Now when we talk about the engine (kernel) simply put red lining the engine will get you to go fast but burn gas. Keeping the rev down low will make you run slower but saving lots of gas. Thats just one way to look at it, rpms being the cpu.
Click to expand...
Click to collapse
or this great one from androidcentral.com
Spoiler
What is a kernel? If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example --when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
. You probably didn't get it at all, so let me tell you what a kernel is in about 17 words. A kernel is "what makes the phone work, and connects the hardware (camera, storage, etc.) And the software (the Rom)."
I don't want to be thanked for this, thank omnicide, and androidcentral.com for the great explanations.
~~~~~~~~~~~~~~~~~~~~~
Samsung galaxy s2
Rom: Jedi knight 6
kernel: Jedi kernel 2
~~~~~~~~~~~~~~~~~~~~~
And you thought celebrities weren't smart! =P

Kernel can correlate to brains function in the human body meaning the manager of the perishing body.
Or the manager of the resources available.
Or the manager of the body.
Sent from my SAMSUNG-SGH-T989 using xda premium

I flashed JB Jedi 2 which came packed with a rom while it works great I wonder what will happen if I want to switch back to a different Rom will it be compatible with the kernel it installed?

All roms install their own default kernel each time you flash them.
They are usually chosen by the rom's Dev for good reasons (usually stability) .
It's up to you if you then choose to replace the included kernel with one of your own choosing.
At that point you should think twice about posting glitches you encounter on the ROM developer's forum because you have now changed a fundamental component of his work which is not of his choosing. It would be kind of rude to clutter his thread with problems that may be caused by the replacement kernel.
Feel free to push the envelope, just make a backup first then post problems to the kernel's thread.

Ohh ok I really didnt know that as some roms I have downloaded are 90mb some are like 330mb does that mean they are all compressed in different ways?

davcohen said:
Ohh ok I really didnt know that as some roms I have downloaded are 90mb some are like 330mb does that mean they are all compressed in different ways?
Click to expand...
Click to collapse
No. Some ROMSs gave more data or bloat. Slim ROMs, are well, slim. Leaks, like, Jedi jelly, tend to be pretty big, due to all the bloat they have.

LoopDoGG79 said:
No. Some ROMSs gave more data or bloat. Slim ROMs, are well, slim. Leaks, like, Jedi jelly, tend to be pretty big, due to all the bloat they have.
Click to expand...
Click to collapse
Bloat = the stuff, APKs in this case, someone decided are not necessary.

[Q] What is The problem with Sense?

Hi All,
I have been reading that a fully functional Sense rom is not possible, and it is about kernels or such, But I am having trouble understanding the real problem. I tried digging the site for the reason, but searching HTC and Sense in a mobile developer forum hardly filters any entry, so please help me understand.
I am thinking as 3 layered structure, Linux kernel in the middle, drivers at the bottom and AOSP with sense modifications at the top.
The problem I am having is, since the kernel is GPL, how come nobody was able to glue all of them together. I am assuming the top part has some non standart calls/interfaces with the kernel, but it must be open source, so what is the part that makes patching same interfaces/calls to another kernel impossible?
If the calls require driver changes(taking in to account nearly all drivers are proprietary) that means we need same hardware of a sense device, but it possible if hardwares match, right?
The real question, is it not possible technically, too hard to implement practically or just won't worth the effort?

enginmanap said:
but it possible if hardwares match, right?
Click to expand...
Click to collapse
There isn't a single HTC device with OMAP4 CPU to my knowledge.
Sent from Samsung Galaxy Nexus @ CM11