Database Info

Android Native Development Kit RELEASED

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

[Q] Running a C++ binary

So this is probably a silly question.
I have this rather complicated app that would be a heck of a lot of work to convert to Java.
It runs in the command line and works fine in Linux.
Trying to run it fails, but x86 bytecode probably isn't very ARM friendly.
Is there a specific way I need to compile the application?
Is it even possible to run it from a console emulator?
Thanks.

Try Android NDK
I am also new to Android Dev ( 15+ years Linux, 10+ years Java, etc.)
I am not an expert but for your purposes you need the "Android NDK" in addition to the "Android SDK" that most developers utilize.
"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++. "
Basically the tools are needed to cross compile C++ source code for the target ARM environment.
I am prevented from posting the download URL for some bizarre reason, but it is listed under "Native Development Tools" on the left side of the web page for the standard "Android SDK" download.

Yeah that's because you are new. It's a system to prevent spammers from posting URLs.
When you have a couple of posts the restriction will disappear
Anyway; found it, seems to be what I'm looking for.
I'll check it out in the morning.
Big thanks

Dmitry Moskalchukhas written a patch for the ndk to better support c++ see crytax dot net there are posts on google groups android-ndk talking about it

Thxs for the info. I was aware that the NDK did not include all of the libs that desktop Linux/UNIX developers expect. The suggested patched version adds the STL libs back in.
Sent from my PC36100 using XDA App

There are A LOT of libraries missing
I guess I'll just keep it a hosted app.
Thanks for all the input

[Q] How XAPs are deployed to Emulator and Device

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.

How to Program Own Apps in Android 4.4.4 KitKat

I am a programmer who has programmed in x86 Assembler, Visual C++ under Windows and DOS.
I need to be able to do own applications for Android KitKat 4.4.4
I need any help and information such as manuals, books, lists of commands, lists of functions, C compiler or, best, Assembler compilers for a given processor, etcetera.
I would like to code in Assembler. I guess I need an Assembler for a given processor and cell phone. In case not possible, I need a C compiler for Android 4.4.4 KitKat. I need the basic rules on how to code for this OS as well as the OS calls which I can use, as well as a description of function libraries which may come with the C compiler.
I prefer pure C than C++ or Java.
I have briefly searched the Internet with various key words and I have not been able to find anything relevant.
Please, does anyone have any information where I can get anything helpful.
I am totally new to this OS and I do not even know the shell commands. I do not have much information of the shell, although I have found a basic list on this forum and I use ls and ? and go by the name as a dumb fool.
Please, advise.

While Android is in Java, it also allows you to run C/C++ native code.
Search "Android NDK" and you will find the relevant documentation.

Arws Apps said:
While Android is in Java, it also allows you to run C/C++ native code.
Search "Android NDK" and you will find the relevant documentation.
Click to expand...
Click to collapse
Thanks. I have tried NDK. I am not sure whether I have installed this correctly but I would keep this.
Because NDK is hardware specific and I am not sure whether and how much Moto E XT1023 and others are supported, I have installed Android Studio 1.2 ad started with XML and Java. I have done similar things with HTML and Java for web sites. I would use XML as much as I can and Java only to get and set some variables, then I would use C for programming and then I would set Java variables and methods. I am not very happy with Java but there is not any other way for now. Hopefully, in the future, they would make XML a real language with all the resources available, functions and methods.

At least Java has a very C-like syntax, so in general it shouldn't be that difficult. In some sense it would even be easier (no memory management).

Arws Apps said:
At least Java has a very C-like syntax, so in general it shouldn't be that difficult. In some sense it would even be easier (no memory management).
Click to expand...
Click to collapse
Yes. You are right. I would prefer, however, a pure ANSI C. This can be done either as an interpreter to be hardware independent or as a compiler upon launch, the system would have a compiler, the user would download only the ASCI text. Upon launch, the compiler would be called first to compile and then the application can be launched. Then, the user can either keep the .exe or keep just the ASCI text, in which case, new compilation has to be done with every launch. A compilation would normally take one or a few seconds only for normal applications.

Is bare metal Linux possible?

Bit of a story here.
So I have been long into car hacking, doing all sorts of canbus related modifications to my Merc W203 model.
The stock radio is utter garbage by today's standard, and Xtrons do a ton of android head units for my car. (Either with an A35 CPU and 2gb ram, or Px5 CPU with 4gb ram).
I am wondering, would it be possible to COMPLETELY remove android from it, and instead boot something like archlinux-arm on it. I want to create some custom applications on it whilst also having full control over the entire OS (Hence the want for Linux, not android).
I do kernel development as well so I am not worried at all about devices not working, I can likely hack together a kernel driver for nonworking hardware on the unit.
I am simply looking if it is possible to wipe android and see if it's possible to use it as a bare bones PC.
Any help would be appreciated, before I bite the bullet and spend £250 on one!:laugh:

You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.

FransUrbo said:
You still need the GUI and stuff like that.
Besides, Android "is" Linux! Much better, imo, to base it off of Android, to keep the ecosystem that that comes with.
Click to expand...
Click to collapse
I am pretty sure by he said 'bare bones' does not mean an (Linux kernel based) operating system with only an command line terminal (i.e. something that looks like MS-DOS).

My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..

FransUrbo said:
My point is that native Linux doesn't HAVE "mobile GUI". It have X11, which is *NOT* (!!) suited for such a project..
So either have to port whatever GUI Android have back to Android, or write his own. Which is a *MASSIVE* (!!) undertaking..
Also, Linux isn't quite suited for mobile applications. That's why Android was created. It took all the good from Linux and made it fit a mobile application.. Reverse engineering or back porting all that work to Linux is just dumb..
Click to expand...
Click to collapse
Wait does the OP mean he need some thing like postmarketOS(some kind of Linux distribution with mobile GUI)?

Of course he does!! What do you think "Linux" is?!
Linux is *JUST* (!!) the kernel! NOTHING else.
The *distribution* is everything else. Boot procedure (scripts, commands, filesystem tools - technically that's "The Userland" - the install procedure, the packaging etc etc). Then you put your GUI on top of that.
On top of that you have X11. Or "The GUI". TECHNICALLY, X11 require some more stuff, the window manager too actually be useful. Without it (the window manager), X11 is just an API to the graphical functions - "draw window border", "draw a close button" etc etc. Which is what the window manager utilises.
So: kernel <- userland <- X11 <- Window manager <- Graphical apps
Then all of that is packaged up in a need CD/DVD/Image to make it easily installed and used. And we call that "The Distribution".
This is how UN*X works and that's how LINUX works. Simple, portable and very useful. But not for a phone, tablet or, in this case, a car!
That's why Android was created. It is ALL of that, in ONE package! With thousands and probably millions of apps compiled for it. Do it yourself, and you have to write EVERY (!) app you need yourself - radio apps, navigation etc etc ad-finitum..
Because NO ONE/THING (except in very rare occasion) "talks" to the kernel. They "talk" to libraries (libc, libX11 etc) to do what they need. Which is why you need "The Userland". THEY (the libraries) then "talk" to the kernel (networking, filesystem, input, output etc) giving the apps a nice API - "Application Programming Interface". A set of functions and tools for applications to use, so they don't have to recreate "the wheel" every time.
Now, I'm not going to go deeper, unless you want me to . I do understand that the un-initated don't know the difference between "Linux" the-kernel and "Linux" the-everything. But this *IS* important, believe it or not..
The kernel is absolutely useless on its own. It can't do squat! It was never MEANT to be used on its own. It was designed and built to be used *with* a distribution - "GNU" in the large majority of cases..
Although it's possible to use bare-bones Linux with either your own distribution (MASSIVE amounts of work, I know, I've tried it!) or an existing one (Debian GNU/Linux, RedHat, SuSE etc - they all provide binaries and packages for a multitude of processors), none of them have all the goodies that Google Play Store have.
And none of them are really targeted towards a mobile graphical environment.
Raspbian for example, was made for the Raspberry Pi, but that is in 99% of cases a non-graphical environment (robots and media stations mostly). Most distributions is like that.
The Play store on the other hand is *specifically* targeted towards a mobile, graphical environment. As this is. I would be foolish to try to reinvent the wheel when Android already IS Linux+userland+GUI+distribution.
Keep in mind though that Android apps on Google Play is compiled for an ARM (ARM64) architecture! Meaning, whatever hardware utilised, MUST run on/with an ARM processor..
All this limits the hardware choices substancially.

Everything "is possible". In theory. In practice though, I'd say the answer is "no". It is simply to much work to get it working. For absolutely no benefit.

With that being said... Bare Android on the other hand!! Now THAT is an idea.
Get your Android kernel source and compile it for the specific hardware you're using and then your Android distribution, set it up juuuuuuust so and you'll get what I (and probably everyone always wanted - a non-bloated piece of ... well, we've all seen them.