Slashdot Mirror

That is the problem with Android. Because of misconceptions, the big gaming companies are ignoring the platform. However, they are perceptions, not reality. A couple:

1: Piracy. Android has a mechanism independent of rooting as a guard against piracy, the LVL, or License Verification Library. The iPhone depends solely on if the device is jailbroken or not. Toss in JVM/DVM code obfuscation, and Android APKs are much tougher nuts to crack than iPhone apps. Click on copy-protected when the app is being uploaded and that provides another layer of shielding.

2: Faster update cycles. On Android, you upload your APK, and it is available for update almost at once. With this, even if someone cracked your 1.0.1, your 1.0.2 forces them back to the drawing board. This allows for tight development cycles and fast bug stomping.

3: Hardware/"fragmentation". This is what the manifest file is for. Don't want anything but the latest Android? Something in the uses-configuration/uses-api/uses-library/uses-feature settings in the manifest file will keep the app from being seen in the Marketplace unless someone has a device with those features [1].

4: Faster hardware development cycles than iOS.

None of this is to say that iOS is bad; it just states that Android is just as good as Apple's offerings for making apps.

[1]: http://developer.android.com/guide/appendix/market-filters.html

The features you speak of are exactly what I'm talking about.

When android phones are incompatible with some piece of software that is exactly what is going on. There is missing or old hardware that the software doesn't work on in the exact same way that your old Iphone doesn't work. If you are thinking that it's up to the user to sift through the android market place your a little behind the times.

Look I have no problem with Iphones. I show new users how to use them all the time (and yes setting up email and the like is difficult for a lot of people even in the Iphone.) I've developed a game for android, and haven't really run into the problem that Iphone people claim happens on android... More over I've taken to asking people about their android purchases and if they would rather have an Iphone and I have yet to meet someone who only bought an android phone because they couldn't get an Iphone. Most new buyers of android phones I've talked to actually seem pretty informed about the different available models and in most cases will tell you why they chose the one they did. Don't take my word for it though try it yourself.

http://developer.android.com/resources/dashboard/platform-versions.html

Humorously the uptake rate of new Android versions exceeds the rate that Apple has gotten updates adopted.

The Android App Store?? Since when? I've never heard it called that, at least officially, in any trade press, IT journals, etc. Android calls it (and always has) the Android Market. The Microsoft Zune has the Zune Marketplace. So I'm sorry but I don't see why Apple can't use App Store, especially when Microsoft gets to hold separate trademarks for Office, Word, Windows (note, the Microsoft and the other word each are separate trademarks).

As a soon to be full-time mobile game developer, I had done some research into the Android platform and it turns out targeting version 2.1 and up is the way to go: http://developer.android.com/resources/dashboard/platform-versions.html 12.6% are still running 1.6 and 1.7. Not only that 2.1 devices are much more capable with faster CPU and GPUs. In my case, I plan to make an engine that run OpenGL ES 2.0 only. Screw 1.1 and it's fixed function pipeline and its wimpy ARM 9 CPU's!

Yeah, it looks like they have a check for it, but it wasn't available until API level 7 (2.1), and so they probably have plenty of pre-2.1 apps that don't include that string as part of the package.

Now that pre-2.1 devices are becoming fewer and far between, as well as their promised rewrites of the App Store (which, per their demos as far back as 2.2's unveiling, included being able to buy apps from your computer and push them to your device), they'll either kludge something in there, or tell app developers that if they want their app to appear on a tablet they have to use a post-2.1 API level.

Then program in C and stop complaining:
http://developer.android.com/sdk/ndk/index.html

This one is one that that gets to use the Android marketplace.

The statement "run inside of a virtual machine" is misleading, it conflates two different meanings of "virtual machine".

1. Linux virtualization using namespaces etc or a hypervisor.

2. Java virtual machine, the bytecode interpreter.

Android uses neither according to this page. It does however play fast and loose with terminology. I have never heard a linux developer refer to normal Unix style uid security as "sandboxing", whereas the referenced page seems quite comfortable perpetrating that abuse.

I guess the bottom line is, don't blindly accept something as gospel just because it is posted on a Google site.

How about ARMv5TE and ARMv7-A?

O rly?

If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device.

It's funny that you claim it doesn't run within the VM yet Google says just the opposite. Oh who to believe...

GPLv3 is the wrong license I believe.

Android is GPLv2 and Apache 2.0.
http://source.android.com/source/licenses.html

http://mobile.slashdot.org/comments.pl?sid=1930156&cid=34715272

Read that, it covers your points on this quote from you:

"Ok so what if the botnet uses IP addresses?" - by cmdr_tofu (826352) on Thursday December 30, @05:44PM (#34715798)

Sorry saying that malware writers "generally" don't use IP addresses, does not mean you can trust that they never will as a form of security.

"Or the user does not have root access on their phone" - by cmdr_tofu (826352) on Thursday December 30, @05:44PM (#34715798)

That's WHY I had to use ADB for Android (dev tools are the 'secret' here & they're free, afaik @ least, for phones!)

---

ADB does not give you a rootshell. It's not a secret. The dev tools are easily available from http://developer.android.com./ If you get a shell with adb on a non rooted device, I think you will have a tough time writing to /etc/hosts

People:

1.) Make mistakes

2.) Folks get "lured" into clicking on URL's that MIGHT be "bad ones" (tiny URL for example? It "backfires" here, imo @ least)... especially from folks you "trust"

3.) You might "let your guard down"?

There's others, those are just some "possibles"... offhand, on "short-notice" etc.! apk

Clicking a url, is not the same as installing an application, unless there are some serious software vulnerabilities I don't know about. If that is the case, I'd rather use a more secure web browser that doesn't allow installing .apk's without my control than rewrite my /etc/hosts file, as an attempt to cripple malware.

I think icebike said it best above where he said, just don't install malware-ridden Android apps from dodgy warez sites. Use the Android Market.

You will need a new-ish (core 2 or better, probably) computer to even run the emulator. Download the SDK and Eclipse and then set yourself up to test on your phone and save yourself a lot of grief. http://developer.android.com/guide/developing/device.html

It has worked just fine for me on every environment I have tried it on (Win7 x64, OSX 10.6, various versions of Ubuntu.) It also didn't require me to spend 50 dollars on a book that wouldn't have much more information than the official developer site.

Not quite ;) http://developer.android.com/guide/tutorials/hello-world.html

http://developer.android.com/sdk/ndk/index.html Not really an issue?

support so I dont have a clue what the VLC guys are going on about... more info here

That the NDK was not up to scratch until the 2.3 release?

Like the news story says

"With the newer Android NDK, however, using native codes for Android apps has been becoming easier."

support so I dont have a clue what the VLC guys are going on about... more info here

That article is out of date, from May. It claims only 27% of Android users support version 2.1 or higher. Looking at the current numbers, that has obviously changed a lot over the past 7 months:

Platform Versions

Now it appears that 83% of devices are running 2.1 or higher.

In other words, the problem isn't as big as everyone claims. Yeah, periodically applications will be released that require the latest OS version. It doesn't take long for everyone to catch up.

This is a real problem affecting both users and developers.

Yeah, a real small problem.

For the Android OS there is: The Android Open Source Project

However, as far as I understand it, there are some hurdles with regards to building a ROM depending on the phone you have. Some have locked bootloaders / proprietary drivers.

For apps, there is a lot of stuff on GitHub, but as someone else already posted that requires the dev to have shared the code.

If you root your device a good firewall is DroidWall

On an Android device, if you specify the required version of the OS correctly in your app, it will simply not show up for the user with old OS in the Market.

As I understand Android Market packaging, a package specifies the API level. It does not specify specific point releases. The difference becomes important if you want to avoid Android versions that have, say, an SSL vulnerability.

Besides, there are still a lot of Android devices that support loading APKs from "Unknown sources" but don't support Android Market. These include most of the Chinese tablets, as well as every Archos product.

What's your beef with the Android NDK then?

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

Why do you think Android devices can't be upgraded or patched?

Because Google hasn't managed to coax Android phone makers, even those in OHA, to make Android upgrades available. Carriers and device makers have been less than forthcoming in pushing out operating system upgrades for existing devices, instead preferring to treat the new operating system's features as bullet points to sell replacement hardware.

In fact, if it couldn't be upgraded that would be better from a corporate standpoint because it would be a consistent platform.

Every iDevice sold since the App Store began operation in the iPhone 3G/iPod touch 2 days can be upgraded to iOS 4. For this reason, app developers can more or less safely assume that anyone who bought an iDevice since the "there's an app for that" campaign either has or can get iOS 4 and can buy apps. Android, on the other hand, has a large proportion of handsets stuck at 1.6, and plenty of non-phone devices with no official access to Android Market. Google gives no information beyond "If you don't have access to Android Market, please contact your mobile service provider or device manufacturer for more information."

Lol! Do keep up!

http://developer.android.com/resources/dashboard/platform-versions.html

So...target 2.1 then? Or, get this, target 1.5 then it'll work on all later (minor) updates.

That was hard.

Actually, Android is built upon a virtual machine tech that is pretty close to what you just described.

Well, close as in free beer. But VMWare is almost layering on VMs to a VM (Dalvik). Interesting. Dual phone numbers are already possible, either with dual SIMS or some CDMA witchery in silicon, and split personalities are something RIM has dabbled in. Android makes this much easier, since it is so close to Linux that work on one can be brought to the other without building from scratch.

We'll see, but I, for one, welcome our virtual Android overlords. Gotta be a way to assimilate this technology to my personal benefit.

Nexus S will ship with support for "fastboot oem unlock", allowing for reflashing of the system software "out of the box", like Nexus One.

Something that may interest this community is that the NDK (native development kit) for Gingerbread now supports native apps (intended to simplify mobile gaming ports, etc) -- providing: libc, libm, libz, opengl|ES, opensl|ES, input/events/sensors, app lifecycle management, etc. JNI is available to access various higher level Android APIs as necessary.

2.3 (platform 9) SDK: http://developer.android.com/sdk/android-2.3.html
2.3 (revision 5) NDK: http://developer.android.com/sdk/ndk/index.html

Platform sources should ship at or shortly after commercial launch of Nexus S.
Kernel git repository (2.6.35 + android + s5pc111/nexus-s) will be available at or shortly before launch.

Enjoy!

Nexus S will ship with support for "fastboot oem unlock", allowing for reflashing of the system software "out of the box", like Nexus One.

Something that may interest this community is that the NDK (native development kit) for Gingerbread now supports native apps (intended to simplify mobile gaming ports, etc) -- providing: libc, libm, libz, opengl|ES, opensl|ES, input/events/sensors, app lifecycle management, etc. JNI is available to access various higher level Android APIs as necessary.

2.3 (platform 9) SDK: http://developer.android.com/sdk/android-2.3.html
2.3 (revision 5) NDK: http://developer.android.com/sdk/ndk/index.html

Platform sources should ship at or shortly after commercial launch of Nexus S.
Kernel git repository (2.6.35 + android + s5pc111/nexus-s) will be available at or shortly before launch.

Enjoy!

What about the support for a barometer?! Finally, I will be able to rest at ease...

Hey .. shit for brains ..

Show me where I can download and compile my own version of htc sense ?? Or the 2.1 package that sprint just pushed ... Or any of the manufacturers specialized versions.

Come on .. please .. show me , I would love to see it.

Stock froyo (which is what my phone runs): http://developer.android.com/sdk/index.html

And this is where you get Samsung's froyo mod: http://opensource.samsung.com/ (search for i900 under mobile )

And this is where you get the source for the HTC phones: http://developer.htc.com/

I guess you love to see that?

Unless you can do that , your comment about the OS being open source so you can check it , is just stupid.

Even if you were right about manufacturers releasing the source, my point about stock android being open would still completely valid. Parent said it was google that made them so nervous. Sense, motoblur, and other android mods were written by hardware companies. And if your hardware manufacturer wants to snoop on you, they don't have to modify the OS. Which was, of course, my actual point.

Shit for brains.

A good working app market, and goog google services is one thing. But they can still win customers back. The one thing on the side of google is time. Google does have early access to next release of android. Members who do not play the rules correct will only have very late access to the latste version of android. Google will release source eventually, but when the latest google phone is released, google already tested it for several months with the very latest version of android. After that they start to release the software. From that moment "strange"handset makers can port their software to that version. With good quality control they are about 6 months later. after 6 months google has already released or announced the next version.

So handset makers can release bing/baidu apps on android, but only on old android, not the newest/latest. This might be acceptable on "budget" phones, but not on high end phones.

11 Jul 2010 Android 2.2 release on HTC high end phone
No source for 2.2 on official site today 20 nov

Android NDK.

http://source.android.com/

That's got exactly the same clause in its terms and conditions too. Or did you think I hadn't checked?

http://source.android.com/

That's got exactly the same clause in its terms and conditions too. Or did you think I hadn't checked?

http://source.android.com/

"Somehow I think Android is a) a product and/or b) a software related to c) the OHA website (and/or the OHA itself which is also a Google trademarked name.)"

Your thinking is incorrect.

> very much the same thing that Microsoft did

Let's clear this up a last time. Microsoft and Google did _very different things_.

As you agree, Java is a language (syntax) _and_ a platform (the API and the VM). (actually there are 3 platforms from Oracle: ME, SE, EE)

Google is using the _language_. Google never said it was using a _platform_ from Oracle. Check http://developer.android.com/guide/topics/fundamentals.html

Microsoft on the other hand was implementing a JVM for Windows, under a license to do so from Sun. Microsoft extended the platform in a non cross-platform way (against the license) in order to "Kill cross-platform Java by grow[ing] the polluted Java market." Doh !

http://en.wikipedia.org/wiki/Microsoft_Java_Virtual_Machine#Antitrust_trial

This is *very* different!

So now back on the android/dalvik google/oracle suit.

> Dalvik shoots Java ME and probably also JavaFX in the head.

First JavaFX is for the desktop. Nothing to do with the mobile.
Second JavaMe has had its success (2B devices) but isn't technically adapted to compete on smartphones. It's a 10 years old platform. The programming model for application developers is outdated. The licensing scheme (and fees) is not adapted, and the amount of work for implementors is too large. Android seeks and manages to alleviate those issues.
Third, Google is under no contractual obligation to not compete with Sun on providing a _platform_ for mobiles.

> That is not in Sun's interest, not in Oracle's
> interest, and generally not in the development
> community's interest.

It's not in Sun's interest, it's not in Oracle's interest but who says it's not in the community's interest ? You ? Based on what ?

As a developer, I say: JavaMe doesn't work for everything, there's a better technology out there, let's use it.
The manufacturers say: this allows us to focus on building and selling a phone, not a VM and software stack. Great !

Only Oracle is unhappy because their expected revenues on JavaME are potentially reduced.

> Google/OHA should not be allowed to fragment the Java platform [...]

JavaME and JavaSE are already different platforms you know ? There's no such thing as a unique Java platform.
Google isn't thus fragmenting _the platform_.

> Google could have worked with the community to
> fix JavaME and JavaFX, but Google doesn't foster
> than kind of an environment internally.

You can't fix an inappropriate platform. You replace it: the VM, the class libraries, everything had to be modified in a non compatible manner.

So why would Google help Sun/Oracle create something that only one compagny had control on ? No one wanted that. Hence the OHA.

Given the patent wars risks & the market complexity, with its reuse of the Java language, development environment and developer pools, the reuse of Apache code, the OHA, Android is one of the smartest move in the industry in the past years. Sun couldn't pull that. Google did. Oracle is pissed because it kills their revenue forecast. But there's a big chance Oracle cannot do anything about what Google did. Google carefully thought their plan, and Sun/Oracle's patents/copyrights/license&strategy may not have protected them against Google's move. That's called business.

Now instead of working hand in hand to make the language and the platforms more universal, Oracle seems to have taken a step against, alienating some of their best supporters (developers and FOSS community). That's a very very bad long term move for the platforms that Oracle present.

To me, the one who is damaging the most the platforms, isn't Google. It's Oracle.

Er vi enig ?

Toast Notification

A toast notification is a message that pops up on the surface of the window. It only fills the amount of space required for the message and the user's current activity remains visible and interactive. The notification automatically fades in and out, and does not accept interaction events. Because a toast can be created from a background Service, it appears even if the application isn't visible.

A toast is best for short text messages, such as "File saved," when you're fairly certain the user is paying attention to the screen. A toast can not accept user interaction events; if you'd like the user to respond and take action, consider using a Status Bar Notification instead.

For more information, refer to Creating Toast Notifications.

Something like that? If you need feedback, then you'll need to do some hacking, but you specifically said you "just want to create a popup window to tell the user something" :)

No, I don't develop android apps (hate java), but had a look at the API some time ago, and remembered that one.

Note that the user being a monkey might be a sort of exception that should never happen. A definite WTF moment, for sure.

Android applications are written in the Java programming language

Does formulating this in the way they have give Oracle access to the Google code to see if the code was in fact copied byte for byte from Oracle

You mean this code?

The first that comes to mind is how Android is all about tossing aside everything that is open source as we know it and reinventing the wheel. The catch is that the wheel has not necessarily been improved, and now it's all under the control of Google, who does development behind closed doors and only allows hardware vendors to participate in the process.

FIrst, Google doesn't own Android, the Open Handset Alliance does (Google did briefly, when it bought Android and before the OHA was put together.)

Second, Android development is done through the Android Open Source Project. Nothing excludes participants (including individuals) who are not "hardware vendors" from participating.

Which is unsurprising, given that most of the Open Handset Alliance members themselves aren't hardware vendors, including the software and online services companies that no doubt have just as much interest in the actual Android platform software as the hardware companies.

Possibly because of the same restrictions placed already by Dalvik on the type of libraries one can execute under the java.* and javax.* namespaces.

I'm not sure what you mean by this. Android does not provide the complete set of J2SE class libraries, but that's not a restriction, it's just a lack of a feature. You can write your own and use them, and it won't stop you.

I mean, this is all speculation from my part, but if Dalvik - by design - restricts on what is available under the java/javax namespaces (for a variety of reasons), it will also follow that it will put restrictions on executing arbitrary native code via JNI (as Google App Engine does now.)

No need to speculate. Android does support JNI, and it does allow arbitrary native code execution.

You can write (C and C++) native code on Android.

The Android Scripting Environment adds several scripting languages to Android.

This!!

As well as crap interaction, the UI objects are damn ugly, and don't scale nicely.
Date and time together don't fit on a single line of a regular screen.
After using the iOS UIDatePicker I thought the Android offering was a joke.

The first time I read the API docs I was convinced it must be a joke.
I scrolled around expecting it to say:
"Obviously, developers should be using class X in preference to this steaming mess."

There is absolutely no consistency between the DatePicker and TimePicker classes.
The DateView takes its listener in an init method (WHY??), the TimeView has a set method.
The DateView is updated with a single call (or when you want to set the listener LOL), the TimeView has separate methods to set hours, minutes and AM/PM.

Actually making use of them is a massive headache.
Come on guys, I probably want to handle my date/timestamp in UTC and as a localized string, at a bare minimum.
It's pointless building on what's in the API because it doesn't even work properly!
Time.format doesn't implement strftime options correctly, with no information about what is actually supported at all from the man page it refers you to. At least developers on Windows won't be misled.

App development for Android takes extra work handling these sort of things, because even if things are fixed in future versions not all devices will get the upgrade.
The issue of fragmentation becomes more serious when such basic elements of the platform are left neglected for so long. This should have been put right after the first public release at the latest.

This!!

As well as crap interaction, the UI objects are damn ugly, and don't scale nicely.
Date and time together don't fit on a single line of a regular screen.
After using the iOS UIDatePicker I thought the Android offering was a joke.

The first time I read the API docs I was convinced it must be a joke.
I scrolled around expecting it to say:
"Obviously, developers should be using class X in preference to this steaming mess."

There is absolutely no consistency between the DatePicker and TimePicker classes.
The DateView takes its listener in an init method (WHY??), the TimeView has a set method.
The DateView is updated with a single call (or when you want to set the listener LOL), the TimeView has separate methods to set hours, minutes and AM/PM.

Actually making use of them is a massive headache.
Come on guys, I probably want to handle my date/timestamp in UTC and as a localized string, at a bare minimum.
It's pointless building on what's in the API because it doesn't even work properly!
Time.format doesn't implement strftime options correctly, with no information about what is actually supported at all from the man page it refers you to. At least developers on Windows won't be misled.

App development for Android takes extra work handling these sort of things, because even if things are fixed in future versions not all devices will get the upgrade.
The issue of fragmentation becomes more serious when such basic elements of the platform are left neglected for so long. This should have been put right after the first public release at the latest.

This!!

As well as crap interaction, the UI objects are damn ugly, and don't scale nicely.
Date and time together don't fit on a single line of a regular screen.
After using the iOS UIDatePicker I thought the Android offering was a joke.

The first time I read the API docs I was convinced it must be a joke.
I scrolled around expecting it to say:
"Obviously, developers should be using class X in preference to this steaming mess."

There is absolutely no consistency between the DatePicker and TimePicker classes.
The DateView takes its listener in an init method (WHY??), the TimeView has a set method.
The DateView is updated with a single call (or when you want to set the listener LOL), the TimeView has separate methods to set hours, minutes and AM/PM.

Actually making use of them is a massive headache.
Come on guys, I probably want to handle my date/timestamp in UTC and as a localized string, at a bare minimum.
It's pointless building on what's in the API because it doesn't even work properly!
Time.format doesn't implement strftime options correctly, with no information about what is actually supported at all from the man page it refers you to. At least developers on Windows won't be misled.

App development for Android takes extra work handling these sort of things, because even if things are fixed in future versions not all devices will get the upgrade.
The issue of fragmentation becomes more serious when such basic elements of the platform are left neglected for so long. This should have been put right after the first public release at the latest.

Android has an All/Some/None setting to turn off UI animations, in Settings/Display/Animation, so once again it gives people the choice.

It's been there since 1.6 at least.

You get the most flexibility with an Android Dev Phone.

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

If you're in the US and buy a carrier-locked/customized phone, you have to read the fine print and experiment; I've never bought one of those.

In most of the rest of the world, you just buy whatever phone you like unlocked and plug in your SIM card. The HTC Desire is a good choice: nice hardware, good updates, actually useful add-on software.

You can also buy any European Android phone and use it in the US, but you lose 3G; you still get EDGE. In a year or two, they're going to be penta-band Android phones, which will give you 3G worldwide and on AT&T and T-Mobile.

I didn't know either. Google shows the official word, indicating that repo is a customization of the git file repository/version control manager. repo init preps a place in your HD and works across different repositories, aided by details from that manifest file you give it with the -u option.

repo sync does the actual updating of the code [or if needed, the very first download to your repo folder]

make is a unix compilation tool that by default runs scripts called makefiles. Those specify what to compile, in what order, what special options to use, and where to install each output file. Make automates a secuential process that can easily take minutes to hours. However, here make might be a special purpose binary here.