Not sure if this is the right spot for this, but I was hoping someone
could answer my question.
With the current Android fragmentation between different hardware and
handsets, why not have the whole operating system run run a hyper-
visor on the phone. ROM's would be portable between phones, dev
testing could be done on anything.
I am expecting there would be a performance hit, but with current
generation hardware it shouldn't be to much of an issue.
That doesn't really address the problem that people are really complaining about when they say "fragmentation."
The Android OS itself has several major versions you need to target, but that's also true of iOS, and (to my knowledge) people DON'T complain about fragmentation on iOS.
The problem is, as I interpret it:
1. Lots of various screen resolutions. 2. Different UI hardware on each device (keyboard? soft buttons? what order are the buttons in?) 3. Different graphics hardware on each device. 4. Different CPU/math support on each device. 5. Bugs in some devices in the way that they present their capabilities and/or in their implementation of various standard Android APIs. I'm looking at you, Samsung, and your buggy SoundPool implementation.
The different OS kernels don't figure in my top five issues to worry about, except as they could potentially affect #5 (as in, adding their own bugs to the mix). So having a hypervisor that allowed you to run multiple OS versions at once on a phone doesn't really help at all.
Having a device with lots of pixels that you could boot up into various different resolutions would help with #1. Also giving it lots of hardware options and allowing you to disable them would help with #2 (maybe just a detachable keyboard like the ASUS Transformer). #3 and #4 really require different devices to test on, though probably only 4-5 devices to hit the major contenders. #5 probably requires that you own each of the buggy devices so you can test on them.
> Not sure if this is the right spot for this, but I was hoping someone > could answer my question.
> With the current Android fragmentation between different hardware and > handsets, why not have the whole operating system run run a hyper- > visor on the phone. ROM's would be portable between phones, dev > testing could be done on anything.
> I am expecting there would be a performance hit, but with current > generation hardware it shouldn't be to much of an issue.
> That doesn't really address the problem that people are really complaining about when they say "fragmentation."
> The Android OS itself has several major versions you need to target, but that's also true of iOS, and (to my knowledge) people DON'T complain about fragmentation on iOS.
> The problem is, as I interpret it:
> 1. Lots of various screen resolutions. > 2. Different UI hardware on each device (keyboard? soft buttons? what order are the buttons in?) > 3. Different graphics hardware on each device. > 4. Different CPU/math support on each device. > 5. Bugs in some devices in the way that they present their capabilities and/or in their implementation of various standard Android APIs. I'm looking at you, Samsung, and your buggy SoundPool implementation.
> The different OS kernels don't figure in my top five issues to worry about, except as they could potentially affect #5 (as in, adding their own bugs to the mix). So having a hypervisor that allowed you to run multiple OS versions at once on a phone doesn't really help at all.
> Having a device with lots of pixels that you could boot up into various different resolutions would help with #1. Also giving it lots of hardware options and allowing you to disable them would help with #2 (maybe just a detachable keyboard like the ASUS Transformer). #3 and #4 really require different devices to test on, though probably only 4-5 devices to hit the major contenders. #5 probably requires that you own each of the buggy devices so you can test on them.
> Tim
> On 3/20/2012 10:39 PM, Evan Pyle wrote: >> Not sure if this is the right spot for this, but I was hoping someone >> could answer my question.
>> With the current Android fragmentation between different hardware and >> handsets, why not have the whole operating system run run a hyper- >> visor on the phone. ROM's would be portable between phones, dev >> testing could be done on anything.
>> I am expecting there would be a performance hit, but with current >> generation hardware it shouldn't be to much of an issue.
>> Cheers, >> Evan
> -- > You received this message because you are subscribed to the Google Groups "Android Discuss" group. > To post to this group, send email to android-discuss@googlegroups.com. > To unsubscribe from this group, send email to android-discuss+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/android-discuss?hl=en.
My main 'fragmentation' problem comes from the rapid release of new OS
versions each of which has new bugs, backwards compatibility problems,
small behavioural changes, deprecated APIs etc. relative to the
previous ones.
> My main 'fragmentation' problem comes from the rapid release of new OS > versions each of which has new bugs, backwards compatibility problems, > small behavioural changes, deprecated APIs etc. relative to the > previous ones.
> ICS has been horrific.
> Pent
I wonder how many of the developers that Google hires have ANY experience shipping something? They mostly seem to hire fresh out-of-college kids with only theoretical experience. They need to hire some folks, especially a few cottage developers because they constitute the bulk of developers shipping on Android, to improve development and even as some managers.
They finally actually implemented some of the screen qualifiers on Google Play and removed the notices that they weren't implemented yet. It looks like my tablet version of an app is now only going to folks with devices it will work well on.
> My main 'fragmentation' problem comes from the rapid release of new > OS versions each of which has new bugs, backwards compatibility > problems, small behavioural changes, deprecated APIs etc. relative to > the previous ones.
Ahh, you know, I've been almost entirely insulated from those kinds of changes, because I'm doing cross-platform OpenGL/NDK development. If you're seeing lots of issues there, then having lots of ROMs you could put on various phones could be useful. A hypervisor is a bit of tech that I wouldn't expect to see on Android, still.
On Mar 21, 2012 1:47 PM, "Pent" <supp...@apps.dinglisch.net> wrote:
> My main 'fragmentation' problem comes from the rapid release of new OS > versions each of which has new bugs, backwards compatibility problems, > small behavioural changes, deprecated APIs etc. relative to the > previous ones.
I don't know that it really has anything to do with fragmentation, just that the companies modifying OSA code don't take the time to do so carefully when pushing major version upgrades to previously lisenced devices. Nor do they seem to ever check for additional updates after getting whatever release candidate from Google.
Motorola, for example, introduced a wpa_supplicant bug that prevents authentication on secured wireless connections for some subset of original Verizon Droid devices... I don't remember, V 2.2 or 2.3 of android maybe? Subsequent updates have only been to introduce additional bugs, or remove the ability to gain root-level access (fixing "security" holes). Nothing through three updates has addresses the wireless issue, even though release notes for one said it was to "improve wireless performance".
> ICS has been horrific.
Do you mean in relation to your application, or just on device behavior in general?
On Mar 21, 3:59 pm, c beck <usabec...@gmail.com> wrote:
> On Mar 21, 2012 1:47 PM, "Pent" <supp...@apps.dinglisch.net> wrote:
> I don't know that it really has anything to do with fragmentation, just
> that the companies modifying OSA code don't take the time to do so
> carefully when pushing major version upgrades to previously lisenced
> devices. Nor do they seem to ever check for additional updates after
> getting whatever release candidate from Google.
Yep, and much more falls between the cracks, as there's little
incentive to work out all the little details. It would be really cool
if the tech blogs and press could look beyond tidbits about the next
glitzy high resolution display and examine the various manufacturers
for their track record on how well the devices actually work, all
around, including pushing out well rounded software updates.
> Do you mean in relation to your application, or just on device behavior in
> general?
In terms of work required to maintain compatibility and work around
bugs,
switch to reflection for deprecated APIs, changes to fit better with
the new
UI style etc etc
1. Resolution
I can't see why Android can;t be made to run at many resolutions in
the same rom, every other operating system can handle it. You would
need the hypervisor to report screen size and resolution, that way the
ROM could make an informed choice as to what UI scale to use.
2. UI Hardware
Easy done, have a few different keyboard options and automatically
select the best fit by querying the hypervisor as to what buttons are
present.
Let's see:
Search button
Home button
Menu button
Vol+, Vol- buttons
Power
Back button
Trackball
Maybe a keyboard
3,4.
CPU/GPU should not be to hard, google should just say "As of Android
5.0 all device must support XYZ instruction set"
5. Not sure.
The extra power use of running a hypervisor is a concern, but I
believe that everyone running the latest android is going to negate
any effects of running a hypervisor.
On Mar 22, 4:45 am, Tim Mensch <tim.men...@gmail.com> wrote:
> That doesn't really address the problem that people are really
> complaining about when they say "fragmentation."
> The Android OS itself has several major versions you need to target, but
> that's also true of iOS, and (to my knowledge) people DON'T complain
> about fragmentation on iOS.
> The problem is, as I interpret it:
> 1. Lots of various screen resolutions.
> 2. Different UI hardware on each device (keyboard? soft buttons? what
> order are the buttons in?)
> 3. Different graphics hardware on each device.
> 4. Different CPU/math support on each device.
> 5. Bugs in some devices in the way that they present their capabilities
> and/or in their implementation of various standard Android APIs. I'm
> looking at you, Samsung, and your buggy SoundPool implementation.
> The different OS kernels don't figure in my top five issues to worry
> about, except as they could potentially affect #5 (as in, adding their
> own bugs to the mix). So having a hypervisor that allowed you to run
> multiple OS versions at once on a phone doesn't really help at all.
> Having a device with lots of pixels that you could boot up into various
> different resolutions would help with #1. Also giving it lots of
> hardware options and allowing you to disable them would help with #2
> (maybe just a detachable keyboard like the ASUS Transformer). #3 and #4
> really require different devices to test on, though probably only 4-5
> devices to hit the major contenders. #5 probably requires that you own
> each of the buggy devices so you can test on them.
> Tim
> On 3/20/2012 10:39 PM, Evan Pyle wrote:
> > Not sure if this is the right spot for this, but I was hoping someone
> > could answer my question.
> > With the current Android fragmentation between different hardware and
> > handsets, why not have the whole operating system run run a hyper-
> > visor on the phone. ROM's would be portable between phones, dev
> > testing could be done on anything.
> > I am expecting there would be a performance hit, but with current
> > generation hardware it shouldn't be to much of an issue.
> 3,4. > CPU/GPU should not be to hard, google should just say "As of Android > 5.0 all device must support XYZ instruction set"
If you've got the highest-level OpenGL GPU, then you're fine on that front.
But there are at least three distinct numeric coprocessors that I'm aware of in Android devices. If you're writing native/NDK code that includes hardware floating point, you may want to support all three. I don't think a hypervisor could emulate floating point hardware not actually on the chip.
I also have no idea why you're talking about using a hypervisor anyway. The point of a hypervisor is to run several OSs concurrently [1]; most of the devices we're talking about are RAM-limited enough that if you tried to even run two at once you'd be in trouble. If all you want is to be able to multi-boot into various different configurations, you can do that without a hypervisor and its overhead. It would be far simpler to, for example, add a hack to an Android image that causes it to read its resolution from a configuration file and act as if it's a lower resolution than it would to create a hypervisor layer that translated every hardware access to different actual hardware.
It does not have to be a hypervisor. but having a standard operating
environment on EVERY handset would solve all the user experience
problems. For example, some of my android devices do not support ICS,
so I have two sets of apps, well 3 if you include the tablet.
On Mar 24, 4:29 pm, Tim Mensch <tim.men...@gmail.com> wrote:
> > 3,4.
> > CPU/GPU should not be to hard, google should just say "As of Android
> > 5.0 all device must support XYZ instruction set"
> If you've got the highest-level OpenGL GPU, then you're fine on that front.
> But there are at least three distinct numeric coprocessors that I'm
> aware of in Android devices. If you're writing native/NDK code that
> includes hardware floating point, you may want to support all three. I
> don't think a hypervisor could emulate floating point hardware not
> actually on the chip.
> I also have no idea why you're talking about using a hypervisor anyway.
> The point of a hypervisor is to run several OSs concurrently [1]; most
> of the devices we're talking about are RAM-limited enough that if you
> tried to even run two at once you'd be in trouble. If all you want is to
> be able to multi-boot into various different configurations, you can do
> that without a hypervisor and its overhead. It would be far simpler to,
> for example, add a hack to an Android image that causes it to read its
> resolution from a configuration file and act as if it's a lower
> resolution than it would to create a hypervisor layer that translated
> every hardware access to different actual hardware.
