Database Info

Forthcoming Native Development Kit

A week ago Brian Swetland (of the Android team) posted to the g1-hackers mailing list this juicy little nugget:
It is possible to bundle native shared libs in apks, and specific details
about how to do this in a least-likely-to-break-later way will be documented
in the forthcoming Native Development Kit (NDK).
Work is on-going to improve the platform APIs and provide more and better
access to the OS and hardware (bluetooth, improved audio, etc, etc). Future
updates will increase the surface area of the APIs.
Click to expand...
Click to collapse
Trying to get some confirmation and additional details, I checked in with android-framework and received this reply from Dave Sparks:
Yes, we're planning a native SDK. There is no official release date
yet. The initial release will probably be very limited in scope, just
enough to add some JNI helpers. As we lock down native API's, more
functionality will be added.
Click to expand...
Click to collapse
"JNI helpers" sounds a bit underwhelming, like .so libraries for optimizing inner-loops. However, this looks like a good first step toward getting applications with performance-bound modules to shine on Android. Personally I'm crossing my fingers for this to be what the Mozilla Fennec team to invest the time in porting for Android.

I'd rather see C#/.NET bindings for Android. Java blows. When I have time, I'm going to look into cross compiling mono for ARM (it's been done for ARM PCs, but not for Android yet).

Koush said:
I'd rather see C#/.NET bindings for Android. Java blows. When I have time, I'm going to look into cross compiling mono for ARM (it's been done for ARM PCs, but not for Android yet).
Click to expand...
Click to collapse
At first I thought you meant to cross-compile C# to Java bytecode to run in Dalvik. Didn't seem to make much sense since you wouldn't benefit from the .NET framework itself at all.
As for getting Mono natively on ARM, would that work for a non-root G1? If not it would be of little help for developing applications for the general non-rooted public.

[DEV][KERNEL][3.1] --- Linux 3.1 mainline kernel

Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline kernel with some patches from paulburton to make it actually work.
Icluded are (as of now) :
improved atmel mXT1386 touchscreen driver
tegra_v4l2 camera driver
ov5640 soc camera driver
prox_lds6202 proximity sensor driver
fm34-500 voice processor driver
asusec keyboard driver (for dock)
al3000a ambient light driver
The purpose of this is not to port things back from some linux 3.X kernel to our 2.X kernel, but to have a fully working 3.X source tree some day, from which we could port to further linux versions in the future. This can also be helpful if we want to port android 5.X in the future.
The github is at https://github.com/skirata/linux/tree/android-tegra-tf101-3.1 .
(It's my github, if someone wants to become a collaborator, please let me know, I'll add you to the collab list.
WE NEED EVERY DEVELOPER WE CAN GET.
I will spend some time on this, but I think I can hardly finish this project on my own.

Totally support this, looks promising!
Thanks for the initiative.

Are you and guever working on this together? I can test and maybe help make aokp or megatron versions.
Sent from my Transformer TF101 using Tapatalk 2

Of course I'm willing to work, you know I've helped all I could.
My kernel has much of the code updated to 3.1, so may be we can use much of it.
This can be done in two ways, by modifying the code in paul whatever it takes, or modify mine. I have nothing clear which will be easier, because over time I have made ​​several test on my code and unfortunately, when the kernel does not boot can not be debugged, so you have to turn back.
Until wednesday I will not be able to devote almost no time, so I think the first thing would be to check the operation of the kernel of paul (if not already done) with a current rom.
It is possible that the graphics drivers (most are binary system level) may not work with that kernel.
Well, it is what I think, that first we must see is what should be changed in the kernel to function properly (or whether to change the rom).

Teamwork is how it's meant to be done.!
I will setup a working kernel konfig in the next days to push this a little forward.
at Guevor :
I'm adding you in as a collaborator so we can work together on this.
Let's improve paulburton's drivers and add new ones based on latest nvidia images.
The advantage of upstream-porting rather than downstream-porting is we can port future kernel versions more easily with own written drivers.
Also, android 5.X porting will be a lot easier, as I think it won't support 2.6.X kernels at that time. And even if it would, we can have a massive performance boost if using 3.1 mainline kernel with improvements all over the world.
Glad to count you in, guevor.
I owe you so much already.
EDIT : Just in case, be sure to use the 3.1 branch of the linux repository, as the master branch is forked from torvalds (linux 3.4.X) and will get some love when we get the 3.1 kernel to work as good as we are satisfied.

Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made ​​for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....

guevor said:
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made ​​for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
Click to expand...
Click to collapse
Have you tried contacting Nvidia about this?

For the record, I am not a Linux user, even with what Im going to say, keep that in mind... My history is firmly routed in WinBlows land!
This has me all sorts of excited, I remember saying it back in paul's thread before it fell off the face of the earth (read, first few pages of the forum).
As stated at the top, while NOT a Linux user, I was trying to build CM9 for one of my tablets, to do so, I had setup a Linux box (tried a few distro's), and kept having issues, so a friend of mine walked me through updating to a 3.4.x kernel (3.4.0.-5 iirc), and things definitely FELT smoother vs the 3.0 (on the distro I was using before he berated me for it and moved me to a different one) and then 3.2 kernel in use (ill note hardware issues where also at play with the actual issues, but the smooth feeling after updating was definitely something I noticed).
I have no benchmarks or performance statistics to back that up, but as I said in paul's thread, and have now experienced in a "full" Linux environment, the future with Kernel v3.1 and up has me VERY excited as to what can be done with the OG Transformer! (vs mass backports to 2.x)
On that note, Subscribed thread, and time to get an RMA for my Tablet... the top basil part is starting to come off the unit

I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!

Orkeren said:
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Click to expand...
Click to collapse
Every help is welcome !
Please tell me your github name and I will add you as a collaborator

If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.

ajohn117 said:
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
Click to expand...
Click to collapse
Will do for sure, but it could take some time until we can push out the first build for testing.

rayman33 said:
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline own.
Click to expand...
Click to collapse
With my git every things works but usb hotplug,cam,hdmi-audio. ( usb works fine when insert add boot ) , also i will stop dev for it as i'm selling my tab :crying: but would be nice if this got finished.
also major thanks to paul

Do you started the project?

I tried some things yesterday, but it did not boot. I will have a look into spark rom and try some other things, I think I have some ideas.
Btw, kernel compiles fine, zImage is there, perhaps some early device drivers have to be updated. I will look into the ramdisk I created and fix some things ...
Just to let you people know. Progress is being made.

First progress
I managed to make it boot on revolver 4.1.1 rom. I modified the video drivers to be compatible with the actual binary drivers.
The touch screen is not working, but I really have not looked at it, maybe even compile options I chose are not the most adequate, but just wanted to get it to boot with video graphics working.

We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.

rayman33 said:
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
Click to expand...
Click to collapse
Well, I tested whether simply boot and graphics drivers failed as expected, and I've tried to change it and make it working. I think that is the basics (make it boot) to further adjust problems.
About the drivers, yes, I used mxt1386 but not detected coordinates, just click. I used a USB mouse to verify that the graphics drivers work.
I updated the repository with my changes.

Did you get a log cat already ?
It may reveal if the mxt1386 driver fails to load.

rayman33 said:
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
Click to expand...
Click to collapse
easy as pie!
Code:
orkeren

FreeCiv

Is it possible for freeciv to be ported by using this http://sourceforge.net/projects/portableapps/files/Source (FreeCiv)/

In theory, the installer could be rebuilt so you wouldn't even need to use the portable build.
However, I believe FreeCiv (like many open source programs) isn't designed to be built under Visual Studio. That increases the effort required for porting quite substantially. It's still possible, but it will take more time. If you want to get started on it, that would be awesome, though...

GoodDayToDie said:
In theory, the installer could be rebuilt so you wouldn't even need to use the portable build.
However, I believe FreeCiv (like many open source programs) isn't designed to be built under Visual Studio. That increases the effort required for porting quite substantially. It's still possible, but it will take more time. If you want to get started on it, that would be awesome, though...
Click to expand...
Click to collapse
I was looking at this as well but have no spare time currently, as well as Civilization:Call To Power 2 (source code released from Activision).
There are guides available for building FreeCiv in Visual Studio, and Civ:CTP2 was always a Visual Studio project.

[LIB] Qt4

All,
Please find the attached Windows RT runtime libraries for QT4 (4.8.4). Qt is a cross-platform gui/widget toolkit used in many software applications.
see: http://qt-project.org
I'm posting these here to assist other developers in porting Qt based applications to Window RT
These were built directly from source without code modification. I haven't tested them extensively, so please let me know if there are any issues with them. I've built what I believe are all the necessary libraries (honestly, I'm not a Qt developer), please let me know if anything is missing.
Cheers!

bfosterjr said:
All,
Please find the attached Windows RT runtime libraries for QT4 (4.8.4). Qt is a cross-platform gui/widget toolkit used in many software applications.
see: http://qt-project.org
I'm posting these here to assist other developers in porting Qt based applications to Window RT
These were built directly from source without code modification. I haven't tested them extensively, so please let me know if there are any issues with them. I've built what I believe are all the necessary libraries (honestly, I'm not a Qt developer), please let me know if anything is missing.
Cheers!
Click to expand...
Click to collapse
It`s what i want:good:

This is pretty awesome! I wonder how hard it would be to compile KDE using this... (for those who don't know, the K Desktop Environment is avaialble for x86 Windows as well as for Linux/BSD/etc.) I suspect Konqueror would be a pain, but some of the other KDE programs would likely work well. Leaving DBUS running in the background might be unfortunate for battery life, though.

GoodDayToDie said:
This is pretty awesome! I wonder how hard it would be to compile KDE using this... (for those who don't know, the K Desktop Environment is avaialble for x86 Windows as well as for Linux/BSD/etc.) I suspect Konqueror would be a pain, but some of the other KDE programs would likely work well. Leaving DBUS running in the background might be unfortunate for battery life, though.
Click to expand...
Click to collapse
Given that its a massive code base.. I'm gonna guess that its pretty hard. I had a quick peek at the source tree.. and it would take some serious effort to port it all (and all the apps!) to VS2012. However, if/when GCC for WOA comes.. it might be manageable to port.. but then again.. everything will be much easier once that happens.

bfosterjr said:
All,
Please find the attached Windows RT runtime libraries for QT4 (4.8.4). Qt is a cross-platform gui/widget toolkit used in many software applications.
see: http://qt-project.org
I'm posting these here to assist other developers in porting Qt based applications to Window RT
These were built directly from source without code modification. I haven't tested them extensively, so please let me know if there are any issues with them. I've built what I believe are all the necessary libraries (honestly, I'm not a Qt developer), please let me know if anything is missing.
Cheers!
Click to expand...
Click to collapse
any chance to get Qt Webkit compiled for RT?

Most of WebKit builds OK (JavaScript being the biggest difficulty), but it's a pain. Might be worth trying to build it just as a component, though.

App requests?

I know this is a potentially dangerous post, but I'm looking for suggestions for things to port. I make no promises that I'll be willing/able to port any suggested software.
Some ground rules before you hit 'reply'
1) Don't ask for Chrome. I won't port it. Period.
2) The source code must be available and not have any _obvious_ specific ties to non-open source code. Eg: some proprietary or closed source library which it depends on.
3) Code must be in C or C++ (I can deal with porting some assembly if needed)
4) Project must be of a _reasonable_ size for 1 person. Honestly, I do this on my own and in my spare time. Some apps can be just massively overwhelming to port. That being sad, sometimes the big ones are also easy.... so use your own judgement here.
5) Tell me why you want it ported. Whats your "use case".
6) Drivers aren't out of the question, but they generally take significantly more work.
Feel free to +1 others suggestions.
Ok.. <puts on protective gear>.. fire away!
Cheers!

Thanks for all your awesome work.
While this isn't an app, I think that the kexec kernel-mode driver idea that was tossed around earlier would be waay more useful than an individual app. Every time it was brought up somebody said "Oh, that won't be much work." And then nobody did anything :-/
So, I'm hugely grateful for the time you put in here, but I think I'd be even huger-ly grateful-er if you opened the door to other OSs.
Sent from my SCH-I535 using xda app-developers app

What would be good is:
http://ekiga.org/download-ekiga-binaries-or-source-code
But I'm pretty sure it uses some libraries not avail

I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.

Would be nice to have InSSIDer. I use it a lot on my laptop, rather leave it at home.
https://github.com/metageek-llc/inSSIDer-2

Myriachan said:
I wish XNA could run on Windows RT. It'd be funny to see Terraria and Magicka on Windows RT...
Firefox would be nice, but without a Thumb-2 JITter, it's not worth it.
Click to expand...
Click to collapse
I would say to take a look at monogame. It can actually build microsoft store apps including ARM support, so coercing it into functioning on the windows desktop may be possible. Otherwise it might end up being a rule 4 :/
There are hacks out there to run terraria on MonoGame instead of XNA, most of them pretty complete but sometimes have the odd graphical glitch. A full source port to MonoGame would be far more reliable, and actually very simple, but sadly its closed source (although not obfuscated).
One of the supposedly more reliable ones: http://www.terrariaonline.com/threads/wip-monogame-terraria-terraria-for-linux.72997/
Isn't rule one covered by rule four?

SixSixSevenSeven said:
Isn't rule one covered by rule four?
Click to expand...
Click to collapse
No.
People can have bad judgement.. so I'm making an explicit point about Chrome.

Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one

Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.

lambstone said:
Just found one. TCPMP, this player worked great during the PocketPC/Windows Mobile era. It moved from open source to a commercial different version which is closed source but I believe the link below has the source.
http://www.hpcfactor.com/downloads/tcpmp/
This would bring about a player that supports MKV playback.
Click to expand...
Click to collapse
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!

bfosterjr said:
There is no source code downloadable from that site. All the links are non-existent. Please post the source code if you have it.
Cheers!
Click to expand...
Click to collapse
Does this help http://code.google.com/p/tcpmp-revive/source/browse/#svn/trunk

mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2101891

mr djé said:
Personally i Was really disappointed by the lack of a transmission remote app when i discovered métro interface!
Plus there are many utorrent app...
SO, i think TR Gui source code is available, i think there is many people interested, And i think it will not be too difficult to develop, that can be a wonderfull idea (especially for me ) to make this one
Click to expand...
Click to collapse
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.

bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
Safari is not open source so cannot be ported.
Chrome is a rule 4 - or in other words is too much effort for 1 man to do in a reasonable time frame.
Firefox is also a rule 4, plus its a ***** to get it to compile properly under microsoft tools apparently, plus its javascript engine is raw ARMv7 JIT whereas windows RT bugs with that and would require a THUMB2 JIT. Chrome also would have javascript issues, although in chrome you can have an interpreted javascript engine I think which would just be hideously slow in comparison.
Opera - Closed source.
The list goes on unfortunately. Browsers are complex creatures. Most will come under rule 4 though.

bigsnack said:
I think the problem with the current torrent apps are you either have to pay to get the ability to download files in the background, or the app doesn't support it. I'd like to see a free torrent client that allows background downloading, even if it means speed has to be throttled a bit.
To the OP what is your favorite browser? If it is not Chrome(or Chromium), do you think it is possible to port that browser? At this point I'll even take Safari as I am starting to hate all the crashes that occur for me in IE.
Click to expand...
Click to collapse
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.

My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
To build WinSCP you need:
- Embarcadero C++ Builder XE2 Professional.
- Copy MFC source code from Borland C++ Builder 6 Professional and
build its Unicode version (see readme_mfc.txt).
- nasm from http://www.nasm.us/
- To build 64-bit version of drag&drop shell extension, you need
Windows Platform SDK:
http://msdn.microsoft.com/en-us/windows/bb980924
Click to expand...
Click to collapse
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...

domboy said:
My only suggestion would be a gui SFTP client. This is probably the one utility I am currently missing on my Surface RT (I use ssh to remote into Linux systems both for work and personal use, point #5). To clarify, I do use the psftp client in the putty suit, and that works well enough, just takes a bit more time and effort than something like winscp. I can continue to use this if an gui alternative is not feasible.
I recall someone requesting winscp at some point in the past, so I searched around this forum and I did find a couple of people that took a stab at it, but with no results, and I haven't found a clear explanation on what the hang up was. Looking at the readme winscp appears to be written in c++ at least (point #3):
I am unsure if the aforementioned Windows Platform SDK is available for Windows RT, or if it is even needed since Windows RT is not 64-bit.
Is nasm the problem? It looks to be an x86/x64 assembler... which of course wouldn't work on ARM... unless I just don't get what an assembler is...
Not being much of a coder I also don't know if one can import a Borland C++ project into Visual Studio, so maybe that is also a problem too.
So I guess I'm not sure on a lot of the points on the ground rules list...
Click to expand...
Click to collapse
Borland C++ is an alternative set of 3rd part C++ tools. Would take a bit of work to get a borland project to compile it under microsoft tools.
Nasm is an x86/x64 assembler yes. Assembly language is pretty much the lowest level of programming possible before writing in raw hex or binary. It is *HIGHLY* CPU dependent. Specifically the set of commands available in assembly is the plain text form of the exact instruction set the CPU has available which for x86 is different from ARM. The fact that nasm is required means that the project will have assembly in it, therefore an RT port will not be undertaken (one of the rules in the OP).
Sorry man, its proprietary tools and parts of it are unportable anyway. Doesnt mean another SFTP client can't be ported, just this one.

Here's my wishlist. I've poked at some of them, but I don't really have time to finish any of them.
WinPCap - Iirc, the biggest issue was that it was written targeting an older version of NDIS. The usecase would be to provide network support for BOCHS.
QEmu - There's a build of QEmu that builds on MSVC called WinQEmu, but it's dynarec recompiles to x86 only. I believe the official QEmu repo doesn't support MSVC, and I don't know if it can recompile to THUMB-2.
A good IRC client - X-Chat and mIRC run poorly under the emulator, and the few .net clients I've tried are meh. X-Chat has too many GCC-specific requirements, and mIRC isn't open source, I just want a good IRC client.
An X Server - I've been unable to find an X server that builds with MSVC, or anything short of Cygwin for that matter, but I'd love to have one.

Calibre is a good eBook manager I think this is the correct source code https://code.launchpad.net/calibre
I'm not good with this source code stuff so if its to much you dont need to make a port but if you can it would be appreciated thanks
Sent from my SGH-M919 using Tapatalk 4

cx1 said:
What the hell are you doing to get all these crashes? I have yet to have IE crash on 8 or 8.1 on RT in desktop or metro.
Click to expand...
Click to collapse
Browsing news sites and/or using Spotify.