Hello all,
I'm now the proud owner of an android phone (htc desire) and as a hobbiest programmer i'm of course intrested in making (free) apps for it. I come from a linux based devices background (like gp2x, wiz, dingoo a320) etc. So i'm used to the gcc toolchains and libs and I read a bit around about android programming. Am i correct in saying that is not possible to just use a gcc toolchain for programming android apps since android uses some sort of java virtual machine ?
Or is this possible after all, just like one woud make apps for linux based devices. I think the Answer will be NO but i still ask since i wasn't certain and did not find that much information about it.
Suppose it is not possible, my only option for porting linux based games / apps would be to use the NDK and split up the main functions of a game and make a shared lib out of it, which could be called using JNI from java right ?
But i have a question if this is the case...
I can't really imagine that all phone manufactures use the same hardware in their phone or even the same architecture, so suppose i would use the NDK to create a shared lib with basic functions of a game i wish to port, wouldn't this lib need to be build for the specific architecture of a certain phone and thus could only work on that phone ? or are all android phones arm based ?
So you could say my question basically comes down to this :
Will Using the ndk and apps created with it, be less compatible then a java only app for all the droid phones out there ?
thanks
hmm seems i can answer my own questions now, i hadn't looked at the official ndk site itselve yet and did not know it would have all the info i needed.
So using gcc toolchains only does not work,
android uses a (modified ?)java virtual machine called dalvik
de libraries do have to be build for a specific architecture, and all droid's (phones) do seem to run on arm, but in the future the x86 architecture will be supported as well.
HOWEVER,
one can target ARMv5TE or ARMv7-A (and in the future x86) and include the needed libs (per architecture) in the apk file, the droid system will do the rest by checking if a lib for the specific architecture is availible or not.
also it's worth to note that ARMv5TE libs should work on any arm based droid phone, BUT without hardware fpu support. Since all the (linux based) devices i programmed for had no hardware fpu either and weren't as near as powerfull as my desire is, i don't think using software floating point would be a problem for my needs and if it i do need it i can always use fixed point math.
Just thought i should write a small excerpt of that page here, since there might be other people looking for it eventually
So i was wandering around google this morning and stumbled upon this. I am not affiliated with the creater in anyway.
I dont know how to use this, but I wanted to put it here, incase some dev knows what to do with it. Or can use it.
I found it here.
Company main page
http://bellard.org/
Link to go straight to the emulator.
http://bellard.org/jslinux/index.html
It runs in your stock tab browser. Let it load. Takes bout two minutes.
Here is the info:
Javascript PC Emulator - Technical NotesBy*Fabrice Bellard
*- May 14, 2011
This PC emulator is written in Javascript. The emulated hardware consists in the following devices:
* 32 bit x86 compatible CPU
* 8259 Programmble Interrupt Controller
* 8254 Programmble Interrupt Timer
* 16450 UART
* Real Time Clock.The code is written in pure Javascript using the*W3C Typed Arrays
. A slightly slower fallback mode is implemented for browsers missing this support. For the exact list of supported browsers, see the*FAQ
. In any case, a fast Javascript engine is needed to have good performance.
CPU EmulationSome of the code is inspired from my x86 dynamic translator present in*QEMU
, but there are important differences because here it is an interpreter. The CPU is close to a 486 compatible x86 without FPU. The lack of FPU is not a problem when running Linux as Operating System because it contains a FPU emulator. In order to be able to run Linux, a complete MMU is implemented. The exact restrictions of the emulated CPU are:
* No FPU/MMX/SSE
* No segment limit and right checks when accessing memory (Linux does not rely on them for memory protection, so it is not an issue. The x86 emulator of QEMU has the same restriction).
* No CS/DS/ES/SS segment overrides. FS/GS overrides are implemented because they are needed for Thread Local Storage in Linux.
* A few seldom used instructions are missing (BCD operations, BOUND, ...).
* No single-stepping
* No real mode
* No 16 bit protected mode (although most 16 bit instructions are present because they are needed to run 32 bit programs).Most of these restrictions are easy to remove, but I decided to implement the strict minimum to be able to use a recent Linux kernel and its user applications.
I added some tricks which are not present in QEMU to be more precise when emulating unaligned load/stores at page boundaries. The condition code emulation is also more efficient than the one in QEMU.DevicesCurrently there is no synchronization between the PIT frequency and the real time, so there is a variable drift between the time returned by Linux (try the "date" command) and the real time.
The UART (serial port) does not support FIFO mode. Perhaps it could help to improve the display speed.
There is no network emulation at this point.
A clipboard device (seen as*/dev/clipboard*in the emulator) was added to allow exchange of data between the emulator and the outside world.Javascript terminalAlthough I could have reused the excellent*termlib
, I decided to write my own because I was curious to see how it could be done. The main problem is the key handling which is different among browsers and OSes, as described*here
.Linux distributionI compiled a 2.6.20 Linux kernel (I guess any other version would work provided there is still an FPU emulator). The Linux kernel configuration, patch and the source code of the Linux starter (kind of BIOS) are available:*linuxstart.tar.gz
.
The disk image is just a ram disk image loaded at boot time. It contains a filesystem generated with*Buildroot
containing*BusyBox
. I added my toy C compiler*TinyCC
*and my unfinished but usable emacs clone*QEmacs
.
JavascriptI happen to be interested by the implementation of Javascript engines these days - but I don't know yet if I will write my own any time soon ! Anyway, this emulator was a way to learn how to write optimized code for recent Javascript engines, in particular Jaeger Monkey (for Firefox 4) and V8 (for Chrome).
A troubling thing is that the PC emulator is about 2 times slower using V8 than Jaeger Monkey (I used the 32 bit version for both). I have no precise explanation yet because I only looked at the Jeager Monkey code so far.What's the use ?I did it for fun, just because newer Javascript Engines are fast enough to do complicated things. Real use could be:
* Benchmarking of Javascript engines (how much time takes your Javascript engine to boot Linux ?). For this particular application, efficient handling of 32 bit signed and unsigned integers and of typed arrays is important.
* Learning to use command line Unix tools without leaving the browser.
* Client side processing using an x86 library, for example for cryptographic purposes. For such application, the x86 emulator can be modified to provide an API to load x86 dynamic libraries and to provide a*js-ctypes
*like API to call the C/C++ functions from javascript.
* A more advanced version would allow to use old DOS PC software such as games.
Hit the thanks button if this has helped you in any way!
Don't Panic
If this has been posted before or is un needed or not wanted please post so, and thread will close
Don't Panic
Airplay SDK is unique in providing the
facility to build your application as an
entirely OS-agnostic binary file that contains
native CPU instructions. So no compromise
on performance, yet no need to port your
application between operating systems.
Airplay SDK supports single-click
deployment to all of the following operating
systems: * iPhone OS * Android * Samsung
Bada * Symbian * Windows Mobile * BREW
* Palm/HP webOS * Maemo Additionally,
Ideaworks Labs is working closely with
leading device manufacturers to open up
new distribution opportunities for Airplay
content. Airplay SDK fixes fragmentation
within each operating system by removing
the need for developers to worry about
individual device eccentricities. Here are just
five examples of the hundreds of per-device
problems that Airplay SDK solves: *
Dynamic portrait/landscape screen
switching handled identically for all devices
* Accelerometer API implemented
identically for all devices (despite the large
number of bespoke device drivers and APIs
in the market) * Device-application
interoperability handled identically for all
devices (i.e. your application is guaranteed
to 'play nicely' with the device software, for
example to respond to incoming phone calls
and messages) * Audio handled identically
for all devices (for example, by providing
advanced software sound mixing) * Single
drawing API supports OpenGL ES 1.x,
OpenGL ES 2.0 and super-fast software
rendering, allowing your app to run with or
without any form of hardware graphics
acceleration FEATURES: Save development
time by writing your Airplay app using
vanilla C++ in the IDE of your choice. Airplay
currently supports all versions of Visual C++
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
- No native support for x86 apps on ARM, nor ARM apps on x86. Only .NET apps would work in both worlds.
But it is possible to create an emulator similar to DosBox that would run native x86 programs on WoA and, for example, I'm currently working in this direction.
- Though existing C++ apps can be recompiled for ARM from sources, it is not a 100% working solution. Current VS11 contains a rather limited set of ARM libraries - no DirectX libs earlier than 11, no import libraries for NtDll.Dll and similar DLLs.
I don't have access to any WoA builds, so I can't check whether these features are completely removed from ARM, or those LIBs are just not present in current VS11 build. But at least now we can compile test apps for ARM and analyze the code (though we don't have where to execute them yet).
- Native WoA programs use THUMB2 instruction set (ARMv7 and above). Though ARM instruction set would be supported too.
- According to "Microsoft Portable Executable and Common Object File Format Specification v8.2" WoA machine type in PE files would be 0x1c4, and some new relocations types are added (for example IMAGE_REL_BASED_ARM_MOV32T = 7). IDA understands such EXE files, though complains on relocs.
- SEH is implemented in a different way than on x86 (similar to x64, google for RtlAddFunctionTable to get the idea).
- WoA is more secure by default. For example TPM can be rarely found on x86, but it would be required on ARM.
- Most of existing drivers are source-code compatible with ARM (of cause if not using x86-specific stuff). But ARM would never allow to load unsigned drivers (unlike x86 Win7/8).
- As platform is completely new - all ARM drivers would be added to windows update site to simplify our life. Some obsolete hardware like 1394 is not implemented at all, so there would not be so many drivers for ARM llike for x86.
- All binaries would be the same for all SoC providers.
- No "native" ARM VisualStudio - developer tools are x86 only.
WoA requirements from different sources:
- 10.1” display with 1366x768 min resolution (though smaller screens may be supported with reduced functionality)
- Volume Control, Windows, Rotation, Lock power buttons
- Dual core CPU with hardware accelerated GPU
- at least 1 Gb RAM
- min 16 Gb fixed storage
- 100mW idle power in standby
- there are rumors that there would be standart "Phone call API" ("Apollo" UI)
Does anyone have access to ARM WDK? It would definitely contain a complete set of import libraries and would provide lots of info on WoA internals in headers/documentation. Seems that Windows 8 WDK on MSDN does not have ARM tools
so your bottom line says: no w8 on arm (ever)?
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
The UEFI requirement is expected, and I doubt will be that much of a hurdle. UEFI is all open, and it should be pretty trivial to chainload a UEFI-compatible environment on top of the existing firmwares, provided that nvidia doesn't provide us with an implementation to start with, which I suspect they'll do.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two. A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Everything I could find relating to the TPM says that it's optional, but will be automatically utilized if available.
The rest is pretty inconsequental, at least to what I think most people here are interested in.
nvidia started a windows 8 development program for ARM (Clickey here), but I haven't seen anything else from it, has anyone else gotten anything?
mamaich said:
As this is a developers forum - lets share here information on WoA (Windows on ARM) architecture.
What is known for now from different sources:
- WoA 8 would require UEFI to boot (instead of BIOS on x86), ACPI is required too. So no WoA to existing devices (they don't have UEFI/ACPI and I don't think that anyone would waste his time on emulating them).
Click to expand...
Click to collapse
Actually they said it would continue to support BIOS for older devices.
See: Current machines dual-booting Windows 7 and Linux should be able to upgrade to Windows 8 without wiping out the Linux install. As Microsoft notes in the Building Windows 8 blog, “We will continue to support the legacy BIOS interface.” However, machines using UEFI instead of BIOS “will have significantly richer capabilities” including faster boot times and greater security. (from Arstechnica)
That's for x86. ARM was said to require UEFI. Besides, there is no real bios on Android tablets, at least not a common platform.
netham45 said:
I'm not quite sure where you found that it requires ACPI. I didn't turn anything up.
Click to expand...
Click to collapse
I've got it in one of the "windows-on-arm" non-public documents dated the first half of this year. While UEFI,ACPI,TPM are an option for x86, they are required for ARM hosts.
So no custom WM8 bootloaders, drivers, patched kernel on ARM hosts (like "windows activators" do) until sign keys would be leaked or some backdoors would be found. Of cause this is good as this would make rootkit creation more difficult, and require device drivers signed by MS (so we'd get more stable OS) but I really don't think that this "protection" would last more than 1-2 months after WoA would be released.
For the emulator, I believe the best thing to do would be to provide something opposite of WINE, something that'd emulate the instructions, but pass API calls and translate between the two.
Click to expand...
Click to collapse
I'm already working on such tool. It emulates x86 instruction set with dosbox or bochs CPU emulation library (I'm using both of them for debugging purposes, while working on my own one that would be much more simple->faster), translates x86 WinAPI to "native" host WinAPI + emulates API that is not present or differently implemented on WoA. It is designed to be truly cross-platform, so just a recompilation + creating several thunks/stubs would be necessary when I'll get my hands to an ARM host running windows8.
Of cause programs that use heavy anti-debugging, self-modifying code, undocumented features and SEH tricks would not work. Currently it is rather far from being finished (I have to implement&debug WinAPI and COM thunks that cannot be automatically generated) but old games like "heroes of might and magic" are already working fine in a test environment.
A full Windows SDK will likely come out for ARM processors once it's finalized, if it's not already out. Have you checked in the Ultimate build of VS2011, or the express build?
Click to expand...
Click to collapse
Of cause I'm talking about "ultimate" VS11, as express is designed to target mostly .NET (though ARM compiler is present there too).
And WDK that it published on MSDN does not allow creation of ARM drivers. I'm currently in a process of renewing my company's MSDN subscription, so I can't prove that myself, but I've read that on OSR forums.
I am waiting to hack my iPad and put win8 on it
I would hope touchpad would be the next viable option. Hp could still make more and just dump W8 on it. Thanks all of you for working this thread. I will be reading your progress as it unfolds. Good Luck devs and if I can find anything you will be the first to know.
Sent from my mwp6985 / Trophy using XDA Windows Phone 7 App
Some information on Win8 "Apollo" is available. Apollo - is a name for a new "windows phone" OS from MS.
- Apollo is based on the same "desktop" code as Windows 8. No Windows CE at last!
- Apollo would provide the same user experience as old Windows Phone 7.x - Metro UI, People hub, builtin office apps, etc. Seems that software compatibility with WinPhone 7.x apps would be preserved, but this is just my own guess.
- All applications on Apollo are required to be signed, similar to Windows Phone 7.
- Device drivers can be written only by IHVs, MS and OEMs, not by ISVs. This would be a problem for antivirus vendors or tools like daemon-tools.
- There would be a "built-in" eMMC card with OS and vendor partitions, and maximum one SD card. eMMC supports NTFS, SD-card supports only FAT/exFAT.
Build-in eMMC would have C:\ drive letter, SD-card would be D:\ if present.
eMMC contains several partitions. Some of them would be made readonly during boot.
- Near Field Communication is built in.
- The same list of sensors as in WP7 Mango is supported.
- There would be BSOD like in a desktop OS
- Unproven, but it seems that only .NET ("Splash UI framework" and "Silverlight") APIs would be available to independent developers. So no native code again.
- Seems that x86 architecture is supported for Apollo too.
Droidspace is a newly published, open source, shell based IDE. It allows you to use Python and HTML5 to hack Android and Chrome. The latest version includes...
Python3 Interpreter
Chrome based interface (hack your droid from a regular laptop)
Extensible shell
Hacker's text editor (based on ACE)
HTTPS support for untrusted networks
Very simple API for casting your own creations onto the browser
SL4A based Android API (supports webviews)
Video and audio streaming
Simple, pure Python extension system
Intuitive threading (nothing blocks unless you want it to)
Droidspace is designed to allow you to very easily and rapidly develop software on an Android device, with the option of using HTML5 to build user interfaces that can be rendered by the device directly or cast into some instance of Chrome running on the same local network. Though all the bits are there, Droidspace is not well suited to developing standalone products for publication.
Droidspace Philosophy, Article 0: Magic is essential. Portability isn't.
The project is hosted by GitHub and is GPL licensed. I can't post links here, but you can find it easily on Google. If you have any questions, I'd be happy to help.
Cheers
carl_smith said:
Droidspace is a newly published, open source, shell based IDE. It allows you to use Python and HTML5 to hack Android and Chrome. The latest version includes...
Python3 Interpreter
Chrome based interface (hack your droid from a regular laptop)
Extensible shell
Hacker's text editor (based on ACE)
HTTPS support for untrusted networks
Very simple API for casting your own creations onto the browser
SL4A based Android API (supports webviews)
Video and audio streaming
Simple, pure Python extension system
Intuitive threading (nothing blocks unless you want it to)
Droidspace is designed to allow you to very easily and rapidly develop software on an Android device, with the option of using HTML5 to build user interfaces that can be rendered by the device directly or cast into some instance of Chrome running on the same local network. Though all the bits are there, Droidspace is not well suited to developing standalone products for publication.
Droidspace Philosophy, Article 0: Magic is essential. Portability isn't.
The project is hosted by GitHub and is GPL licensed. I can't post links here, but you can find it easily on Google. If you have any questions, I'd be happy to help.
Cheers
Click to expand...
Click to collapse
Great ! ... ... I'll give it a try soon ... :good: