Develop Bugs

software under device forums?

Is this a good idea? as it causes fragmented discussion, eg. dt-apps2sd is something that works across devices but I see it discussed under one particular device meaning generally only owners of that device will take part in that discussion. BLN is another example.

chrcol said:
Is this a good idea? as it causes fragmented discussion, eg. dt-apps2sd is something that works across devices but I see it discussed under one particular device meaning generally only owners of that device will take part in that discussion. BLN is another example.
Click to expand...
Click to collapse
BLN though can be pretty device specific... Even down to the actual kernel you're using... I think there's always going to be a need for device-specific discussion of these things tbh - I doubt that would change

Or a mod for a Sense ROM, wont work on different Sense ROMs and non Sense ROMs etc.

yeah roms make sense of course that doesnt bother me, was just a thought tho

[REQ] Guess what? Right, 3.0 kernel.

@Kernel devs,
Please, congregate your forces and build 3.x kernel for our precious Arc. I bet this will be one of the most (if not The Most) appreciated works. I bet this will be one of the most useful ones too. I bet almost every Arc/S user will agree with me.
Sent from nowhere

Absolutely!

What are the features you are waiting for in 3.0?

soo what does the new kernel provide?! I've seen few comments about users wanting the new kernel, and was wondering what improvement will it do to our Xperia?!

Mods please move this thread to general or Q&A. This thread is for android development, not wish lists.
Yes we'd all love a new kernel, why not bump to 3.5, well the answer to that is closed source drivers. While we should be able to theoretically add most of the maintenance patches to get to the latest 2.6.32.xx, porting to different major versions are just unlikely to be possible for our phone. You can't link against something with a different API, it just won't work.
The first request should be made to Sony to release sources for these drivers. Good luck with that.
So instead of focusing on version numbers, instead ask "Is feature X possible with our current kernel" and the kernel devs will try to accommodate and patch it in.

First of all, this isn't for Wishes and Requests, this is where you share you dev work with everyone, if you have a request then go to general or Q&A.
Second, EVERY DEVELOPER ALREADY KNOWS ABOUT THIS. Everyone IS WORKING on Kernel 3.0, ICS was laggy and JB isn't perfect is because the the lack of support in the kernel. So they don't need a "request"
Third, it is not impossible but very very hard. There is a reason why kernel 3.0 was never ported, because even the best devs like FXP and DoomLord CAN'T. Unless Sony releases their hardware sources or some developers open up his own Arc and get it out, no kernel 3.0 can be ported!

Custom msm7x30 3.0 kernels are still really in infancy stages with no major changes. If anything it's just a facelift but still the same purpose-wise.

Well, for those saing that devs can't do something I would argue - there's a 3.0 kernel being developed for HTC Desire (which also has closed source drivers) and guys working on it are pretty close. Same goes for HTC DHD and HD2 if i'm not mistaken. So why not for our device?
Sent from nowhere

tajimura said:
@Kernel devs,
Please, congregate your forces and build 3.x kernel for our precious Arc. I bet this will be one of the most (if not The Most) appreciated works. I bet this will be one of the most useful ones too. I bet almost every Arc/S user will agree with me.
Sent from nowhere
Click to expand...
Click to collapse
+ over 9000!
---------- Post added at 09:49 AM ---------- Previous post was at 09:40 AM ----------
It would be just awesome, beacuse idiots from Sony will pobably never update our kernels. Even HTC Wildfire S (which is little, smarttoy) has 2.6.35.x. It's not big difference, but... It is!

pmdisawesome said:
First of all, this isn't for Wishes and Requests, this is where you share you dev work with everyone, if you have a request then go to general or Q&A.
Second, EVERY DEVELOPER ALREADY KNOWS ABOUT THIS. Everyone IS WORKING on Kernel 3.0, ICS was laggy and JB isn't perfect is because the the lack of support in the kernel. So they don't need a "request"
Third, it is not impossible but very very hard. There is a reason why kernel 3.0 was never ported, because even the best devs like FXP and DoomLord CAN'T. Unless Sony releases their hardware sources or some developers open up his own Arc and get it out, no kernel 3.0 can be ported!
Click to expand...
Click to collapse
Work had already begun (with a lot of help from Jimbo77). It is stopped now (holidays) but for sure it's not abandoned.
tajimura said:
Well, for those saing that devs can't do something I would argue - there's a 3.0 kernel being developed for HTC Desire (which also has closed source drivers) and guys working on it are pretty close. Same goes for HTC DHD and HD2 if i'm not mistaken. So why not for our device?
Sent from nowhere
Click to expand...
Click to collapse
Because there is no Sony msm8255t 3.x kernel released that we can use as a base. There are major changes between 2.6.3x and 3.x kernel so
-all hardware related files (read: cpu, vibra etc) must be updated
-all drivers (read: screen, keys, sound etc) must be updated or rewritten
so it takes a lot of time and learning.
It's done when it's done
Click to expand...
Click to collapse

gen_scheisskopf said:
Work had already begun (with a lot of help from Jimbo77). It is stopped now (holidays) but for sure it's not abandoned.
Because there is no Sony msm8255t 3.x kernel released that we can use as a base. There are major changes between 2.6.3x and 3.x kernel so
-all hardware related files (read: cpu, vibra etc) must be updated
-all drivers (read: screen, keys, sound etc) must be updated or rewritten
so it takes a lot of time and learning.
Click to expand...
Click to collapse
first and bigest major new funcion is ntfs suport(for me there are, also sove with batery iporvents , also ksm is form 3.0.16 or 3.0.8(with used in cm roms))

n1kolaa said:
first and bigest major new funcion is ntfs suport(for me there are, also sove with batery iporvents , also ksm is form 3.0.16 or 3.0.8(with used in cm roms))
Click to expand...
Click to collapse
I had internal functions in mind (like ssize_t(*show) ), not user level.

Why would anyone think that this thread belongs in Development section, is beyond me.
Moreover, why would anyone think that in such community, known for the breakthroughs that its developers are achieving at a daily basis, such a request thread is needed.
I would like to believe that anyone who has been here long enough knows that if something is possible, it is done.
So, all in all, please think twice before clicking the "Start A New Thread" button.
Thanks for your cooperation.
Thread closed.

[Q] What would happen if I build android from source and flash it to my One X?

What would happen if I build android from source and flash it to my One X?
With the current release, it is possible to build for Nexus 7, for some variants of Galaxy Nexus, for a variant of the Motorola Xoom, and for all variants of Nexus S and Nexus S 4G. The exact level of functionality for each device depends on the availability of the relevant proprietary hardware-specific binaries.
Click to expand...
Click to collapse
- (source)
Will I brick my device? Did HTC basically just take the code and modify it to work on the One X? Any suggestions on how to proceed if I were to build my own ROM?

If you have no experience in this you are likely to f*** things up.
Just stick to aosp roms - same result.
Sent from my HTC One X

TToivanen said:
If you have no experience in this you are likely to f*** things up.
Just stick to aosp roms - same result.
Click to expand...
Click to collapse
Well that is no fun answer. I want to learn. I make apps for a living and want to advance and build my own ROM, because I want an all custom made one. I know I can go with CM and mod their code (or, can I?), but it would be more fun to actually do it from scratch. If it is possible, not build from AOSP at all. I know it sounds retarded but I believe the best way to learn is do as much as possible completely from scratch.
With that said, do you have any suggestion on where to start? Like mod the AOSP source code and get it running on the emulator?

You can branch cm10 and build that, it's a good place to start, you'll learn a lot.
After that, you may want to say, diff the AOSP kernel against a similar HTC kernel to see how many changes you'd be required to make to pure AOSP to get it to work with all the hardware specific bits.
Due to GPL, HTC are required to release the source modifications to the kernel and android (I assume), for any released binaries, but they can be a little slow. The JB stuff should be out soon, in theory. Hopefully that's enough to get everything working, but you will also need any binary drivers from nVidia etc.
It's a long road, and you'd do well to start with something working and work backwards towards AOSP.
I'm not sure what you mean by not even with AOSP, do you intend to create your own OS?

BenPope said:
You can branch cm10 and build that, it's a good place to start, you'll learn a lot.
After that, you may want to say, diff the AOSP kernel against a similar HTC kernel to see how many changes you'd be required to make to pure AOSP to get it to work with all the hardware specific bits.
Due to GPL, HTC are required to release the source modifications to the kernel and android (I assume), for any released binaries, but they can be a little slow. The JB stuff should be out soon, in theory. Hopefully that's enough to get everything working, but you will also need any binary drivers from nVidia etc.
It's a long road, and you'd do well to start with something working and work backwards towards AOSP.
I'm not sure what you mean by not even with AOSP, do you intend to create your own OS?
Click to expand...
Click to collapse
Thanks for the thorough information! If it is possible to create your own OS, then yes, it would be awesome. Actually my idea is to make a ROM similar to the Linux distribution Tiny Core Linux; only the most essential stuff are present and bloatware and other features are removed. It could maybe serve as a good starting point for other ROMs to build on that want a minimalistic base. However, that is very, very far into the future. Now I would just like to compile a ROM that I have developed. But as I said before, if possible, skip AOSP and build my own OS definitely! Is that even possible?

Of course its possible, Android wasn't invented by some higher being or alien lifeform.
Nobody would use it though, because there would be no apps.

BenPope said:
Of course its possible, Android wasn't invented by some higher being or alien lifeform.
Nobody would use it though, because there would be no apps.
Click to expand...
Click to collapse
I see, so I am locked to AOSP then? i better start with the CM branch, thanks a bunch.

[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] Why is ROM-cooking so hard?

Hi!
I have great respect for the people that give us our great ROMs, and i KNOW that that is hard - but my question is: why exactly is it that hard?
This is just a question out of curiosity, because I would really like to understand the unerlying problems that cause all the other issues.
I was under the impression that the Android stack runs on top of the Linux kernel.
Usually, the Linux kernel is the Hardware Abstraction Layer, and apps and ROM, in theory, should be kind of hardware agnostic?
e.g. the Bluetooth Issue on our Captivate Glides: I would guess that Android communicates, through some API, with the kernel's BT stack/driver. There must be some (open or closed source) driver available (worst case: some .so module ripped out of an official ROM, maybe?). So why does the headset profile not work? Did the APIs change? Are custom ROMs forced to use another version of the driver?
It also happens to this 50$ chinese tablet i have here: some ROM screw up the touchscreen, some break audio, and so forth. Why can't there be some way of installing a generic ROM, and then side-loading the OEM's drivers?
Thank you again to all ROM developers! This is NO WAY a complaint. Just pure curiosity!

I may be out of my league when trying to describe this, but the processor in our phones is somewhat different to the processor in the bulk of other phones. This is where majority of the issues came from in porting ICS to the glide before ATT released it. Even after the first official ICS update, the modders here were the ones who fixed the keyboard lights... I changed up to JB because the GPS wasn't locking quick enough and PACROM had all the quick toggles and the speed/gps lock I needed.
Sure the kernel is the underlying part that pulls it all together, even still there is all the drivers that need to work with it. If there isn't a bluetooth/wifi/HW Video driver for the version of the kernel, then it gets really tricky and now its coding for a piece of software to speak with the hardware ..... We have things that partially work, but not fully ...as with everything computers, in theory things that "should" work, don't always... I'm an IT tech.. I run into weird **** all the time that "should" work ... takes time, but with persistence and the right skillset, majority of the time a resolution can always be found.