Slashdot Mirror

There's a Mac App Store: http://www.apple.com/au/osx/apps/app-store.html
There's the iOS App Store - available from iTunes and on iOS devices
There's the Windows Store: http://windows.microsoft.com/is-is/windows-8/apps
There's Google Play: http://www.android.com/apps/

They all handle DRM for you in a relatively unobtrusive way, plus they handle payment processing and distribution. The end user doesn't need to worry about you going out of business, your authentication servers going down, your serial numbers not working etc or dealing with another payment processor.

The advantage of something like the Mac App Store is that if I buy apps on here, Apple keep my purchase history. When I get a new machine, I sign in to the App Store and download all my apps from one place, and don't need to keep track of serial numbers or activation keys or anything like that.

This leaves you to handle doing the coding and the promotion of the app. Yes, you give up a cut of 30% or so, but if that's a big problem for you, put your price up slightly to take this into account. Or, give up the 30% cut knowing you don't need to handle any payment processing, hosting downloads, going over your bandwidth cap on your hosting plan because your app became popular, DRM, activation, providing lost serial numbers to users etc...

This vulnerability is in a TON of software. Python 2.X (which most people are still using) doesn't even allow you to verify the CN without adding a bunch of code to make it happen yourself. http://bugs.python.org/issue1589 [python.org] Most APIs allow you to do it both ways, but I think it is time that they stop making it optional. If you want to use SSL, use it properly otherwise it isn't worth wasting your time with it.

No, that's a very different vulnerability. What you're talking about would allow any valid certificate for site A to pose as site B, which means that there is almost no security, but if you can determine whose valid cert is being used, you are likely to have at least some idea who was responsible for it. There's at least a partial audit trail, in other words.

This vulnerability, by contrast, is that any self-signed certificate for site A can pose as site A. The common name must match, but everything else can be complete garbage, including the signature on the cert. This means that there is exactly zero security and zero audit trail.

This is the sort of security I'd expect from someone who knew nothing at all about SSL, and who just thought it was a magic box that made things secure.... :-/ Unfortunately, this class of mistake is painfully common, particularly in the mobile app space. Anyone who is considering overriding SSL chain validation really needs to read the following articles:

• Overriding Chain Validation on iOS
• Overriding Chain Validation on Android

Given how many news reports we see about this sort of thing, I think it is clear that Android needs to do a better job of messaging the importance of doing SSL chain validation right. IMO, it's telling that Android's networking training area does not appear to even mention the need for security anywhere, as far as I could tell. In fact, I'm really not finding any big-picture documentation for Android networking at all. It reminds me of learning POSIX networking by reading the UNIX Socket FAQ. And this is why we keep seeing these sorts of news reports. Just saying.

That's like complaining that Android ICS won't run apps written for Android Jelly Bean.

For example see the "breaking changes" http://developer.android.com/about/versions/android-4.2.html#Behaviors

Your earlier assertion was that WP7 won't run on WP8, not that WP8 apps won't run on WP7.

The real world calls bullshit

Using the home button does not end the app, it's still running in the background using memory. I think OP might have meant "exit" to mean an easy way to exit the app that also 'force stops' it. A feature most apps do not do and one that I would welcome, since it's an unwanted set of taps (settings / apps / force stop).

Why would you want apps to be force closed? Just so you don't see them in the recent apps list? There's a good reason for Android to only pause apps and not close them:

1. When an app is no longer needed it gets paused (it still uses memory, but it's in a stopped state, unless it has background threads or services).

1.a When that app is started again it is resumed from its previous state (much faster than having to restart the app from scratch since it's still in memory).

1.b If Android needs to free up memory it may close the paused app, in which cause the app needs to be restarted from scratch the next time it's run (since it's no longer in memory).

That behaviour is well designed in my opinion, it uses available memory to speed up apps, and Android only frees memory when it needs to. The developer activity lifecycle illustrates it pretty well.
You should never have to use Settings->Apps->Force Stop unless you're dealing with misbehaving or badly designed apps.

Should I tackle your brand of lunacy?

* Apps need a standard user interface way to exit. Really.

So you want them all to work the same way and look the same way?

* Locking the Nexus homescreen to portrait is idiotic. Really.

Which Nexus? My Nexus 7 isn't locked in portrait. Not since 4.2.1

* MTP looks great on paper, in practice it is dog slow and buggy. Back to the drawing board please.

It's done this way to provide a standard for all devices to be treated the same way regardless of software suite.

* Maps crashes all the time. Surely you know that. Fix it.

Not on any of the 5 android devices I've owned since my G1. Perhaps it's user error.

* Pretending that Android is not Linux is intellectually dishonest.

It uses the Linux kernel, and that's where it ends. All apps run in Dalvik. So it can't run normal Linux binaries.

* Support for unlocking and root access is still half hearted.

We have an amazing community who work for free on their own devices. Root and unlocking come soon enough.

* Android is not a community project. Fix that.

http://source.android.com/community/index.html I beg to differ.

"La la la I'm not listening"

That is you when you claim Android isn't Linux.

"Building on the contributions of the open-source Linux community and more than 300 hardware, software, and carrier partners, Android has rapidly become the fastest-growing mobile OS." http://developer.android.com/about/index.html

"Android consists of a kernel based on Linux kernel version 2.6 and, from Android 4.0 Ice Cream Sandwich onwards, version 3.x" http://en.wikipedia.org/wiki/Android_(operating_system)#Linux

Pull your head out of Ballmers ass and read this http://www.tbray.org/ongoing/When/201x/2010/11/14/What-Android-Is

In my distro I can rollback drivers and any app with a simple button click at least one version, sometimes 4-5 versions back if I need it. Try that with Windows.

You keep repeating crap that no one else experiences, maybe it is just you? You will feel better if you come to terms with your low IQ, seriously.

Chrome for Android is still only available for Android versions greater than 4.0, which excludes about 60% of all Android users, while Firefox is available to Android 2.2+, which constitutes about 98% of all Android users (source)

There are many applications and utilities written in Java that are quite far from useless, and which are not web-based applications. The website Java.net alone has an enormous number of open source ones. I've personally played around with Klooge Werks, a virtual gaming table for RPG's, which is written entirely in Java. Minecraft was originally developed in Java. A large percentage of IBM's Watson is written in Java.. And of course, Eclipse is mostly written in Java, which is the most widely used development environment for Android

In all fairness, the Android SDK license isn't a bed of roses, either:

1. 3.3) You may not use the SDK for any purpose not expressly permitted by this License Agreement. Except to the extent required by applicable third party licenses, you may not: (a) copy (except for backup purposes), modify, adapt, redistribute, decompile, reverse engineer, disassemble, or create derivative works of the SDK or any part of the SDK; or (b) load any part of the SDK onto a mobile handset or any other hardware device except a personal computer, combine any part of the SDK with other software, or distribute any software or device incorporating a part of the SDK.
2. 3.4) You agree that you will not take any actions that may cause or result in the fragmentation of Android, including but not limited to distributing, participating in the creation of, or promoting in any way a software development kit derived from the SDK.

In both cases, the intent is clearly to say "This SDK is our means of controlling the platform; meddle at your peril."

I have a nexus 7 and was annoyed that it doesn't automatically show up as a USB drive when connected to my computer. Bugged me for a long time -- there are apps to transfer files over your network but they seem slow. I resorted to scp more than once. Till I finally stumbled across http://www.android.com/filetransfer/ . Now when I plug in the tablet, I get a file browser to move things around. It's great.

As an aside, Airdroid http://www.airdroid.com/ is an awesome over the network method. Still kind of slow, but the interactive user interface with your phone/tablet is way cool. I just don't ever need anything but file transfers, and plugging in the USB cable is faster/easier -- but in a way, I wish I did want to do other things because of the objective coolness of this app.

The GPL doesn't ensure that you can "actually contribute to or even see developmental android code" and Google not offering that doesn't mean that their products are a "proprietary exploitation". The problem here is a nerd's sense of entitlement.

The problem is that Google sets expectations when they describe something as "open" (as if that meant anything by itself, but still) and then breaks them when they do not utilize an open development process.

This is true, and they deactivate flash on all devices when they update themselves to 4.0.

I guess you meant 4.1, but that's still not true (unless it's a special quirk of certain devices or something). Android itself doesn't respect the maxSdkVersion attribute, it's just a filter used by Google Play, so when you have Flash already installed and upgrade from ICS to JB, it'll merrily ignore Adobe's silly irrational restrictions.

The biggest install base for Android is what, Honeycomb? Shit.

Try an earlier version, oh hmm ah, Gingerbread.

That whole article reads like it could have been written by the Microsoft FUD division. It's either nobody uses Open Source or, if it is popular, then it has to be fragmenting ...

"Android also gives you tools for creating apps that look great and take advantage of the hardware capabilities available on each device. It automatically adapts your UI to look it's best on each device, while giving you as much control as you want over your UI on different device types."

"you can create a single app binary that's optimized for both phone and tablet form factors. You declare your UI in lightweight sets of XML resources, one set for parts of the UI that are common to all form factors and other sets for optimzations specific to phones or tablets".

"At runtime, Android applies the correct resource sets based on its screen size, density, locale, and so on."

Android may not be the only mobile OS or the best mobile OS, but it's the only FREE mobile OS. And one which now has a huge app store.

Uh, the open source Android has no app store?

Do feel free to point me to it on http://source.android.com/ .

Java is not native, even on Android. There's a separate NDK.

http://developer.android.com/tools/sdk/ndk/index.html

There are actually very good guidelines for Android development. Following those guidelines, along with a bit of research and practice, allows developers to release apps that work consistently well over a large choice of devices with different screen sizes, button layouts, etc.

Things can get trickier if you need to get closer to the metal but for most apps that's just not an issue.

That has also been available for a while as part of the SDK.

The SDK has an emulator, no? This would be natively compiled for x86, so more along the lines of a VM.

That has also been available for a while as part of the SDK.

Then you had NO RIGHT to bitch about Open Office or Java or anything else that tells you to piss off when it comes to user contributions, after all you have the source so you can just fork it!

Why do you assume I did? It sounds like you desperately want to prove your point.

If you seriously want to add code to mainstream Android, feel free to follow the procedure:
http://source.android.com/source/submit-patches.html .

Because adopting Android worked out so well for everyone but Samsung, right?

Oh, the exact opposite of that? I guess being a "me too" player isn't a smart strategy. Probably even worse for premium brands.

RIM made a smart move by buying QNX. It's (quite possibly) the most advanced mobile OS on the market. It instantly gave them a presence in new markets, which they're leveraging well, and an easy way to maintain their legendary security.

Their new UI is stunning (thanks to great acquisitions like TaT and smart hires like former Apple designer Don Lindsay) and from what we've see so far, clearly not something you could achieve by slapping a skin on top of Android. Features like Balance would also be a clunky mess (like running a VM on your phone).

For developers, there's nothing attractive about Android -- from the tools to the ROI, it's painful. RIM, in contrast, has dramatically improved developer relations and the quality and variety of the tools available to developers. This includes true native development, not just a few "essential" parts. From Google's What is the NDK page: "In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++".

In short: Adopting Android would have been the single worst move RIM could make. They'd be just another Android phone is a sea of unprofitable competitors, they'd lose every advantage that they currently have (their edge in security and MDM, for example), they'd be left out of other markets instead of expanding in to new ones, and they'd be unable to provide the same innovative new features for end users and developers (balance, peak, flow, etc.)

RIM made some mistakes, that's not in question, but skipping over Android was not one of them. Their transition was painful, sure. However, their new products are very impressive and, in many ways, well ahead of the game. Even BGR is singing their praises -- that takes some doing!

They could still fail in the market, I'll grant you that, but that won't be because they've produced an inferior product.

Andy Rubin (Co-founder of Android before Google bought it, and current VP of Mobile) posted this a few months ago in relation to Aluyin OS. https://plus.google.com/112599748506977857728/posts/hRcCi5xgayg (which links to the official Android blog: http://officialandroid.blogspot.com.au/2012/09/the-benefits-importance-of-compatibility.html).

It sounds like this modification of the SDK might be another move toward Google defending against this Aluyin OS-style modification of Android. While Android is commonly cited as being "fragmented" due to the %'s of handsets that have older versions of Android on them (see the Development Dashboard); what these links talk about is a very serious, more dangerous style of fragmentation. Currently all Android apps are forward compatible with future versions and most are backward compatible (unless the develop chooses to use a new API and not include any graceful degradation in their app for older versions). But Google's flavor of Android is also sideways-compatible with the likes of Amazon such that if you write an app intended for the play store and later decide to distribute it to an Amazon-flavored device (via their app store or other various means), you can do this.

The implications of allowing such activities to continue are that Android could turn into a true wild-west of operating systems. From a technical standpoint, a budding Chinese developer modifies some core Android source code which work with the apps being developed by his company, but suddenly break every other app developed for their flavor of the Android OS -- and then suddenly developers for that hypothetical OS can no longer pick up their app and take it to Google's (/Amazon's) flavor of Android without resorting to hacks and workarounds. Suddenly that Android Development dashboard needs to represent that data in more than 2 dimensions - and Google's got a world of new problems to deal with.

See this Architecture Diagram for some further context. Basically the various Android OEM's and custom ROM developers such as Cyanogenmod should only really be modifying the blue bits and maybe some of the green (I'm sure ROM developers would argue on the red bits, but in a perfect world..). Seems like Google is trying to stop the messing with of the yellow "Android runtime" section.

Sorry to reply to self but should add that the Android class for UI testing would be TouchUtils

Robot is part of the awt package and thus is not supported on Android.

http://docs.oracle.com/javase/1.4.2/docs/api/java/awt/Robot.html

The (better IMHO) Android class would be TouchUtils

(Though it seems to be missing screenshot capability. )

I don't know about "good" but for Android there is Monkey Runner

I don't think that would have saved December though.

Maybe a unit test should assert that there are 12 items in the month list though.

The internal permissions manifests are actually much more granular. For whatever reason (probably ease of use, but I don't know for sure), Google grouped them up into easy to understand chunks.

Full list is here: https://developer.android.com/reference/android/Manifest.permission.html

I do wish, however, you could tick a box in your settings to get the full story in the permissions confirmation window if you know what you're doing. Looking at that list, though, I can understand why they would choose to fold in some of the more obtuse permissions into some higher-level definitions.

Yes but this uses an official ICON. Clearly no way to forge that. I've never seen anyone think to use logos or icons for nefarious purposes before. Luckily I am protected here on my Windows 7 machine. I clicked an ad using the Windows 2000 theme that alerted me to major potential threats in my "regisetery"... Had a similar experience on my Macbook Air. Thank goodness for the altruism of all those interwebs ads and sites.

In all seriousness though, this could be a problem for people who root/ROM and install their Google apps from sources other than Google. Granted, when you root/ROM you should be aware of the risks, but it still presents a small danger.

Many Google apps however request permissions that need the app be signed with the same key as the ROM and/or the system key.

See: http://developer.android.com/guide/topics/manifest/permission-element.html#plevel

"signature"
A permission that the system grants only if the requesting application is signed with the same certificate as the application that declared the permission. If the certificates match, the system automatically grants the permission without notifying the user or asking for the user's explicit approval.

"signatureOrSystem"
A permission that the system grants only to applications that are in the Android system image or that are signed with the same certificate as the application that declared the permission. Please avoid using this option, as the signature protection level should be sufficient for most needs and works regardless of exactly where applications are installed. The "signatureOrSystem" permission is used for certain special situations where multiple vendors have applications built into a system image and need to share specific features explicitly because they are being built together.

Actually the android sandbox is quite sophisticated. Jellybean will randomize the location of an application's...

It's too bad that it was released in June 2012, and still, nobody has it. So while I'm sure newer versions of Android are much improved, but it doesn't much matter to anyone if the horrible manufacturers won't put an ounce of effort into maintaining the devices.

In single click mode, hover did selection.

I haven't seen a touch screen that detects the sort of finger proximity without contact that would be required to implement hover. A lot of Slashdot users have supported the early decision not to support SWF on tablets because too many SWFs rely on hover. In Android, one emerging pattern is for a long press to select an item, and then once an item is selected, the context menu replaces the toolbar. But of course, if you have a bunch of items to select, a long press (or even a long hover) on each is likely to take a while.

Open source has won the battle for the server, but is in a losing battle for the client, with walled gardens springing up all over.

Android is the biggest mobile platform at the moment. It has eclipsed Microsoft in the number of installed systems. Although these typically are not traditional desktop/laptop PC installations, the market seems to be heading more in the direction of Android (and similar systems) than it does towards those 'traditional' PC configurations.

In other words, the biggest platform at the moment is open source. Never mind that are several closed markets which serve this platform, you are not bound to them.

A quick look around the farm here shows that the advent of Android has pushed the last stronghold of closed source - mobile - off the cliff. All our PC's, servers and laptops run Linux in some form or other. All our phones run Android in some form or other. All our tablets run Android in some form or other. There is a television in the house somewhere, served by a DVB-T receiver/decoder. The thing runs Linux. The DSL modem? Linux. The router? Linux (OpenWRT). There is only one remaining 'closed' box attached to the network here: the (HP Laserjet 2200) printer. Guess which of all these devices is the most troublesome?

In contrary to what you state, gaining software freedom has never been as easy as it is now. Even better: it looks like it will become easier still with the advent of open hardware.

So you could have a device based upon the Android source, but doesn't meet the CDD, so it can't call itself Android.

Hmmm...my thinking on that is it's more to protect the Android trademark from crap implementations that would tarnish it's image. I' haven't read the CDD but from the summary it's focus is making sure applications will run correctly on a particular implementation.

I admit that doesn't say that the "license" actually requires a fee, but I think it does.

The Android compatibility page (where the CDD is hosted) states "Android compatibility is free, and it's easy." Although it does also have the below so there are some other factors that may involve some fee.

Once you've built a compatible device, you may wish to include Google Play to provide your users access to the third-party app ecosystem. Unfortunately, for a variety of legal and business reasons, we aren't able to automatically license Google Play to all compatible devices. To inquire about access about Google Play, you can contact us.

Although requiring a small fee for such certification may technically make it not virtually free, if the fee is relatively moderate I would still consider it essential free.

From the FAQ:

"What does "compatibility" mean?
We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.

In other words, compatibility is a prerequisite to participate in the Android apps ecosystem. Anyone is welcome to use the Android source code, but if the device isn't compatible, it's not considered part of the Android ecosystem.

What is the role of Google Play in compatibility?
Devices that are Android compatible may seek to license the Google Play client software. This allows them to become part of the Android app ecosystem, by allowing users to download developers' apps from a catalog shared by all compatible devices. This option isn't available to devices that aren't compatible.
"

http://source.android.com/faqs.html#what-is-the-role-of-google-play-in-compatibility

It still drives me crazy that there isn't a "reference install" for Android that you can use

AOSP is the reference version. http://source.android.com/faqs.html

This is probably what you are looking for:
http://developer.android.com/about/dashboards/index.html

As with so many things, Slashdot users are not typical of the wider world. According to android.com, the marketshare for Android versions 3 and up isn't at 40% yet...

http://developer.android.com/about/dashboards/index.html

Obviously older hardware won't get OS updates forever. It's because the hardware can't accommodate them, not because of some conspiracy theory.

With Android 4.2, the Nexus S and the Motorola Xoom got dropped from the list that get the upgrade. That seems logical. For example, the Nexus S only has a single-core processor, while its successor the Galaxy Nexus has a dual-core running at a higher clock speed. The Nexus S also has half the memory of the Galaxy Nexus, and its screen resolution is 37 percent lower. It simply is not a modern handset, and the effort required to shoehorn Jelly Bean 4.2 onto it wouldn't be worth the time, effort, or money.

Sure, the Nexus S was only released two years ago, but in case you haven't noticed, this market moves fast. I can understand why some people would be disappointed that the product's "shelf life" is only two years -- but that's really not the case. The Nexus S can still run Jelly Bean 4.1.2, which is a more recent OS release than all but 2.7 percent of all Android phones are running.

All I can think of is so? Google has been know to give android phones
to those that root and make that info pubic, this was before the cell phones public release.

Better yet, Google has been known to simply document how to unlock the bootloaders on their devices. This isn't even a case of giving the devices to hackers to hack, it's a case of someone writing the step by step instructions into a forum post using the officially endorsed method of rooting Nexus devices.

From Wikipedia:

Even better: From the Android documentation

Well, unlocking the bootloader is not the same as rooting, which is why it's more news than it people give it credit for.

No this is neither news nor does it deserve credit. You want to unlock the bootloader on your Nexus 4? Use the same method as you do for any other Nexus device. Use the method that is in the official Android documentation.

Not only do you have to worry about processors, screen ratio, resolution and anything else hardware related... you also have to worry about fragmentation of the operating system. Some people might have gingerbread and haven't upgraded to ice cream sandwich yet. And perhaps their phone can't handle the newest version.

http://developer.android.com/training/multiscreen/index.html

It really shouldn't be that difficult for anyone that expects to make money doing this. The guides are great (I've picked this up as a hobby) and the SDK is obviously built to allow re-use over different sizes and configurations. You design for scalability and the OS takes care of the rest.

You can also target specific hardware and android versions if you'd like. Pretend you're in Apple land and only target Samsung Galaxy S3 phones as if they're the only Android phones being produced. Anyone that doesn't have the same software version or screen size etc will not be able to download it. Also, I believe the latest iPhone has a different res/ratio as well.

But the Android device I have, is not something I would ever buy apps for. The screen is too small, the touch screen too annoying. I'd use maps on it and that's about it.

I have no idea what sore of Android device you've got, but I would have thought that there were very few phones today being sold with a screen size of less than 3.5" and a resolution of less than 320x480 ... and that, of course, was the spec of the 3GS (and previous iphones). Going by Google's most recent figures, there's only 2.7% of Android phones out there that have a screen size of less than 320x480 (which is the "small" classification of the screen data -- Google defines "normal" to be at least 320x470) Most should really have a 1ghz processor in them too, which is fine for running most things (it's all that's in my Nexus S, and that handles most everything I throw at it with aplomb).

So, I dunno ... a year or more ago, I'd say you've got a point, but not anymore. Even the dirt cheap Android phones are pretty damn good these days. They're not going to handle Asphalt 7, of course, but for doing smart phone things they should be fine.

(As to how many people buy apps in the Android world, that's another matter. Google is at least trying to make piracy harder than it used to be, which is a good thing ... but there's definitely a problem. Which means it sucks to be a developer, really, right now.)

But the Android device I have, is not something I would ever buy apps for. The screen is too small, the touch screen too annoying. I'd use maps on it and that's about it.

I have no idea what sore of Android device you've got, but I would have thought that there were very few phones today being sold with a screen size of less than 3.5" and a resolution of less than 320x480 ... and that, of course, was the spec of the 3GS (and previous iphones). Going by Google's most recent figures, there's only 2.7% of Android phones out there that have a screen size of less than 320x480 (which is the "small" classification of the screen data -- Google defines "normal" to be at least 320x470) Most should really have a 1ghz processor in them too, which is fine for running most things (it's all that's in my Nexus S, and that handles most everything I throw at it with aplomb).

So, I dunno ... a year or more ago, I'd say you've got a point, but not anymore. Even the dirt cheap Android phones are pretty damn good these days. They're not going to handle Asphalt 7, of course, but for doing smart phone things they should be fine.

(As to how many people buy apps in the Android world, that's another matter. Google is at least trying to make piracy harder than it used to be, which is a good thing ... but there's definitely a problem. Which means it sucks to be a developer, really, right now.)

Now hopefully they actually write an app that uses Android properly instead of some stupid iOS port - I've seen so many that are hard to use on Android because of this.

Which version of Android would that be? Development often revolves around the least common denominator, which in Android's case is 2.2. In the real world ~15% of the market is still a significant figure. What new and useful features have been added since then? Are you aware of how many different implementations which are vendor specific, things like graphics, button functionality (interesting related blog post illustrating these points) which might hamper development? I know this isn't an end user concern but you're experiencing the symptoms of Android fragmentation. What version of Android are these handsets running? Take a look at the SDK usage and OS versions as of this month. Looks like Gingerbread, which is from December 2010, in handset terms that's nearly a generation or two.

At least with IOS you're dealing with pretty current hardware since Apple (love it or hate it) makes it a point to support only the last two releases, and over 2/3 of devices upgraded to the newest version within a month, wish it were the same for Andorid.

but 90% are still at nothing higher than 2.3.5

Actually, Gingerbread and below are down to about 70%. Not good (JB is only on an utterly pitiful number of devices), but improving slowly.

Any desktop environment (KDE, Gnome, LXDE, etc) ported to Android should not use X but whatever Android uses to replace X (android.view)

Just grab IntelliJIDEA, the Android SDK, the JDK, and DroidDraw and you have a free software stack for writing GUI-driven android applications - perfect for business apps (think barcode readers and form automation).

Note - when setting up IntelliJIDEA, use forward slashes in your JAVA_HOME environment variable or it can't find the JDK on x64 Windows.

Intel's fabs are the advantage offered by x86. x86 processors are the only processors that can be made by Intel's fabs. If that changes, or if other fabs catch up, then great - use whatever is the best.

I guess I don't remember this as well as I thought I did, but I have been out of school for a while... And hardware never was my thing... I thought chips were burned onto silicon via some sort of lithography process? High intensity light etching the transistors onto a silicon wafer from a VHDL-type specification? What would prevent Intel from burning a 28nm ARM design in their fab?

Android apps are almost all Java - they run on any platform that has a Java runtime, which certainly includes x86.

No they're not and no they don't. They're Dalvik, which is similar enough to Java to make me sound pedantic by pointing it out, but they're not Java.

And while many android apps are written to run against the Dalvik VM, no small amount of them run native code. Opera, for instance by default ships both a ARM5 binary and an ARM7 binary (together) in the app store, and you can download the ARM7 binary by itself directly from them if you're sure your device can run it. Most performance-sensitive apps run natively, and writing native apps is well supported.

If your apps make calls into native code, that native code is shipped by the phone OEM, and you can already buy x86-based Android phones (Motorola sells one using some Intel Atom chip), so it obviously works there too.

Yes, and when that phone shipped you couldn't get Chrome for it, because there was no x86 Android build for Chrome.

In other words, the CPU's ISA is completely invisible to app developers, so I'm not sure what your complaint is there.

Sorry, that's simply not the case. It is invisible if you limit yourself solely to Dalvik apps, but that limits your options.

This makes no sense. Why would Intel have to push an ARM chip for you to be interested? What if Intel pushed a better-performing x86 chip than any ARM chip? Would you not be interested in that because you have some inherent bias against x86?

Hopefully it makes more sense now. No, a better performing x86 chip would not guarantee my interest. I'm not biased enough to completely rule out purchasing an x86-based phone in the future, but as it stands right now x86 looks like a disadvantage as opposed to an advantage.

Source here: http://source.android.com/source/index.html

Factory Images here: https://developers.google.com/android/nexus/images

Not open?

Oops, that was for 2011. Here's as of 1 October 2012, from Android.com. It may not be entirely representative since the metric is accesses made to the Google Play store. Even now, more than 70% of Android devices are on 1.x or 2.x.