Database Info

Android as an OS for non-phone devices

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.

Tool for creating pure android ROM. An idea for Google Android guys.

Original Post : linkedin.com/pulse/google-android-guys-here-idea-you-prashantha-mundkod
Today, I have some business ideas for Google Android guys..
Idea
A tool (a desktop tool and/or android app tool ) for creating ROM and installing stock android.
This tool basically does 3 major tasks.
1. Reads hardware information of an Android device through the desktop/android tool and creates a stock android ROM for that device.
2. Creates a super user , roots the device , installs the ROM created in step 1.
3. Provides an option to keep/remove the super user after the installation based on user sophistication.
(Alternatively, tool will install a generic stock android and then look for appropriate drivers for the device after the installation)
Why do we need a tool ?
Here is what I found while playing around with stock android.
1. Majority of handset manufacturers simply don't bother provide updates . Even if they do, its ridiculously delayed.
2. The UI created by most manufacturers is not innovative or user friendly. They are loaded with ridiculous amount of bloatware. Since they don't bother to provide timely updates either, end user is stuck with an older version of Android regardless of device's capability to support newer versions of android.
3. For an average user, there is no simple way to install a stock android . Users are in mercy of tech forums and developers who volunteer to create custom ROM. Expecting a ROM from volunteers for all devices out there is unrealistic . Trusting those ROMs is another biggest concern as well. Despite the volunteer efforts , installing a stock android ROM still needs some level of IT knowledge , not the cup of tea of an average android user.
4. There is no generic stock android ROM. Reason perhaps is that, creating a package with drivers for thousands of manufacturers would be practically not feasible as the package size would be enormous.
User Experience
An end user who wants a stock android doesn't need to be an IT guy and the tool should be simple to user. Example : Click a button that would read hardware and create the package, next user interaction is a prompt asking the user to install the stock android ROM. All other user interactions such as retaining super user etc is an an option for advanced users.
Manufacturers
Any custom UI or App package a manufacturer wants to push for their device should be updated as App package from manufacturer over a pure android . (Example : Once user install the stock android, manufacturers like Samsung, can push their app like Galaxy gifts etc as a package. )
This would shorten the development cycle for manufacturers as well. Thus updating Android for their device becomes purely a app package for an android version , rather than individual device.
Advantages
For users, clearly the benefit is the ability to have most updated software and experience of pure android and freedom from abandonment of device from manufacturers.
For Google (and Android as a platform ), one of the biggest competitive disadvantage is , its fragmentation. One of the reason for fragmentation is that, for a large number of devices, simply there is no easy way to update the software. The tool could help solve fragmentation issues.
The tool may be included as part of Google's attempt for Android One initiative. Certainly , no explanation is necessary on how it benefits Google from having one single version of android in all (or at-least as many devices as possible) android devices.
For now, that's it . When i am free, I will post the details on how exactly they should do it .
Experts... What do you think ?
Disclaimer : Views expressed are my own.

Advice on using Screenless Android Phone for IoT device

I would like to create an IoT device by buying new, cheap android phones, strip them down and remove the screen, rebox into my own physical box, install a custom ROM without any bloatware (and that will boot without a screen!), and install my android app on the device to do stuff.
An example of a purpose for this could be a GPS tracker for a car. The box would be placed in the car, and record GPS and accelerometer readings, posting these readings back to a central server via the cellular network. (This is just a random example, so don't focus too much on the detail of this, but there are thousands of uses for a IoT board with the sensor, CPU, RAM, storage, and connectivity capabilities of a budget android smartphone)
The reason I want to use existing phones is that they are wonderful, mass produced, cheap devices with a variety of sensors I can use.
The reason I want to use Android is because it is because of the customization ability, and the mature development ecosystem.
To me, it seems an obvious thing to do, but I don't seem to be getting much joy trying to search for examples of this sort of thing (either here, or on the internet in general).
So some questions:
1. General thoughts? (Good idea? Am I missing some fundamental problem?)
2. What are the challenges of running Android without a screen connected?
3. Are there any custom ROMs you know of that specialize in this sort of thing?
(I've seen Google Brilo, but it still seems a bit early yet, and I really like the idea of just using the standard Android SDK to develop the app - and the abundance of help and information that comes with it)
Thanks!

[Completed] Outform 15.6" iDisplay Android Tablet

Picked up one these tablets its a commercial built android tablet running KitKat 4.4, this has a bespoke install specifically for retail management in the form of integrated MokiManage software. While the software can be turned off and your left with a big standard Android tablet (seriously the onscreen keyboard is massive), i would though rather have a standard android install than one with features enabled & disabled according to the manufacturer requirements.
It is possible to access the recovery to implement an update but;
1. Would it be possible to replace the bespoke install with a standard KitKat ROM?
2. Its brand new & built to withstand Saturday morning kids playing whack a mole on it, would YOU risk bricking it?

Hi!
I can't find anything at all on xda about that device. You could try a Google search, or try asking here, http://forum.xda-developers.com/android/help
I really doubt you can do much with it though. You would need to have something created for your specific device, and I can't find anything.
Good luck!

What behaviour in the mobile operating system market could be described as anticompetitive?

I am a retired programmer with too much time on my hands; as such, I wrote a complaint to a regulatory body about how I can't install the operating system I want on my device because it will render it unusable (if I can't call for help on a phone because of drivers, what good is it?). I received a response requesting an interview with an officer who specializes in anticompetition cases and I would like to make sure I have my eggs all in one basket.
The current mobile phone market I liken to the desktop OS market of the 90s, where you had companies like Xerox, Microsoft, IBM, and so on; in the 90s, there were antitrust lawsuits where a particular company was accused of intentionally creating barriers to customers seeking to install software by other companies on personal computers. Obviously, that was settled in the 2000s, but IMO it did appear to make a positive change even if we are still fighting against IE. This may not be relevant, but that's what my mind went to when I realized I couldn't uninstall the Play Store.
Nobody uses "cellular telephones" as telephones anymore; instead, they are mobile computers. Computers in the 80s/90s had plenty of OS options (you may recall using OS/2 or BSD), but you can't do that with mobile computers... is that a good thing?
In my retirement, I'd like to develop and build a mobile phone operating system that is not android (nor lineageOS); this would either be Linux or BSD-based with a simple package manager, but the user would have the option to compile their own software also. This would ideally *not* hinder the underlying function of the device (i.e. telephony), but I don't see how manufacturers could be compelled to provide binary drivers. The current mobile market makes it obviously a very high barrier to entry for any who want to develop new operating systems for mobile computers. Is this anticompetitive? Perhaps not, but I'd like to hear some opinions and if you would kindly point me towards some resources I would appreciate it.

IMO the OS is not the problem - a command line based OS can be written by any talented student nowadays - preferably in C++, yes there are enough templates on the Internet, it is the device drivers what have to fit the hardware that make the whole thing difficult. I know that some OEMs put their device drivers' source code to the public.

jwoegerbauer said:
IMO the OS is not the problem - a command line based OS can be written by any talented student nowadays - preferably in C++, yes there are enough templates on the Internet, it is the device drivers what have to fit the hardware that make the whole thing difficult. I know that some OEMs put their device drivers' source code to the public.
Click to expand...
Click to collapse
To install a new OS on a phone, the phone must first be booted into a bootloader such that the 'image' of the OS can be loaded. The image for the OS should be built with the drivers present such that when booting, the OS kernel can load the relevant drivers as it probes the hardware in the phone, and then the software installed on the user layer can access that hardware through the relevant system calls. How possible is it for the bootloader to load a custom OS in the general sense? The majority of instructions I find are on enthusiast/developer websites with the actual manufacturers giving basically no input (that is to say, I haven't seen on manufacturer's websites or instruction manuals where they give instructions for booting your choice of OS).
Would it be fair to say that mobile developers, like Google/Samsung/LG/Amazon/etc are restricting users from being able to install their own OS on their device? Is driver access a reasonable thing to ask for?
Again, I'm retired, so I have time on my hands, but I'm old and there's realistically not a lot of that time left. I don't want to try developing my own BSD-based mobile OS if there's no way for me to install it on my own devices; that effort could go into another project if it is otherwise wasted. I suppose it is worth asking whether I should bother returning the bureau's request for an interview.