I have a 42 inch multi-touch monitor with IR Input. I want to develop applications for multi-touch input and I have planned to go with android. Is there any way to get touch input? when we go with WPF, have to depend on a PC. Im really confused how to go through!! please help me out.Is standalone monitor possible in ANDROID?
Generally it appears that the only option to get Android (at least under ICS) to include touch screen HID drivers is to recompile Android from source.
Here are some instructions for exactly the purpose you describe (they also require the PandaBoard single-board computer as an intermediary).
There's a guy on xda-developers who's trying to do this using the Android USB Host functionality and MHL only on a Samsung Galaxy S3, but there's no confirmation one way or the other that he ever got that working.
Related
I want to develop a HTML5 app to control doors, lights and other things in my garage. The frontend of will get displayed on a 24/7 turned on screen, that really only displays the app (kiosk mode). So there will be really only the app, no browser controls like back and forth button or url bar, and also no notification bar or back and home buttons of the device. Just the app.
For this I considered 2 options:
Doing it with a raspberry PI & connect a touch screen to i
Doint it on a dead cheap noname Android Tablet
Since the 2nd option is much more elegant from the hardware point of view (everything I need is already built in) I decided to try this first and bought a 70 USD Prestigio Tablet.
But since I'm no android dev, I'm not sure how I can even modify the stock firmware that's currently installed on the device.
As far as I can see, the bootloader is unlocked and ready for flashing a modified firmware image.
And here comes the question:
How can I get the device's currently installed firmware image? Do I have to contact the manufacturer for this or can I extract it from the device directly?
If I get the firmware image, how will I be able to modify files in it?
Or do you think I got the wrong route?
You need to find sources of firmware for your specific device. I bet manufacturer would not provide them. For Nexus devices it is easier because there is AOSP (android open source project) which gives you an opportunity to build a firmware. You can also check specific forums like 4pda.
But there is another way - to make a KIOSK mode for your device example. I'm not sure how does that fit into requirements. Also You can make your app as Launcher app and live with that :)
I own a Samsung Galaxy 3 and want to port kernels available for other Android Devices. I have all building environment ready. I have C knowledge also. What exactly I dont understand is how and what all things porting involves, which codes should be modified in what way?
If someone could help me. It would be great.
Thanks in advance.
Ok I got it. But the real problem is I dont understand one thing.
What needs to be changed in the source code so that to make it compatible in other device? Can someone explain me that?
Idolon gives a good suggestion. In theory what is written there is true. In practice, it's a little more involving. I've been porting Android Kernel for months now. My goal was to have a custom S5PV210 processor module on my custom board with my custom I/O. I have the source code for Samsung's galaxy tab and several Samsung's android smartphone as well as a few versions (Froyo, Gingerbread) for the Samsung's Evaluation board (SMDKV210 for S5PV210 CPU). FYI, S5PC110 is a close derivative. Here is what I found out.
Eventhough all the device drivers are supposed to be built in a very modular way and independent from each other and you should be able to replace them with similar devices, the way Samsung did it is not exactly that. To give you one example is about power management. In many low level drivers dealing with hardware devices, it calls some specific routine for other hardware devices like power management chip. So, When you change the choice of drivers in the "make xconfig" or "make menuconfig" it will remove the source code of what you don't want and add the one you want but, there are still other modules that are calling the low level function you removed. When building, you will get tons of unresolved external because you removed a power management chip that your hardware doesn't have but is used in the source you started with. I looked through several Samsung's device source code and they have branched very early on. They have been adapted by different teams and it would be a major amount of work to go from one device to the other from one source kit.
Here is how I succeeded: I bought an S5PV210 evaluation board with an already ported Android Kernel (Gingerbread). All the power management and inter dependant issues where already cleaned-up. Then, form a working kit, I could change the device I needed (the one you can't buy without a 100K unit/yr commitment) without getting stuck with the interdependancy. Then I could even change LCD resolution (from 800x480 to 1024x768), touchscreen, Cell modem etc etc. The whole thing takes about a month worth of work with only one guy (me).
Starting with a Galaxytab or other commercial device made me waste months of headakes with no useful results but the thing I've learned.
There is one requirement to succeed on my approach. You have to know the hardware you are working on. As an example, you need to know what touch screen your hardware has (chipset) to select the driver and were is it connected to hook it up to the right device (USB, Serial etc). That the same thing for all other devices (power managemnt chip, keypad, backlight, LCD etc etc)
Hope that is useful to give you an idea of the work involved and how you can do it.
You should take a look at the cached copy of Android Platform Developer's Guide and at android-porting google group.
There is also an old but useful article about porting Android to Nokia N810, which will give you some hints about Android Linux kernel porting.
I am also into android porting stuff for quite some time I suggest the following route :
Read
You need to have basic knowledge of android porting and AOSP source code, directory stucture hierarchy.
I suggest you to start reading https://books.google.co.in/books/about/Embedded_Android.html?id=plHsngEACAAJ&hl=en
and also refer https://source.android.com/devices/index.html as good guys pointed out you can also google android porting related groups and become a member there, if you are stuck on a issue there are chances similar issue might have been faced by someone else previously.
Observe
AOSP code :
Parallely you need to dive in to the android source e.g from links like https://android.googlesource.com/ observe which components are placed where in the source code, what are the updates from previous android release (like ART replaced dalvik in LL), at top level there would be generic code, code specific to your hardware called HAL in hardware/ and device/ folder.
Kernel code :
In the kernel also you need to observe the directory structure and know which things lie where like SoC specific code will be in arch/ directory defconfigs (used for selecting kernel configuration) will be arch//configs/ directory.
Also there are good books available for linux kernel, you can google them and start reading them also.
While porting kernel you need to take care of following
1.If in the new kernel there is already support of SoC which is used in hardware to be ported then you need to add only device specific changes like suppose you want to port new kernel version to samsung galaxy s3, you can take a reference android kernel having exynos support and then you need to make changes only for adding support for samsung galaxy s3.
For that you need to have reference of some old kernel having support of s3, from there you can study patches which have been added to add support for s3 and port those patches to newer kernel.
Experiment
First you can only port the bare minimum changes required to up the platform, compile and flash it on your platform, then observe the output, if everything looks fine than go on for next changes otherwise try to solve the issue.
Thanks,
Devarsh
We want to place a device in a store that operates as sort of a kiosk device. As in customers walk up to it and start interacting with our custom app. The app could be developed for Android or the iPad, so I'm trying to decide which one to use and would like comments on the following ideas:
Is it possible for Android or iOS to access services over the USB port? This would enable us to disable the network.
Is one particularly better for 24 hour always on?
I like the iPad as I think its supply will be more constant as we move forward and need to replace devices due to ones gone bad. Also, our app will probably work on future generations of the iPad. With Android, I'm not sure there will be that sort of consistency from the tablet vendors.
Kiosk mode? I think with the iPad by putting it in a kiosk case that removes access to the home button and turning on the restrictions we'll get what we want. What about Android? I'd rather not have to get into rooting devices and replacing their firmware.
Remote control? Any way to remotely control iOS or Android in a standard means? Our app will be a client to a master server which will obviously be able to control the app somewhat (when used purely as a display device to a customer, controlled from behind the counter).
My feeling is that neither Android tablets or the iPad is best suited for this. Are there other options?
I will try to answer your points, but know that I am probably biased towards Android, because that is where my experience lies.
With Android 3.1+, at least with the Xoom, you have full USB host capabilities. Things like USB flash/hard drives, keyboards, mice, even digital cameras, all work. If you need custom interop with a USB device, you could go as far as to write a driver for it.
24 hour always on is not good for any device with a battery, but neither is better in this situation.
While android apps are forward-compatible, bad programming practices and/or deviations from "vanilla" Android software and hardware CAN break forward compatibility. That being said, if you grab a Google Experience device like the Xoom, you won't meet as many surprises.
In Android 3.0, the navigation bar is built-in at a low level, and it is not possible for apps to remove it. Therefore, it is trivial for anyone to break a "software nanny."
I know that it is possible to control android devices remotely, but without knowing your specific needs, I can't really offer more information than that.
Good luck!
iPad NOOO believe me I am a convert to Apple for my home and business but when we went to launch kiosk the iPad FAILED Big Time.. Here are a couple of little (Big) issues we ran into.
If the device reboots you cannot auto launch you iPad app since Apple does not allow that.
There is a serious memory leak in the iPads browser. We were running javascript / CSS3 and it cratered intermittently. I literally spent 2 hours "today" on the phone with Apple getting the MAJOR run around. I finally said let me speak to an Enterprise Sales Manager as my project could mean thousands of iPads and I got NO WHERE. One Apple employee even told me they don't have enterprise sales managers.
If those weren't enough even though we are just in the proof of concept phase, we are already getting request for other options. These other options are going to require access to the OS which Apple yea right. We are moving to Android immediately.
Sorry Apple I love you but you loose here.
If your using an Ipad you should consider if it can support the power for the USB thing. Watch this Using Powered USB Port
Your idea about putting the tablet behind another piece of glass/plastic is neat. To then deal with remote controlling, you might consider doing some Bluetooth programming.
My mobile development has been primarily with iOS, so I am biased toward that SDK. I will mention that the data/sync/charge port for iOS has (I believe) never changed. Your Gen 1 iPhone sync cord works on your iPhone 4... and your iPad or iPad 2. So, in terms of third party hardware, you may see more consistency with Apple.
I haven't found a good answer regarding whether it is easier to do Bluetooth programming for iOS or Android, but I think to stay cost-effective, you might see which one is more open to third-party devices. Here is an SO post/answer about iOS and third-party Bluetooth devices; I've not found anything on Android regarding third-party Bluetooth remotes, but considering a lot of hardware running Android is third-party, your chances from a naive perspective seem pretty good. Here's the Android Bluetooth API.
Buying an iOS or Android handheld to remote control an iOS or Android tablet does seem a bit steep, but then again, maybe not. Cost also depends on your ratio of remotes to tablets. 1:1? 1:N? N:1? N:M?
The lowest end iPod goes for $229 as of May 20, 2011. Android does have more variety in terms of hardware. You may be able to get a cheap Android phone with no service plan to act as a Bluetooth remote for an Android tab.
I have provided a solution for the kiosk mode using iPad here Lock-down iPhone/iPod/iPad so it can only run one app
I am afraid that I don't really know for Android if the same thing is possible.
To address the issue of crashing applications you can use an exception trampoline (see discussion here https://blog.compeople.eu/apps/?p=275) to catch the crash and reboot your app.
If the entire device is restarted however then other apps that are on the device can be started and will subsequently be locked in.
To answer your other points:
You can use a configuration profile to control network access. Force it to use a VPN or Proxy that only allows your custom app with embedded credentials to use. That way other network access can be prevented.
Your concern over future compatibility is spot on. The Android marketplace is so fragmented then maintaining a fleet is difficult.
If you have an app that is behaving as a server and is locked in then remote control is possible.
We manufacture tablet kiosks that support both android and iPad devices. In fact we are the only iPad kiosk that has achieved apple approval.
Generally speaking i think you will have an easier time with an iPad as the software and hardware will remain more consistent over time. Which is important if you have to change out a fault unit or deploy more kiosks 6 months or year from now when the original device is no longer manufactured.
I have been tasked with sourcing an off the shelf touch pad device that can be used as a dedicated industrial instrument controller.
Is it possible to run a dedicated application and prevent user access to all other functions/applications within Android.
Also is it possible write your own USB device driver which would allow you to connect an USB serial class device?
Of course you can. Like already stated Android is open source. You can take the sources and recode them to your desire so that the device behaves like you want.
In the end the default android launcher and all other applications are all just standard Java applications (mainly). You can recode it so that instead of loading the launcher app it loads up your app.
I think you can use this OS to make your own custom gadgets same as you can use linux in embedded systems.
Its open source so you can go down into the OS code and disable what you like. So i would say it is indeed possible. Windows does also do windows embedded like windows CE/WM range, these have touch screens and come in rugged form factors too, M3,PSION and others.
You can recode the OS visual display, i.e. HTC sense on all their phones. So you could recode it to show nothing.
As to the driver, well a driver is a driver this will also be possible.
Is it possible to install Android in a normal mobile phone?
I have Sony Ericsson Naite which has only key pad interface (No touch). I would like to install Android in my phone for experimenting with it. It will be great if its possible to dual boot Android with Symbian :-).
Do we need any other special hardware to install operating system in a mobile phone? Will Android work on a key-pad mobile?
Any pointer/suggestion is appreciated.
Thank you in advance.
The Naite is a fairly simple handset running on the Sony Ericsson JP8 platform.
End users are not supposed to be able to update the firmware on the phone.
Only Sony-Ericsson partners are supposed to get the PC software to update the firmware and only Sony-Ericsson is supposed to be able to create new firmwares.
(maybe you can hack the phone so you get it to boot on android or symbian but that's going to be unsupported behavior that nobody will guarantee)
If you want to experiment with creating your own android firmwares, I suggest buying an ADP2 handset from google.
If you want to experiment with creating your own Symbian firmwares, I suggest buying a Texas Instrument Zoom 2 device since it is the reference platform for Symbian.
The Zoom 2 seems to also support Android, by the way.
If you just want to experiment with application development on both platforms, I suggest using the two SDKs and emulators first.
There are some pretty cheap Symbian phones out there, particularly in the Series60 3rd edition range and, depending on where you live, you might even be able to find a Pay-As-You-Go Android phone like the Pulse.
I STRONGLY encourage you to go visit the XDA Forums and visit their Android sections for this kind of information.