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
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
I've been searching for about an hour now and haven't found a thing. I think I'm missing something extremely obvious but I'm completely stumped. I'm trying to simply create a new android project in eclipse from an existing source, the Launcher found in the android 2.0 source. It creates the new project with no problems and everything looks like it is supposed to look except I have about 74 errors among various different classes. I've looked through some of the errors and many are variables that haven't been declared and others are references to classes that don't exist. I've tried numerous times with several different app sources with the same problem in every single app. I've even tried downloading the source for separate apks and the same thing happens. What am I missing?!
I'm pretty new to coding android apps but decent with java. My biggest problem is just getting the apps to compile without even making any modifications yet! Any help is appreciated
matt_stang said:
...I'm trying to simply create a new android project in eclipse from an existing source, the Launcher found in the android 2.0 source...except I have about 74 errors among various different classes.
Click to expand...
Click to collapse
The android.jar which is linked in to the project by ADT only exposes the public Android API (as seen in the official documentation.) Launcher, and other "system" apps included with the platform, almost invariably access a number of private APIs which are not exposed in the SDK, and cannot be built with ADT--at least, not easily.
As it turns out, android.jar can be edited to expose all those private APIs, which is something Brut.all has worked on as part of apktool, but he hasn't done this for an entire android.jar.
Your other alternative--and practically speaking, the only current alternative--is to build it the official way, by compiling a complete platform on Linux using the full Android build process, and including your Launcher customizations. After building the whole system once you can build just the desired APK, as I understand.
olearyp said:
The android.jar which is linked in to the project by ADT only exposes the public Android API (as seen in the official documentation.) Launcher, and other "system" apps included with the platform, almost invariably access a number of private APIs which are not exposed in the SDK, and cannot be built with ADT--at least, not easily.
As it turns out, android.jar can be edited to expose all those private APIs, which is something Brut.all has worked on as part of apktool, but he hasn't done this for an entire android.jar.
Your other alternative--and practically speaking, the only current alternative--is to build it the official way, by compiling a complete platform on Linux using the full Android build process, and including your Launcher customizations. After building the whole system once you can build just the desired APK, as I understand.
Click to expand...
Click to collapse
But I already have the whole system built on my mac.. so maybe is it a matter of pointing the project to the right directory for the private APIs? Or importing a android.jar from the built source to the project..? I'm very confused
matt_stang said:
But I already have the whole system built on my mac.. so maybe is it a matter of pointing the project to the right directory for the private APIs? Or importing a android.jar from the built source to the project..? I'm very confused
Click to expand...
Click to collapse
There is no android.jar with what you're looking for. If you already have the entire platform--either http://android.git.kernel.org/ or the CM source repository--just modify that, then build from the command line. AFAIK, you have to build from the command line, though, using `make'.
olearyp said:
There is no android.jar with what you're looking for. If you already have the entire platform--either http://android.git.kernel.org/ or the CM source repository--just modify that, then build from the command line. AFAIK, you have to build from the command line, though, using `make'.
Click to expand...
Click to collapse
That makes a lot more sense. Thanks
Hello.
I'd like to automate XAP deployment from my development environment to WP emulators running for testing. WP emulators are running as Hyper-V VMs and they have a valid IP. As much as I understand communications between MS tools like Visual Studio 2011 Beta and WP are TCP/IP based. So, I wonder what is hiding behind the "Deploy" button? Some PowerShell command? Anything else? For starting I'd like to upload the XAP and install it on the Emulator and eventually the device.
Thanks.
There are third-party deployer apps, so what you want is entirely possible. You'd have to look at the source for them, though, and then write your own that listened on a network socket for the file that it is supposed to install.
GoodDayToDie said:
There are third-party deployer apps, so what you want is entirely possible. You'd have to look at the source for them, though, and then write your own that listened on a network socket for the file that it is supposed to install.
Click to expand...
Click to collapse
Due to security restrictions I still cannot post to developers forums, so I'll try to ask here:
are these applications like Tom XAP installer or Multi-XAP installer Open Source, or what? They are distributed in a compiled form so how I can ask their developers for the source code?
There are any number of programs that can decompile managed assemblies (JustDecompile, for example, but there are a bunch and many are free). It's nice to ask for source (and some of the apps are probably open-source; you can look for the tag [SOURCE] or similar in the thread title) but unless they obfuscated the assembly for some reason, decompiling well enough to understand what it does is easy.
Hello,
I am posting to begin a thread regarding the native compilation and execution of OpenCL code on an ARM Android device, namely the HTC One M8.
I have used the app Linux Deploy to install a Debian desktop environment alongside Android, sharing the same Linux kernel but supplying different runtime libraries. Additionally, I have installed gcc/g++, Code::Blocks, and the OpenCL ICD and header files necessary to compile a native binary.
My intent is to continue developing a graphics render algorithm, but if I can get a working Android binary from g++ on a GNU toolchain, I would be happy to share generalized source code so that others can do the same with some simplicity.
Currently, I have success compiling a binary with shared libraries for GNU/Linux, but it does not detect the OpenCL devices on my system. I tried statically linking my application, but it refuses to link OpenCL statically.
The way I see it, there are two ways to solve my problem:
1) I assume Debian cannot see devices due to a driver issue, but I could be wrong, and I don't believe appropriate GNU drivers exist at this time. (Please correct me in a response if you know this to be false.) I have talked briefly with some of the folks from the Freedreno project, and it seems the OpenCL compiler is the biggest missing piece between the driver and the hardware. Unfortunately, I do not know if a working driver would even solve the issue in my case.
2) Compile binary with Android shared libraries. This may be most easily done with Eclipse, but I prefer Code::Blocks, so if the libraries could be linked in, then it may be trivial to change IDEs. I suppose it depends entirely on how the NDK handles compilation.
Option 2 is most likely the best course of action. I intend to publish my progress in milestones. Discuss.
XDA:DevDB Information
PLoW, Device Specific App for the Verizon HTC One (M8)
Contributors
Agenthex, agenthex
Version Information
Status: Testing
Created 2015-01-03
Last Updated 2015-01-03
Answer to your question = Mint 17.1 Works for me and this should be in general as this has nothing that you created.