Related
Check it out here:
http://android-developers.blogspot.com/2009/06/introducing-android-15-ndk-release-1.html
Yes, I heard they were making this actually happen...
As for building Apps in C/C++ Native..
Pros:
-More Stable
-More Unique (no Android UI features unless integrated)
-More Sophisticated
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
-Other open sourced / commercial apps will be more easily ported...some ideas?...START A THREAD!!!...but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
-Remember, this is a Development Kit...it just adds tools to the 1.5 SDK that allow you to create C based applications and build them in the android environment. All your apps should still work going back to RC-30 or even further back...depends on the kernel support I would guess.
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Other:
Load times? Ok, so for example if you have one app...say...TuneWiki...just an example of a popular resource hog...if it were to be redeveloped under C++ and optimized for the Android Modified Linux Kernel...your resources could easily be cut in half since you are not relying on the Dalvik VM.
SO...outcome?
Better for all, as long as you know what you are doing.
We should also see a huge upswing in crapware on the market from student programmers doing C++ projects on an easy open-sourced mobile platform (that has a public SDK).
So you'll see a lot of "Hello World" type apps that will have next to no function...have fun with those...................
From the Official NDK User Forum: Link
acidnine
Very nice post. Thanks for the insight.
acidnine said:
Pros:
-More Stable
Click to expand...
Click to collapse
The opposite actually. Poorly written interpreted code breaks elegantly in a vm. Poorly written compiled code can take a whole system down.
-More Unique (no Android UI features unless integrated)
Click to expand...
Click to collapse
You can't integrate any Android frameworks (UIs, etc) period.
-More Sophisticated
Click to expand...
Click to collapse
I've seen some very sophisticated Java and some **** C/C++. Don't assume that higher level programming languages are necessarily less sophisticated than lower level ones.
-Will open to a more known (learned) framework, by this I mean if you know C/C++ and already have apps built for other mobile devices it should be much easier to port it over to Android (look out for the flood Android Market)
Click to expand...
Click to collapse
The NDK will enable some applications that couldn't previously have been done in the Dalvik vm for performance issues, but it isn't going to be a "flood". Fact of the matter is a lot of developers who have needed native performance or didn't want to rewrite a C/C++ codebase have deployed native code already.
but just for the record...Apache...FireFox...just about anything that has an open source that relies on C programming...crap you can even extend this by adding Ruby, Perl...etc.
Click to expand...
Click to collapse
FF is written in C++... [edit: I should also point out that the NDK provides for native code support in the form of libraries (mainly as a helper for computation-intensive functions). Nothing in the way of window managers or other UI is addressed, meaning for the majority of "visible" C/C++ apps the developer would have to rewrite a significant portion in Java still.]
Cons:
Much Larger Apps (file size)
Need to learn how the Linux Kernel works (for developers)
Click to expand...
Click to collapse
I don't know what to say other than these two statements are generally incorrect. There are two main cons to using NDK as opposed to the standard SDK, and they are 1) Reduced (or no) compatibility on future Android devices 2) Significantly reduced ease of debugging.
very interesting...subscribed
jashsu said:
You can't integrate any Android frameworks (UIs, etc) period.
Click to expand...
Click to collapse
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
The NDK provides:
A set of tools and build files used to generate native code libraries from C and C++ sources
A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
Documentation, samples, and tutorials
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Click to expand...
Click to collapse
.milFox said:
Not true. This isn't full native code apps, this is the ability to call native libraries in a davlik app.
From the actual NDK page ...
Click to expand...
Click to collapse
Correct. As I pointed out above, the NDK actually is just a framework for building native libraries that standard dalvik apps then call. However, my point was that the libraries themselves (the products of the NDK) cannot access or invoke the Android framework. There is a pointed distinction.
At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.
neonrush said:
At least this could mean the beginning of some video codec porting to the G1's hardware. Be nice to be able to actually make use of my video collection without having to reencode everything.
Click to expand...
Click to collapse
That is probably what the NDK is perfect for. It's CPU intensive stuff, already written in platform independent C/C++ that can then be called from within a nice Androidy UI.
So they basically added JNI to the SDK...
http://en.wikipedia.org/wiki/Java_Native_Interface
Hello,
Do you know that it is possible to enable JIT in Dalvik JVM?
http://groups.google.com/group/0xlab-devel/browse_thread/thread/1edef26f4e5b7427
According to the Dalvik developers it is possible to backport JIT to the Donut tree and gain ...1.74x in performance!!! It would be awesome if someone could spend some time and create a ROM with that patches applied.
Anyone?
Karol
I think you misread somewhere.
It is a *new feature* they are *adding in*. The current JIT in AOSP/master is in development (i.e. incomplete). You can play with it if you want, but you should consider this to be a future new feature that will be added to official builds.
Well, I though that this is xda developers forum, place where even experimental Android features are welcome (vide extra memory hack and others...
And while English is not my native language I doubt that I have misread it. The current master tree ALREADY contains JIT implementation PLUS there are patches which allow using it in the Donut tree. So even though it is experimental it is worth checking out because it apparently it can be compiled and tested...
I would do this by myself, but since a week or so I am unable to update my donut tree, I am getting "fatal: The remote end hung up unexpectedly" messages
The current master branch in AOSP is eclair. If you use repo to sync the AOSP source, then build, the branch it pulls out (according to the output from envsetup and the lunch menu I receive) is eclair (2.0). I doubt that the donut branch has the code for the Dalvik JIT.
It *may* be possible to backport it to donut (1.6), but why when 2.0 is running on the Dream except for some AV/codec issues without problem?
Let me quote developers behind JIT in Dalvik....
NOTE: the results were measured in Donut based environment. That is,
there are some changes for Eclair backport to Donut without replacing
the libcutils and bionic, which were modified a lot in Eclair.
If you would like to introduce Eclair's Dalvik VM in Donut based
products (especially for 3rd-party components compatibility), feel
free to apply the attached patches and rebuild Android.
Here are the instructions:
# cd android-donut
# mv dalvik dalvik-orig
# . build/envsetup.sh
# git clone git://android.git.kernel.org/platform/dalvik.git
# cd dalvik
# git apply dalvik-eclair-backport.patch
# mm
# cd ../frameworks/base
# git apply frameworks-base-eclair-backport.patch
# mm -B
# cd ../../
(Do copy out~system to your target.)
Click to expand...
Click to collapse
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
karolbe said:
Let me quote developers behind JIT in Dalvik....
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
Click to expand...
Click to collapse
Ah, I stand corrected. It looks like it is indeed workable to get 1.6 with a JIT Dalvik. However, once HTC (or Qualcomm) releases the needed A/V drivers, 2.0 will be fully functional on the Dream. But, this might be nice in the interim.
Is that just the Eclair Dalvik version, or is it also the JIT-enabled Eclair Dalvik?
There /is/ a difference between the two.
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Yeah, I tried it out, and the phone seemed to be less responsive. When I tried to install an app the phone rebooted, and now it seems to be booting to a certain point and then shutting down again. Nice progress though.
cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Memory Hog.
That's what I was afraid off, that a JIT would hog memory. And if there's 1 thing that my G1 is really short of, it's memory. RAM for running applications. So no please no more memory hoggging on my G1! ;-)
I'm afraid that memory hogging is kind of unavoidable for a JIT.
Just my 2ct.
--Tim
Anyone tried this with the memhack and CompCache running?
EDIT: Running it myself now. Can't see any lagginess; everything seems to be running quite snappily. Going full-time with it now.
I haven't done any java stuff for a while, so I might be off. Anyways, since this is a vm library change, I assume it runs in mixed mode (dynamnically compiles the java byte code when needed), which may cause performance issues. Is there a way for us to pre-compile all the java code in the apps with jit? and have the apps run natively without the dalvik vm at all? This would be the most desirable. I think the biggest weakness in android is the dalvik vm. It is a huge memory hog. If we can use jit to compile the apps into native instructions then theoretically we shouldn't need the vm to run at all.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
Click to expand...
Click to collapse
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
A bit of ignorance is a compliment. Like I said I have not done any java work for a long time. What I don't understand about jit the way it is done, is why not go all the way and generate the native code similar to the odex files, and just by pass the vm all together. If they are going to the trouble of compiling byte code into native instructions anyway.. why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
IConrad01 said:
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
Click to expand...
Click to collapse
why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
Click to expand...
Click to collapse
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
I'm trying the libdvm.so cyanogen posted on my 32A magic (288MB of RAM) and so far it's all working well, and it seems much faster
Using 4.2.5 on 32A Magic with 4.2.4 Radix Kernel with New JIT Based libjvm.so
Everything Works Well and Never had any Force Close but is that 4.2.4 Kernel from Radix actually uses JIT.
@cyanogen 32A have 288 MB ram i can test JIT based Dalvim if you want me to test it
Ok, I integrated this lib with Cyan 4.2.5. Running comp-cache and Ram hack, 16GB class 2 SD.
Initial impression (based on 20 minutes of playing);
No change in OS speed. No crashes yet. Apps (especially game emulators) have a noticeable increase in speed. I have no technical information to back up my claims, nor do I have the possibility of an ABX comparison. Sorry.
Thanks for the explanation, I buy #3 as far as security is concerned, we all know those virus taking advantage of overflow instructions in windows. But As for #2 I don't mean to have developers compile the byte compile to native, but have the vm on our phone compile it on first run and save the native instructions in file similar to how it generates the dex files on first run. This way it'll not have to recompile every time it runs. I just wish there is a way to avoid the dalvik-vm.
I irks me how much memory the dalvik-vm hogs up. A simple battery widget takes 12-16mb of memory.. It has a few pics and bytecode that simply goes to the system driver go get a number. I mean the whole ext3 filesystem driver uses less memory. Same with those widgets for task killing, they take up well over 10 mbs, which kind of defeats the whole purpose. I could write a simple tiny script that uses kill and do the same job without taking up 10m+ in the background.
We all here complain about our hardware, but I feel like these are more of software problems. anyways, that's just my rant... i hope the memory issues in vm gets better in later release.
IConrad01 said:
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
Click to expand...
Click to collapse
cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Could anyone upload that again? The link is dead.
Android Games WILL be improved thanks to NDK r3 and OpenGL ES 2.0
Developers on the Android platform have already been pushing the boundaries of Android gaming. Even Quake 3 has been seen running on the Android platform. Things can only get better with today’s announcement.
The Android Developers Blog today announced the availability of the NDK r3 that will let android developers directly access OpenGL ES 2.0 features.
Applications targeting Android 2.0 (API level 5) or higher can now directly access OpenGL ES 2.0 features. This brings the ability to control graphics rendering through vertex and fragment shader programs, using the GLSL shading language.
A new trivial sample, named “hello-gl2″, demonstrates how to render a simple triangle using both shader types.
With access to these enhanced OpenGL ES features game graphics should be greatly improved and we should start to see an awesome future for Android gaming. Obviously, we still need developers to take advantage of the new API and have the hardware powerful enough to use it, but everything is getting real close to serious gaming on Android.
Source: Android Developers Blog
Source: AndroidSPIN
-----
What is the Android NDK?
The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.
The NDK provides:
* A set of tools and build files used to generate native code libraries from C and C++ sources
* A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
* A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
* Documentation, samples, and tutorials
This release of the NDK supports the ARMv5TE machine instruction set and provides stable headers for libc (the C library), libm (the Math library), OpenGL ES (3D graphics library), the JNI interface, and other libraries, as listed in the section below.
The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity. Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Contents of the NDK
Development tools
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
It provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:
* libc (C library) headers
* libm (math library) headers
* JNI interface headers
* libz (Zlib compression) headers
* liblog (Android logging) header
* OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
* A Minimal set of headers for C++ support
The NDK also provides a build system that lets you work efficiently with your sources, without having to handle the toolchain/platform/CPU/ABI details. You create very short build files to describe which sources to compile and which Android application will use them — the build system compiles the sources and places the shared libraries directly in your application project.
Important: With the exception of the libraries listed above, native system libraries in the Android platform are not stable and may change in future platform versions. Your applications should only make use of the stable native system libraries provided in this NDK.
Documentation
The NDK package includes a set of documentation that describes the capabilities of the NDK and how to use it to create shared libraries for your Android applications. In this release, the documentation is provided only in the downloadable NDK package. You can find the documentation in the <ndk>/docs/ directory. Included are these files:
* INSTALL.TXT — describes how to install the NDK and configure it for your host system
* OVERVIEW.TXT — provides an overview of the NDK capabilities and usage
* ANDROID-MK.TXT — describes the use of the Android.mk file, which defines the native sources you want to compile
* APPLICATION-MK.TXT — describes the use of the Application.mk file, which describes the native sources required by your Android application
* HOWTO.TXT — information about common tasks associated with NDK development.
* SYSTEM-ISSUES.TXT — known issues in the Android system images that you should be aware of, if you are developing using the NDK.
* STABLE-APIS.TXT — a complete list of the stable APIs exposed by headers in the NDK.
* CPU-ARCH-ABIS.TXT — a description of supported CPU architectures and how to target them.
* CHANGES.TXT — a complete list of changes to the NDK across all releases.
Additionally, the package includes detailed information about the "bionic" C library provided with the Android platform that you should be aware of, if you are developing using the NDK. You can find the documentation in the <ndk>/docs/system/libc/ directory:
* OVERVIEW.TXT — provides an overview of the "bionic" C library and the features it offers.
Sample applications
The NDK includes sample Android applications that illustrate how to use native code in your Android applications. For more information, see Using the Sample Applications.
Click to expand...
Click to collapse
You can download the Android NDK: here
just waiting for it ! Good job!
Kind of makes sense now why the binary 3D driver broke from 1.6->2.0
and i most care about whether our G1 are supported ?!
huhaifan1 said:
and i most care about whether our G1 are supported ?!
Click to expand...
Click to collapse
well if the rumors about every single android device being upgraded to 2.1 in the US are true then id think so. we already have partial 3D working, so i think with this release the devs will be able to make it work
Except the chip in the G1 is not built for 2.0.
IMHO, if you'll see 2.0 drivers on the G1 (or Hero) it'll be software. But I'd love to be proven wrong, so please do.
Chainfire said:
Except the chip in the G1 is not built for 2.0.
IMHO, if you'll see 2.0 drivers on the G1 (or Hero) it'll be software. But I'd love to be proven wrong, so please do.
Click to expand...
Click to collapse
from what ive read on androidspin and phandroid, some phones will receive a slimmer 2.1 that doesnt support lwp OTA. some devs have found ways to use software libs and kernel edits to use partial 3D acceleration in some 2.1 roms. Firerat and Case_ managed to get 3D and Youtube HD working on Canon's Roms. The next OpenEclair should have fully working 3D, lwps, and video according to wesgarner, so i think that this upcoming release mentioned in the article will provide more tools for our devs to use on the G1.
but when EXACTLY - like DATE - are they coming!?
chim4ira312 said:
but when EXACTLY - like DATE - are they coming!?
Click to expand...
Click to collapse
The NDK is available now, maybe the devs should look into it:
http://developer.android.com/intl/de/sdk/ndk/index.html
What is the Android NDK?
The Android NDK is a toolset that lets you embed components that make use of native code in your Android applications.
Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.
The NDK provides:
* A set of tools and build files used to generate native code libraries from C and C++ sources
* A way to embed the corresponding native libraries into application package files (.apks) that can be deployed on Android devices
* A set of native system headers and libraries that will be supported in all future versions of the Android platform, starting from Android 1.5
* Documentation, samples, and tutorials
This release of the NDK supports the ARMv5TE machine instruction set and provides stable headers for libc (the C library), libm (the Math library), OpenGL ES (3D graphics library), the JNI interface, and other libraries, as listed in the section below.
The NDK will not benefit most applications. As a developer, you will need to balance its benefits against its drawbacks; notably, using native code does not result in an automatic performance increase, but does always increase application complexity. Typical good candidates for the NDK are self-contained, CPU-intensive operations that don't allocate much memory, such as signal processing, physics simulation, and so on. Simply re-coding a method to run in C usually does not result in a large performance increase. The NDK can, however, can be an effective way to reuse a large corpus of existing C/C++ code.
Please note that the NDK does not enable you to develop native-only applications. Android's primary runtime remains the Dalvik virtual machine.
Contents of the NDK
Development tools
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
It provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:
* libc (C library) headers
* libm (math library) headers
* JNI interface headers
* libz (Zlib compression) headers
* liblog (Android logging) header
* OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
* A Minimal set of headers for C++ support
The NDK also provides a build system that lets you work efficiently with your sources, without having to handle the toolchain/platform/CPU/ABI details. You create very short build files to describe which sources to compile and which Android application will use them — the build system compiles the sources and places the shared libraries directly in your application project.
Important: With the exception of the libraries listed above, native system libraries in the Android platform are not stable and may change in future platform versions. Your applications should only make use of the stable native system libraries provided in this NDK.
Documentation
The NDK package includes a set of documentation that describes the capabilities of the NDK and how to use it to create shared libraries for your Android applications. In this release, the documentation is provided only in the downloadable NDK package. You can find the documentation in the <ndk>/docs/ directory. Included are these files:
* INSTALL.TXT — describes how to install the NDK and configure it for your host system
* OVERVIEW.TXT — provides an overview of the NDK capabilities and usage
* ANDROID-MK.TXT — describes the use of the Android.mk file, which defines the native sources you want to compile
* APPLICATION-MK.TXT — describes the use of the Application.mk file, which describes the native sources required by your Android application
* HOWTO.TXT — information about common tasks associated with NDK development.
* SYSTEM-ISSUES.TXT — known issues in the Android system images that you should be aware of, if you are developing using the NDK.
* STABLE-APIS.TXT — a complete list of the stable APIs exposed by headers in the NDK.
* CPU-ARCH-ABIS.TXT — a description of supported CPU architectures and how to target them.
* CHANGES.TXT — a complete list of changes to the NDK across all releases.
Additionally, the package includes detailed information about the "bionic" C library provided with the Android platform that you should be aware of, if you are developing using the NDK. You can find the documentation in the <ndk>/docs/system/libc/ directory:
* OVERVIEW.TXT — provides an overview of the "bionic" C library and the features it offers.
Sample applications
The NDK includes sample Android applications that illustrate how to use native code in your Android applications. For more information, see Using the Sample Applications.
Click to expand...
Click to collapse
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Gary13579 said:
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Click to expand...
Click to collapse
sorry i probably misunderstood the article =/
im still not very experienced with android development, i thought this would help the devs a little bit with getting 3d working (since theyre already doing that without official drivers)
I did indeed get a humongous boner on reading this earlier. It was enhanced by 3D.
My favorite part about this is the new ability to use openGL in apps! That means the entire face of our OS is going to change.
...and speaking of OS... Qualcom/htc just released a new radio for the G1. The G1 To this day holds over 50% of the android installed user base. There is no doubt the G1 will live beyond 1.X
bleah writing games in opengl es 1.0 was hard enough...
Gary13579 said:
This doesn't at all in any way say that we're getting 2.0 drivers for the G1. All it's saying is that phones with 2.0 will be able to directly access ES2.0 functions.
Which, really, has absolutely nothing to do with the driver issue we face. Unless you can point out something I missed.
Click to expand...
Click to collapse
agreed
the binary still needs to be available
as far as I can see with have two
the open source one
/system/lib/egl/libGLES_android.so
and the proprietary
/system/lib/egl/libGLES_qcom.so
the quoted text in the OP is basically stating that an Android developer will now be able to mix in a little c/c++ to get direct native access to opengl es
functions
Firerat said:
agreed
the binary still needs to be available
as far as I can see with have two
the open source one
/system/lib/egl/libGLES_android.so
and the proprietary
/system/lib/egl/libGLES_qcom.so
the quoted text in the OP is basically stating that an Android developer will now be able to mix in a little c/c++ to get direct native access to opengl es
functions
Click to expand...
Click to collapse
sorry guys like i said i misunderstood =/ i was hoping the NDK would provide some help but i now see its pretty much for apps, facepalm >_<;
edited the title to avoid further confusion lol
speedysilwady said:
edited the title to avoid further confusion lol
Click to expand...
Click to collapse
Was just about to do that, thanks .
I'm sure we'll get drivers eventually, either hacked or official. Just a matter of time.
Gary13579 said:
Was just about to do that, thanks .
I'm sure we'll get drivers eventually, either hacked or official. Just a matter of time.
Click to expand...
Click to collapse
haha no problem, glad to see i have a moderator type mentality. lol
yeah im sure we will, theyre already partially working, so its only a matter of time hopefully
What Chainfire said is that there is no hardware support for OpenGl ES 2.0 in msm720x chips. (refs here, sorry couldn't find official spec datasheet).
So even if 2.0 is supported, it will only be through software drivers implementation, which means really slow rendering.
spocky12 said:
What Chainfire said is that there is no hardware support for OpenGl ES 2.0 in msm720x chips. (refs here, sorry couldn't find official spec datasheet).
So even if 2.0 is supported, it will only be through software drivers implementation, which means really slow rendering.
Click to expand...
Click to collapse
Thats right.
But most Games will probably/hopefully still be written for OpenGL1.1. (Because of the userbase whatsoever)
For a start, but to focus at the future, too bad, the G1 will get old sooner
HEllo people,
For people who have been looking for the source code of this phone recently,but are unable to download it due to the registration process at opensource.samsung.com, I am mirroring the source code! Download and Enjoy!
Source Code (127.18 MB)
PLEASE NOTE->
I will not be responsible for any bricking of the device while modification and/or addition of values to the Source Code or the Kernel.
What is Source Code?
In computer science, source code is text written using the format and syntax of the programming language that it is being written in. Such a language is specially designed to facilitate the work of computer programmers, who specify the actions to be performed by a computer mostly by writing source code, which can then be automatically translated to binary machine code that the computer can directly read and execute. An interpreter translates to machine code and executes it on the fly, while a compiler only translates to machine code that it stores as executable files; these can then be executed as a separate step.
Most computer applications are distributed in a form that includes executable files, but not their source code, which is useful to a user, programmer, or system administrator who wishes to modify the program or understand how it works.
The source code which constitutes a program is usually held in one or more text files stored on a computer's hard disk; usually these files are carefully arranged into a directory tree, known as a source tree. Source code can also be stored in a database (as is common for stored procedures) or elsewhere.
Source code also appears in books and other media; often in the form of small code snippets, but occasionally complete code bases; a well-known case is the source code of PGP.
The notion of source code may also be taken more broadly, to include machine code and notations in graphical languages, neither of which are textual in nature. An example from an article presented on the annual IEEE conference on Source Code Analysis and Manipulation:[1]
For the purpose of clarity ‘source code’ is taken to mean any fully executable description of a software system. It is therefore so construed as to include machine code, very high level languages and executable graphical representations of systems.[2]
The code base of a programming project is the larger collection of all the source code of all the computer programs which make up the project.
It has become common practice to maintain code bases in version control systems.
-> The Kernel and Source code is as seen on Samsung's website
-> Uploaded here in order to avoid regestration process on the website
-> Do NOT download this if you are not sure of what it is or how to edit these
-> Also, Do download if:
-You are planning to develop a kernel
-For Stable CM7 or Future releases
-You are studying the Code
- Bug fixing
- You are learning Kernel dev.
- You belong to the Kernel DEV. TEam of Fit!
------------------------------
CLICK ON TEH THANKS BUTTON, IT DOES NOT EXPLODE!!!
Can I change kernel is Windows or what?
No kernel developing is not supported in windows you need linux you need linux or mac os
omarhasan76 said:
No kernel developing is not supported in windows you need linux you need linux or mac os
Click to expand...
Click to collapse
VMWare or Virtual PC does the job.
Yes, Yes it does! You dont need to install Linux!
ya but its the same thing installing linux or using virtual machine
omarhasan76 said:
ya but its the same thing installing linux or using virtual machine
Click to expand...
Click to collapse
I meant the same.....
Which version/baseband ?
hey this source code is for galaxy ace gt s5830
i guess and not for fit ??
I tried to post this in the development forum, but I am not allowed.
I am tinkering with ARM architecture and Android device development and low level OS stuff. I am currently using QT C++ for Android for app development. This works great for all of my standard Android app development, but now I am digging deeper. I am doing an experiment where I have a small binary blob (64k) of ARM code that I want to load into memory at run time using mmap(). In order for this code to work, it needs to be loaded at address 0x22000000. In my C++ code i call mmap(0x22000000, ...) which would map the binary file to that address only if it were not in use already, which it is on a couple different android devices that I have tried, so it maps to another address, as it should by design. I tried using MAP_FIXED as a flag to mmap() and the application crashes, as expected, since mmap() overwrites memory that is already in use.
In order for mmap() to map the binary file to the address I want, I believe that I can do some sort of advanced Android / Kotlin / gradle level compile time linking modifications in order to make sure that the area of memory (the whole page at least I imagine) that I want to mmap() to is unused when execution reaches my C++ code that calls mmap(). I don't know the android build system very well though, so I hope some Android experts can help me. I am not trying to access real physical RAM though, only address 0x22000000 in the processes virtual address space. Because of this, I believe that with some custom hackery can be done during linking to modify the areas of RAM that are assigned for program/stack/etc use. I believe I am looking for the equivalent of LD script customization for standard GCC C/C++ compiled software, and possibly some direction on how to manipulate.
I have successfully done this on a raspberry pi running raspbian via a command line C++ application, as well as an x86_64 Fedora system using an x86_64 binary blob. In both cases I got lucky that the area of memory was not in use, so mmap() succeeded and I was able to execute the code as desired.