I have tablet pc, which uses Android.
It's config:
marvell mohawk rev 0 v51
bogoMIPS: 797.00
Features: swp, half, thumb, fastmult, edsp, java, iwmmxt
cpu implementer: 0x56
cpu arch: 5te
cpu part: 0x840
cpu revision: 0
Hardware: pxa168 edge development platform
My aim is to develop my own driver, which will get stream from usb ( from the microscope ) and then render it in Android app in my tablet pc.
As I understand , I must learn not only arm v5 arch, but need to get arm-gnu C compiler and must know hot to handle byte stream from usb.
I have looked at usblib (OpenUSB) project, but seems to be it's not such clear project for arm arch and will cause a lot of problems.
So, how can I natively get stream from usb of my tablet pc ( armv5/android ), then obtain in in native part ( ndk ) than through JNI send data to Java and render it in my tablet pc.
Is the way I think correct and what troubles I shall get on this way?
Thanaks,
Best Regards
Android runs on a Linux kernel. So what you're after is either a Linux kernel driver for your microscope, or a user mode program to interface with it (some USB devices can be driven entirely from user land). In either case, you'll need to root your device. Use the Android NDK if you need to write a native mode program. If you need to write a kernel module, get the kernel sources for your platform (either from https://android.googlesource.com/kernel/common.git or, if applicable, from a manufacturer-specific repository). Before you embark on writing a driver, check if there isn't already one for Linux; chances that it will work with minor adaptations if at all on Android (what definitely won't work is any Linux GUI application).
Android doesn't currently support 3rd party drivers for USB devices. However, starting with Android 3.1 (Honeycomb), there is a Java API to directly communicate with USB devices. You can write an Android application which detects and communicates directly with your microscope completely in Java. If the processing of the data coming from the microscope requires higher performance, you can write native code (through the NDK/JNI) to do the processing.
Related
There're several emulator binary variations residing in the Android SDK's /tools folder but I don't find any documentation on their differences (e.g. when to which one).
Android SDK version is 24.4.1, on CentOS.
Normally, you don't need to care about this, a default emulator will be chosen for you (first binary). Each binary represents one of the supported architectures. The last five are the 32-bit emulators.
Android emulator is based on QEMU
When the Android SDK was first made available to the world, Google
used QEMU as the basis for their Android emulator. They copied the
source code to a custom repository in the Android Open Source Project
(AOSP) and made a number of invasive modifications to QEMU.
Specifically, they added emulation of a specific board called goldfish
for the purposes of emulating an Android phone.
Every build of Android targets a specific hardware platform, and the
emulated goldfish platform is no different. A number of specific
emulator features are enabled in both the Android kernel and Android
userspace environment when run in an emulated environment. These
features allow a smooth and complete user experience resembling using
a real Android device, on laptop and desktop workstations.
The Android emulator provides Android application developers with a
convenient development environment and allows developers to develop
and test applications on devices which they do not have physical
access to. With the introduction of the ARMv8-A architecture and
Android support for 64-bit ARM platforms, this need is more important
than ever because it allows developers to begin adapting their
applications to an ARM 64-bit based mobile ecosystem prior to hardware
being available.
You can use the default emulator like here (or add QEMU options, but I never needed it, read this).
You also can force a 32-bit emulator:
I am experimenting with Android Binders at middleware level using C++ so I need an emulator to test it as I cannot afford a board everywhere. My ultimate target is to port a linux middleware application on android and I also want to test that app.
Is the android emulator that comes with SDK suitable for it (which I don't think). If no, is there any emulator for android middleware development or how can I test on my PC instead of running binaries on an ARM board?
As long as you do not rely on/do not want to change the HALs of specific hardware you should be perfectly able to use the emulator.
Depending on what kind of middleware you want to test you could either use the emulator coming with the sdk, create an avd and install your app/library there or you could modify the android source code (when your middleware should be part of thd system) and start the aosp provided emulator directly with thd built ROM.
Don't know if this answers the question as I didn't fully understand what you want to say with 'middleware'
There was a recent article that Linux kernel 3.3 has integrated Android as one of the features.
It has also created the possibility of launching Linux applications on Android systems provided the correct drivers are used.
I am currently learning Android app development using Processing language.
I am comfortable with processing language in Windows/Linux operating systems. If I develop a processing application in Linux kernel 3.3 that uses bluetooth communications, is it possible to port it to Android?
If yes, How should I go about doing that?
To summarize my question, Can I port my Linux based processing language apps to android?
Linux binaries have always been able to run on an Android system assuming the proper libraries are available (such as in a chroot). See, for example, Debian & Android Together on G1, the first released Android device.
What is happening more recently is that Android kernel modifications are merged or being prepared for merging into the mainline Linux kernel. This doesn't directly benefit desktop Linux users (who weren't using those additional features anyways) nor Android users (who will continue using Android's kernel), but will hopefully reduce divergence and make ongoing development and maintenance easier.
It also gives rise to the potential of running the Android userspace stack on a mainline Linux kernel, whether on a Android device or not.
You can't do this directly no. You see, Android is based on the Linux Kernel, on top of that are all of the drivers for the specific device and on top of all of that is the Android OS. You need to write code that makes Android OS calls through the sandbox that your app is in.
I have some operating systems such as Windows 7 and Linux.
Is it possible to run Dalvik on this Win7 and after that running an Android application or game?
Thanks
One solution is to install Android-x86 (Android for Intel or AMD CPUs) either natively or in a virtual machine. If you only want to play some games and not to dual-boot with Windows and Android, you can use the excellent Android emulator Bluestacks. Just a warning, depending on your hardware (or virtual hardware) one version of Android-x86 may work better than another, you have to try. In a virtual machine most likely the virtual graphics card won't be detected properly, so you have to run it in VESA mode. I recommend editing the boot entry before running it and adding the commands:
nomodeset xforcevesa vga=ask
Then choose graphics mode to run Android-x86. This forces a specific VESA mode and most of the times the graphics are presented properly with correct colors on screen. Of course in that case you have a performance penalty. Some games may need to enable Developer Options and then force software rendering to be able to run them.
Android's virtual machine is tightly integrated with the OS (Linux). So, it is impossible to run it on Windows.
The lower-level components (OS and native libraries) in the Android system provide many services that Dalvik merely "translates" for the consumption of Java programs. So porting Dalvik to Windows is probably very hard and rather pointless.
dalvik can definitely run on (normal) linux, and it's likely it can also run in a cygwin environment on windows.
As for being able to run Android applications, that is quite a bit more complicated. However, the AOSP source does have a "simulator" build, which does just that - runs dalvik natively on the host machine and provides an android framework etc, for running android applications.
Keep in mind however that the simulator environment isn't actively maintained, and will probably require quite a bit of "love" to get it to work.
You can install Android on your PC with VirtualBox. Check out this tutorial.
is there any way to reboot the emulator into recovery mode??
Android emulator does not support recovery mode, just normal boot mode
Android emulator accepts Android images -including kernel and ramdisk images - as standalone images on it's command line interface. They are not compiled to one big image as in a real world scenario where all Android partitions are stored to the same phone storage
The kernel of Android emulator is a custom build of a android kernel, it's called goldfish kernel which can communicate with the virtual platform developed by Google engineers named as "goldfish", a pre-built of this kernel can be found under $sdk/system-images/android-22/default/armeabi-v7a/kernel-qemu
Please note you can not just replace it by kernels other than goldfish kernels. However, goldfish kernel source code can be found # gooogle repo and can be easily compiled and replaced by the default one that comes with the Android SDK
In case you need to run the android emulator with another Linux kernel, then you have to port this kernel to the golfish virtual hardware (which is not a straight-forward process). I did it before and I can elaborate more on how to do it if needed.
In order to boot the android emulator in the recovery mode, you need to do an extra effort of porting a tool called "u-boot" (i.e. a well-known and widely used 2nd stage boot-loader used in real phones) to the goldish virtual board to be able to run it on top of android emulator. I did that a couple of years ago and it was very mind-blowing process. I can provide you with tremendous information if you are interested in doing so.