[Galaxy S Plus I9001 Android Development] skywalker01:
I would be glad if you could continue the whole kernel project. You already know that the source of SkyHigh (V1.4) is completely published on github ? And I will send you a PM with additional information and links later.

That will be true for sure.

Oh yes, nothing can be more true that that ;)

That's why I always say Java is complete rubbish. And that's also the first thing you will learn about programming languages when you start to study computer sciences. There are only two reasons why Java is so successful and most companys love it:

1. it's free, with some minor exceptions no license fees have to be paid

2. it's mostly hardware independent and therefore runs on most platforms; but this feature comes for an extremely high price which is horrible slow performance

That's a very subjective opinion. It is the most popular for sure and it is also very performant. But personally I hate the syntax.

Well, I know AutoIt very well because I'm using it for years now. But many of your statements above are wrong unfortunately:

AutoIt is written in C++, that means its source code is in C++ but the syntax of the Autoit language itself is nearly the complete opposite of C. C is a very beginner's unfriendly language and hard to learn while AutoIt is a very easy to learn language like you state correctly.

But this is due to the fact that the AutoIt language syntax is based on BASIC and not on C.

BASIC is an abbreviation for "Beginner's All purpoSe Instruction Code" and like the name implies it was especially made for beginners to help them in learning the first programming language which should be rather easy compared to others. C was created primarily for efficiency and performance.

And like Java AutoIt is an interpreter language which are all very slow as I already said. The AutoIt compiler is like the Java compiler, it only generates bytecode which is executed by a runtime engine that is packed into the exe file by the Aut2Exe tool.

The purpose of compiling an AutoIt script is NOT to gain performance but only to make it executable on machines that don't have AutoIt installed. Therefore it isn't really faster than interpreting the native script.

For the last point: AutoIt is just a scripting language, NOT a classical programming language. It was first designed to automate some recurring tasks in the windows GUI, that means installing software and windows itself by automatically clicking through the install wizards and filling in fields with the always same options. It later became a very powerful scripting language for scripting virtually everything (scripts are aka macros or batch files).

But it is still single-threaded and therefore has some limitations in general.

It is great for automating a lot of administration tasks and I also used it many years for that purpose.

But it never was and still isn't a programming language to code any standard applications or even games which mostly need a lot of performance that simply can't be delivered by interpreter languages.

Oh no, sorry, but this is complete nonsense.

Which proves that you totally misunderstood something. ;)

OK, let me explain: neither smali nor Java produces scripts. You first must understand the differences between scripts, bytecode and source code and also between interpreters, compilers and any hybrid forms of that. AutoIt and Java are very popular examples for such hybrid forms, Java neither uses a native interpreter nor a native compiler. To understand the decisive differences you must first learn everything about interpreters and compilers. So this is like learning Russian and Polish. Both are Slavonic languages so there are a lot of similarities. But also a lot of differences, one very obvious already is the different script. The relationships between compilers and interpreters (and hybrid forms of these) are of the same nature (many similarities but also many differences). The same is true for scripts and source code.

Well, that's because it is reverse engineering only. And I already told you what reverse engineering means: the highest dose of pain that you can get in software development. ;)

Just to clarify: nobody really codes in smali syntax. smali and baksmali are used only when you don't have the original Java source code but still want to modify the already precompiled bytecode (that's dex code in Android).

If you had the Java source it would be much easier to modify and recompile that. Which also means that you will never use smali and baksmali for compiling any Android sources (AOSP, CM, whatsoever).

It is only meant for MODIFYING existing compiled Java bytecode, that is executed by the dalvik engine. baksmali is a disassembler to disassemble (reverse engineering !) the precompiled Java code. baksmali produces an intermediate stage code that is human readable (while bytecode isn't human readable at all). Theoretically it is then possible to revert this back to original Java source code but practical this is much to complex and will always be very buggy. It is a similar problem as with translating spoken languages. Did you ever translate a quite long Russian or Chinese text with Google translator or similar to English or to your native language ? Just try and laugh at the result.

You have to modify and correct a lot to transfer this automated translation into real English and it is the same problem with decompiling bytecode (or machine code) into the original source code.

So what you do is modify this disassembled bytecode and then assemble it back to Java bytecode. smali only does this reassembling of the modified baksmali code.

So you will never ever use smali or baksmali in original Android development. The only exception is when you don't have the original Java source code but only the bytecode in dex files but want to use and modify that part.

But that's reverse engineering and modding/patching, NOT open source development.

Hope this is clear now. ;)

Can't follow on that one. There are only used 3 different coding languages in Android (and some scripting languages). This is just a wee bit compared to standard systems like Linux and Windows which use dozens of coding languages especially for all the third-party applications.

And I don't see why this should be a limit for improvement.

This is true for sure. But then it would have the same problem as Linux for example: hardware platform specific code and therefore a complete mystery for 99% of all potential users.

That's also true. But "closest" and "very similar" is something completely different than "identical". I just complain that nearly 99% of all I9001 users always confuse these words and therefore draw pointless conclusions from that mistake.

I really wish there would be more users that are such realistic and enlightened by simple facts and reality. ;)

Are you saying that you are studying at a university or such ? Which discipline and which semester ? Or do you just mean personal studies ?

Wow, that's the right attitude. :D

OK, I'm looking forward to that.

That's the best method for the libraries like I already said, nothing to worry about.

Well, don't focus on the folder contents itself, have a look into the CM makefiles and try to understand what CM does with the vendor folder files and why it does that.

Another simple fact that many users don't seem to understand or don't want to understand. Without giving names there were different guys here that told me how enthusiastic and how smart and fast learners they are and that they want to build AOSP (GB) and CM7 for the I9001 on their own and I just should tell them what to do. I told them a lot of stuff but also warned them that they are totally underestimating the complexity of such a project because they don't even had any programming skills. To achieve these skills on a sufficient level will already take at least 5 years IMHO. But nobody wants to hear that.

So let the facts speak for themselves. Most of these requests are more than 6 months ago, do you see any results at all now ?

Look above, basics of programming: about 1 year. Whole story: about 5 years. Just my humble opinion and experience ;)

Wise decision :laugh:

Oh yes, that would be just perfect. I will upload V1.5 source code later and send PM :highfive:

Now you experienced my major problem yourself. This post (and many others) took me even much longer. :silly: