[Galaxy S Plus I9001 Android Development] skywalker01:
Thanks again for all your appreciation (like always) but I have to make an announcement to everyone who answered here:

the only reason why I give those long explanations is to encourage everyone who reads them to try to develop something on their own.

But since a huge lack of spare time is my crucial problem and writing such tutorials and essays is a bigger time killer than development itself - like I already tried to explain in previous posts - continuing with these long posts would be completely contrary to intention and my personal needs.

I really have a lot of numerous duties in my "real" life and continuing here would mean neglecting those duties as well as closely related persons.

So I hope that everyone understands that I have chosen to concentrate rather on real life than on xda which means that I just can't put most proposals here into action.

But don't hesitate, I also decided to give you the latest kernel V1.5 but remember that the practical differences are quite limited. Regard it like a service pack for windows, all the features are the same as in V1.4d. And there is an additional BigMem version. That's all what you will see unless you have a peek into the source code. There are hundreds of changes for stability and efficiency but no new features.

Like I also mentioned already I didn't test the new version thoroughly. So I will NOT publish it before I'm sure that there are no major bugs in it and my proposal is that I will give it to some beta testers first that can test it on their own phones and give me short reports if they found something strange AND different to V1.4d.

So any volunteers may send me a pm and I will give you a copy of V1.5 or V1.5bm or both for testing.

Well, honestly I doubt that this is the real reason. It's all about money: development costs a lot of time and staff and therefore a lot of money.

Only major devices - that means with a high selling rate - and those who use the same hardware as the bestsellers (not much additional development necessary) will be updated for a long time and even with major updates like new os versions.

Since both conditions don't apply to our I9001 it would be economically inefficient by the manufacturer to do it anyway and it would be rather silly by the customers to watch for this to happen ;)

So just take this as an advice when you buy your next device (of any type that can be updated, so this is even true for software based TVs for instance !): if you want major updates and long time support buy ONLY bestsellers and never niche products or low budget products like the I9001.

This may sound unfair, theoretical, flashy or whatever but reality and experience proof that this is the only reliable method.

I totally agree with that. Guess what I am running ;)

First I customized my GB stock ROM and since this wasn't enough I took manveru0's Feacore Phoenix kernel. But when he stopped his development the kernel wasn't yet good enough for my personal demands so I continued his work primarily to suit my own demands.

Remember that even back then I only published my kernel in an own thread due to public demand and I still had a lot more spare time than today.

Sorry, but it is exactly the other way round. Native interpreters are always slow as hell. Only compilers (and assemblers) will deliver rather fast executable code.

Since Java is an interpreted language and therefore has natively a tremendous performance problem this is usually boosted by precompilation.

The Java source code will be first "precompiled" by the Java "precompiler" into .class files. Then Google uses the dx tool (dexer, part of Android SDK) to translate the .class files into Dalvik's proprietary format ie. to dex code, so that's the precompiled Java bytecode. This Java bytecode is packed into the apk files you execute in Android.

If you start an App (which is an apk file) the dalvik engine will unpack the apk file and execute the precompiled Java bytecode (which resides in classes.dex). It should be very obvious (if not tell me and I will give you another hint) that this is MUCH faster than interpreting native Java source code. But it is still much slower than compiled executables of a "real" compiler language like C or Pascal and all their derivatives.

So what about smali now, what is it actually ?

Well, just have a look on Google's developer pages, I'm just citing here:

"smali/baksmali is an assembler/disassembler for the dex format used by dalvik, Android's Java VM implementation. The syntax is loosely based on Jasmin's/dedexer's syntax, and supports the full functionality of the dex format (annotations, debug info, line info, etc.)

The names "smali" and "baksmali" are the Icelandic equivalents of "assembler" and "disassembler" respectively. Why Icelandic you ask? Because dalvik was named for an Icelandic fishing village. "

Can you see now what smali and baksmali actually do ?

Just in case one additional hint: on which platform(s) run(s) smali/baksmali and why is your statement above about smali not really correct ?

Of course, but I already commented on this, did you read that ?

http://xdaforums.com/showpost.php?p=33442132&postcount=499 (last lines)

Maybe yes, maybe not. But I'm repeating this now for the thousand and first time I guess: i8150 and i9001 are NOT so identical like 100% of the users here think. Many sensors including camera sensors and sound processing are completely different just for instance. You MUST look at the kernel sources to see the numerous differences. If you don't do that or don't understand the differences between ANCORA and ARIESVE in the source code I doubt that it is possible at all to compile a fully working AOSP for the I9001 (without CM or other custom AOSP files that is).

That's only one fact about layers you must learn IMHO. Layers are EXTREMELY important since nearly everything in computers works in layers of some kind. It's one of the basic principles of software engineering and you can find it almost everywhere. In protocols like network protocols (OSI model !), http, printer protocols and so on, but also in interpreting and compiling software (see above, "compiler construction").

But these are all very complex topics and most of them fill at least one complete semester if you study computer sciences. That's why I always say you need YEARS just to learn the basics. And I think you are the only one in the I9001 forum who should be able to confirm this because you are trying for a whole year now and AFAICS you are also the only one who started from null and actually still continues and didn't give up just after a few weeks or months like all the others that contacted me for starting help (and I gave 'em a lot of it).

Well, but that's exactly how it works. I'm doing nothing else, that's the reason why it is so time consuming. This is mostly reverse software engineering and this is the most painful discipline you must know. Honestly, I can give only one advice there: if you can't stand it leave it.

But if you still want to continue this is what you should know and do:

the framework is mostly only cosmetic, written in Java and therefore hardware independent (!!!) as well as not part of the libraries.

So I actually have no idea what's your problem with the framework and why you are so focused on that part. From my point of view you are looking in the completely wrong places there. But I also don't know the vanilla AOSP source as mentioned before, so can you provide me some more details (compiler error messages that involve the framework sources for instance) ?

The problem are the libraries primarily. There are two solutions for that:

1. modify the source code of the Google standard libraries. If there is already some leaked source of the hardware manufacturer somewhere you are lucky and can use it. Otherwise reverse engineering and debugging are the only possibilities. The kernel driver source and the library sources of similar hardware are your only references. But IMHO you need very advanced programming skills and experience for that.

CM is a very good source for such already modified library sources so it is not only OK to use them it's even the best method.

2. the easier method is to use the already compiled libraries (.so files) that already come with the stock ROM of the device.

But there are a lot of difficulties that can come with this method which are often unsolvable. I bet you already experienced some of these problems, incompatibility (with the other AOSP libraries) is the primary one. If they are compatible you are lucky, just look at the vendor folder of already working CM devices. It is mandatory to fully understand the concept of CM's vendor folder and how it is integrated into CM compiling because IMHO this is the only method that a non-programmer can use to make AOSP work on a device that isn't yet fully supported by any AOSP sources.

You're welcome and I hope these explanations were not too discouraging, as I mentioned above they should be encouraging.

But I also don't want to raise false hopes and as a final conclusion and advice I want to tell anybody my honest opinion: I already told others here that they are completely underestimating the complexity of OS development and I will try to explain now why this is true.

Just imagine you want to learn a new (spoken) language like Russian. If you are already a speaker of another Slavonic language like Polish and so on this should be much easier so in this case take instead Chinese for instance.

If you want to speak it really well and professionally, let's say to become a translator, you will also need years for that. And you can bet your a** that learning the basics of software engineering isn't easier than that.

And when you are trying to modify a whole operating system or doing reverse engineering which both belong to the premier class of software engineering these basics still won't be enough by far. While these rudimentary basics might already be enough for Java development they are only the first mandatory step for OS development and reverse engineering.

Staying with this metaphor I will try to explain what you are actually asking. You ask how to compile ('translate') AOSP ("bible') for the I9001 ('into Russian'), where to start and what's the most efficient way. So it is like asking how to translate the bible into Russian.

The answer for that question is very easy: learn Russian first, and learn it very well. When you have done that, then you know automatically how to translate the bible (and anything else) into Russian, where to start and what's the most efficient way to do it.

There is no way to do it without learning the complete language and there is no way to just learn how to translate a single book. At least no way that I am aware of.

It's the very same with OS software development like I tried to explain above. You must read and learn the whole "story", there is no "partial" or "selective" way. Sorry if this sounds pretentious, but along with the advices above I can't give you a more honest and much better answer than that.

So there is still a very long path ahead of you and you have to make a decision. Do you really want to trudge through all of it till the end or do you rather take the next exit and continue with something less tormenting and more rewarding like scripting and modding. The latter ones are also the first steps in learning the basics of programming and you already know a lot of them, don't you ? So it would be a good opportunity to abandon that I9001 AOSP project in favor of more promising projects. A new GB kernel for instance, hahaha. But that's completely up to you and just a possibility to consider. :D