Android as an OS for non-phone devices - General Questions and Answers

Hello,
First off, apologies if I have posted this in the incorrect forum.
The company I work for is looking to update one of it's product lines and has been toying with the idea of using Android as a development platform. Up until now the philosophy has always been to develop simple, bespoke embedded software that provides only the functionality that is needed at the time. The device itself will be a medical device, and as such will have no telephony requirements (and associated things like contacts, calander and the large majority of the pre-installed Android apps).
I have read, and understand it is possible to re-compile Android from source and remove all of these non-required functionality. My question is really if that is worth doing? i.e. stripping out all un-needed applications that get build into a stock ROM. Or would it be a more efficient to use some form of OTS embedded Linux platform?
Something in Android 4.0 that does seem to be useful is the support for Bluetooth HDP.
Kind Regards,
Simon

Well there are other devices that aren't phones that use Android. Take the motoactv for example. It's a fitness watch that runs a stripped version of Android, but it's still Android and applications can still be programmed and installed to it.

Related

[Q] Native code, dead or just waiting?

As far as my stock quantum goes, I really can't complain about wp7. Great features, flows great, everything I could ask of a marketplace based OS. I got the phone knowing it would be locked down, but hoping the possibilities would grow. I do miss the seemingly endless capabilities wm offered though. Access to all resources, running native apps without the need to sideload.
I noticed a month or so ago a few guys in the forum were discovering ways to gain higher priveledges within WP7 and with the little knowledge my noob self has, have looked into the differences between wm6 and wp7, new kernel, beeing sandboxed and whatnot. And im curious, are we waiting for m$'s release of limited native code execution to oem's to be exploited, or is there an update in the privilege adventure?
With the amount of wp7 devices released and soon to be, I doubt I can look forward to an exploited bootloader to run a custom rom on my first gen wp7 quantum (such as a tricked out wp7 or possibly wm support...?), but a ported version of haret to run xdandroid as I did on my diamond would be exceptional, and from what I understand not too impossible considering wp7 uses ce7 (not sure if there's backward compatibility for ce6 though). We would just need a new UI, and an understanding of the device specific hardware for support in android...?
Where do we stand on any of these options, are they likely or if so, nearing?
I can understand your frustration with the restrictions on WP7 but for most scenarios, access to native APIs isn't that essential in my opinion (and I have been developing on WM6 myself). WP7 uses WinCE 6.0 R3 and not CE7. The Windows Phone team do recognise that they have been quite strict with the exposed APIs and I am sure that was a combination of fear of what developers write (in terms of crashing your phone) and work need to be done with Silverlight for WP. Mango brings new low level functionality and should be made available soon - Sockets been the first that comes up in my mind. Is something wrong with sandbox solutions? I believe not
For any other reasons I probably wouldn't have much to say on the subject, but I've always been one to tinker with my Xbox, psp, router, anything fun. If I can get more functionality out of it, I look for a way. Unfortunately I am not skilled enough to make it happen, so I look upon the gurus. In this case I consider dualbooting wm or even starting android from within the current OS as expanding possibilities. Which is why I look for answers to my question. Any answers?

Possibilities of a Rockbox Port for WP7?

Hey, XDA. This is a copy and paste of a post to '/r/wp7dev' on Reddit I made a few minutes ago, and I'm not yet able to post links sadly.
I took out my Toshiba Gigabeat S the other day, which I've pretty much abandoned when I got my Focus. I kind of missed the amazingness of Rockbox.
The short time that I had a loaner iPhone 3G, I had installed iDroid on it and the Rockbox for Android port too, and it worked well. (I was the first person to get Rockbox working on an iPhone, [kind of!])
So now, I'm thinking about how cool it'd be to have Rockbox on my shiny Windows Phone 7.5 Samsung Focus...
I'm not a programmer by any stretch of the term, aside from dabbling here and there, but I do have the whole VS2010 for WP7 and an official student dev unlocked phone and all that, and got to tinkering with the source from Rockbox's Android port (I had this linked, search for Rockbox Android port). (I figure it'd be the most sensible to try with their Android port than any of their device specific variants.)
Obviously, I have no idea what I'm doing. I was able to find a porting guide for Android to WP7 APIs (I had this linked, search for Windows Phone Android mapping) and it looks like a lot of the objects translate well, plus Java and C# are fairly similar to each other, and are translatable (also linked, search for Java C# comparison).
I'm aware of some of the limitations with file system access and native applications, etc. with WP7, so I know the whole porting process won't be a 1-2-3-done kind of deal. But it definitely looks doable.
It seems that something like this might need an Interop-unlocked device for it to fully run, but I figure anyone who'd even want Rockbox would already have that done.
Rockbox would be great for WP7 because:
- it supports gapless playback
- it supports a gigantic variety of file formats
- crossfading is lovely
- EQ controls are superb, as are compression controls and balance and whatnot
- it has an excellent set of plugins like oscilloscope, vu meter, etc.
- plus, it'll look really cool Metro-fied.
If anyone with interest is able to help out with this, let me know. Then who knows, support for streaming gapless from a media server could even be done down the line.
tl;dr: a Mango/Metro-fied WP7 Rockbox using the source code from the Android port could be a super amazing thing for the audio playback options for the platform. Any assistance in doing this would be spectacular!
Rockbox for Android is not something I'm familiar with; the last time I looked at RockBox it was a full ROM replacement. You could technically do that with an HTC phone, I guess, but it would be very difficult to create the ROM and a complete waste of the hardware's other capabilities.
Integrating Rockbox functionality into a WP7 ROM is probably closer to what you're thinging of, but it still won't be easy. WP7 doesn't allow apps to replace core functionality built into the OS, so you'd need to create a custom ROM that uses Rockbox in place of the built-in media player.
I don't know how hard this woul be, but don't assume it would be easy. Android is pretty much nothing like WP7 internally. Android uses a Linux core, and apps for it are written using a Java variant or various native programming languages available for Linux. WP7 uses a Windows CE core, and apps for it are written using managed code or Windows native C++. Typically speaking, to port an app between the two system you must completely re-write it.
I do know that Windows Phone 7 uses C#, which is structurally similar to java. At that point it'd be a matter of porting over the java to C#, then figuring out the API equivalents. Still though, I don't know how possible this'd all be without native access to the device.

How About Android for Desktops...

Another discussion where I posted a version of this led me to thinking that this might make for an interesting topic all on its own.
How would you envision a port of android made specifically for Desktop/Laptop environments, and do you think such an OS would be appealing to the average user?
_______________________________
As I envision it, ChromeOS should be folded into Android 4.0 and Google should build a version of the combined OS for Desktops.
The idea would be to create a common ecosystem of apps and usage environment accross multiple device categories, ad have it all interconnected through Google products and other apps running in the background.
I envision something that boots instantly right into ChromeOS while the rest of the Android system boots up in the background, thus allowing you virtually immediate cloud based functionality on the desktop. You could even choose to ONLY boot into chrome, say if you needed to look up something quickly online and didn't want to fully turn on a computer that has been turned off.
The chrome side of things would be very similar to ICS for tablets and would be deeply linked to all things google as well as relying on versions of the same Google apps that run on mobile, but optimized for ICS and taking advantage of larger screen dimensions. I envision touch interface to be retained for those who have touch sensitive screens, but also better keyboard and touchpad/mouse controls than currently exist. Lastly I would bundle a Google fork of Libre office specifically designed to have deep automatic integration with Google docs and Google+, but allowing users to have local editing control.
I would love to have such a system and have a common ecosystem between my phone, tablet and desktop/laptop, much how Apple currently does with IOs devices and MacOS and how Microsoft is planning to do with Windows 8 and WP8. unlike those ecosystems, this would run variants of the same OS, as opposed to different OSs made to work together, thus being able to take advantage of current built up knowledge and the existing android market.
Imagine if Google did the entire thing open sourced and released it to desktop and laptop OEMs.
A guy can dream right? If only there was a way to have a bunch of people pitch it to Google.
What do you guys think and how would you envision such an OS?
Android is already going to be merged with the Linux kernel in version 3.3 (with improved power management in 3.4)
nejc121 said:
Android is already going to be merged with the Linux kernel in version 3.3 (with improved power management in 3.4)
Click to expand...
Click to collapse
you sure about that? From what I've read Android is going to provide it's drivers and both Android and linux are going to provide patches to each other's kernels (with Power management being addressed in later versions of the linux kernel (3.4?). The Android kernel will remain (at least for now) a fork of the linux kernel.
Still that doesn't really address the subject of this thread.
Santeno said:
As I envision it, ChromeOS should be folded into Android 4.0 and Google should build a version of the combined OS for Desktops.
I envision something that boots instantly right into ChromeOS while the rest of the Android system boots up in the background, thus allowing you virtually immediate cloud based functionality on the desktop.
Click to expand...
Click to collapse
Yeah i too dream of Google using all the OS & games tech experience they have gained from Android to bootstrap a full desktop OS.
My personal fantasy is that the under no circumstances include any of the Chrome Cloud based nonsense. But focus quite heavily on games and multimedia, offer an OS that delivers content & gaming rather than try going head to head on productivity (where they would get owned).
Am not going to go into my objections to the cloud concept, lots of geeks my age & older well remember the mainframe model from the 70's and the cloud suffers many of the same inherent flaws IMHO.
I addition my fantasy involves ARM leveraging the experience with the multi-cores they have developed to produce an ARM desktop CPU arrays, as am a big fan or clusters and arrays, render farms etc.
I have to confess being serious i don't see either happening since both would be attempting to breaking into markets they are inexperienced in and where entrenched competitors already have a tough obstacle course laid out, plus pretty deep war chests.
But the main issue with a Google desktop OS, IMHO to succeed, i think it would have to be capable of some kind of half decent x86 emulation ........... But hey we are talking 'The Brothers Grimms Tales of Silicone Valley' here anyways.
Its possible to do so now, albeit not the same experince you get on your phone or tablet due to lack of driver support Its how i checked out 4.0 before I got it on my Asus Transformer Prime. Worth a try!
(Im new to XDA so I cannot post links, however google "android x86 download" and its the first link.)
There are ready is a port of android that works on desktops that these guys are working on over at http://www.android-x86.org/.

[Q] Why is Android so hardware specific

May be a dumd question, but I'm asking anyway. Why is Android so hardware specific?. or better yet, why can't you install any android system on any phone?
example: you can install windows or linux on any system, you don't have to have a certain set of chips. Is it a propitiatory type thing with these phone makers. is the whole android system so small, that the coding can't be added to make it installable on any phone.
I'm not a coder, or prgrammer, I do understand it enough to read what it is doing, but cannot write anything. Can someone shed some light on this
Thanks in advance
You've got this completely bass ackwards. Android is decidedly not hardware specific. Phones, tablets, computers, car stereos, home heating/AC, watches, TVs, etc. Android is open source, which means anybody can develop it to work on just about any platform they wish. I mean, you can get refrigerators and microwaves that run Android for Pete's sake.
If you're complaining that you can't get Android on an iPhone or a Nokia Lumia, then you're barking up the wrong tree.
To add some more "devices" to the list above on which android can be installed - cars! I'm working in that industry now
And the answer above is right - if your device is totally closed for others, then you will not be able to install anything on it, maybe, without really breaking into it. Android can be put mostly on any hardware - if the hardware manufacturer wants it. The short description is - Android is implemented on top of HALs (Hardware Abstraction Layer) which are then implemented by manufacturers specific to their devices and then Android works "out of the box".

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.

Categories

Resources