Slashdot Mirror

And if you happen to be developing native application code for Android using the Android NDK or contributing to the Android OS itself, you will be writing it in C.

Ok, so that first result on google: http://www.android.com/market/

Where's the search box?

Agreed. I keep thinking I'm doing something fundamentally wrong... I can search for apps on my Droid but I can't find a website that lets me search through the apps or browse the app categories. Apparently there are roughly 30,000 Android apps, but if you click around the marketplace, you'll get a sense that there's maybe 50 or 80 apps out there. This is both a problem for Android users (who can't find what they want... doing it on the phone is okay but not as efficient) and for uptake (it makes the platform look amateurish).

On the flip side, though, I can't imagine a worse move than "hand over the entire management of the Android Market to carriers, OEMs and trusted publishers." The carriers would turn it into a painful nickel-and-dime opportunity (forget free apps!), and letting OEMs and publishers do whatever they want would make the Android platform even more fragmented. Google is (in theory) the right entity to mange the Android Market: they have a good reputation, they are really good at sorting and search, they know how to make a good web UI, etc. In fact, it's fundamentally surprising that they didn't put together a slick interface for the Android Market...

http://www.android.com/market/

You can't search for apps. You can on the phone, but consumers need better integration and ways to access information.

Lets say you were interested in an Android device, how do you find out what apps are in the market?

I ahve sent several emails, and posted on the form.

There online market SUCKS.

I have a G1. it's running Google android OS. It is fully integrated with Google.

Why can't I go to android.com and do a search for apps?
Yes, a Google site and you can't search for market apps.

http://www.android.com/market/

Not searchable. I'm sorry, what is Google's core business?

Source is right here:

http://source.android.com/download

I suspect there is a lot of custom code/drivers for each specific handset model - while you can download the source to the android OS the expectation as an OEM is its your job to make it work on your device.

At the moment, I'd be quite happy with the source. The developer site provides lots of helpful tools and documentation for developing "apps" for the Android platform (the version of which you include as a component in the SDK), but I can find little about producing my own custom ROM to experiment with on my phone.

I suppose I probably have to just look through the SDK more carefully, if the workable source code isn't included in that download and I missed it, then I've no idea where it is. I haven't looked too deeply, but the SDK never gave me the impression it was for anything other than application development for Android (rather than Android development for my hardware).

Has anyone noticed how bad it is, that you have something that is supposed do be an open source Linux-based phone, and you don’t even have root access right out of the factory? Even worse, not only do you have to root it with a hack, but you are also supposed to feel bad about it when returning it for broken hardware (which has nothing to do with modded software)?

I have indeed noticed something at least a bit...off about Android phones, but that something could easily be something I'm missing. Before I explain my situation, perhaps someone with more experience can enlighten me: what's the deal with carrier released Android ROMs? More specifically, is this news only to Droid users who haven't rooted their phone, or are Android phone owners really not able to upgrade their OS version without a carrier release?

I've wanted an Android phone since the G1 was announced, more or less, but never could justify committing to the total cost of ownership (I get by with spending $10/mo on voice and ~$5/mo for 400 or so texts). Less than 6 months ago, I won a Samsung Behold 2 in an online giveaway (to my amazement). It's not the Android phone I would have picked by far, but it has enough of the hardware features one needs to use all the neat apps (touch, tilt, compass, gps, a rather nice camera, etc). Already being a T-Mobile customer, I put my existing sim card into the new phone, turned off all the wireless data conduits, and only use "network access" via WIFI (home, work, friends' places). I miss out on key things like maps and Internet outside where they can be most needed, but it works out well enough compared to the alternative of not having an Android phone at all.

As many will know, the Behold 2 shipped with Android 1.5 or 1.6. I have looked into rooting it but haven't put any serious effort into it yet, primarily because I haven't come across information on upgrading the OS version. I understand the advantage to getting a ROM from a carrier (e.g. I'd really like my camera software to keep working properly), but I expected to go to http://www.android.com/ and find a "Download Android 2.1 Now" link, with general documentation about how one goes about installing Android on their supported device.

All I find is the release notes and the SDK, which I've downloaded and used before with an emulator. If that's a path to upgrading my phone, I missed it (not having a phone at the time). If I have to root my phone before I can install / upgrade on that level, fine, just point me to a tangible Android 2.1 download I can use on my phone once I've rooted it. Since 2.1 is a big upgrade over 1.5/1.6, I'm not exactly going to be spending any money in the Android marketplace, since I don't know which weak points I want to replace are improved in the OS upgrade.

Well, the bootloader on the Droid is supposed to be signed, but there was a bug in the source code (patch) that let people sneak modified updates through. There's a good chance the official 2.1 bootloader will close this hole, since the patch has been merged already.

OK makes sense, but..
http://developer.android.com/resources/dashboard/platform-versions.html
wasn't too helpful. The previous answers were actually clear and useful something that sometimes lack on /. Thanks for the minSDK thingy though, I'll look it up.

This might be a little more helpful. The blog was just regurgitating this page, but was out of date anyway.

1. Android doesn't run JVM (it runs Dalvik VM).

2. Android has an officially supported way of developing native code applications.

You fail at life. The JVM is not a walled ghetto. You can go ahead and write whatever you want for it. You can also write portions of your app natively if you wish: http://developer.android.com/sdk/ndk/index.html. What you're doing is akin to complaining that you can't install windows on your power pc.

Couple of things to keep in mind in the iPhone vs Android development wars:

1) Android also allows native (C/C++) development with the Android Native Development Kit (NDK): http://developer.android.com/sdk/ndk/index.html#overview

2) If Android apps do become popular and a competitive advantage, AFAIK there's nothing to stop Apple or someone else from porting Dalvik and underlying libraries and services to the iPhone. After all, both the iPhone and Android are at their cores just little unix boxes. If so, the project should be called Blade Runner. The Warner Bros lawsuit would be good publicity.

What a bunch of dip-shiat posers. First, Android apps are run on a virtual machine (yes, that's right, even on the phone). If you've actually cut code for Android, you would probably be familiar with the build/test cycle which consists of compiling and running on an Android Virual Device (AVD - an emulator that lets you simulate different phone configs) which comes with the SDK. The emulator supports multiple resolutions as well as multiple versions of the Android OS. Screen resolutions are really not that much of a challenge. Funky hardware (say, a totally bizarre, non-standard GPS chip) might be, but I have yet to run into a situation where the Android SDK doesn't provide an abstraction that just takes care of it for app development.

Here's a link to the Android developer documentation on the multiple screen resolutions. It just isn't that tough, and anyone who says multiple screen resolutions are either has never cut code for Android or simply is incapable of reading the manual.

Note to Mr. Buy A Lot of Hardware: Your code does not know the difference between being inside an AVD or running on a real phone. I think someone at your company has a fetish for gadgets and is tickling it at your expense.

Note to /. at large:RTFM before opening mouth, RTFM and you'll be amazed what you learn. For the n00bs: RTFM = Read The Fscking Manual. More for the n00bs: typing $man fsck is not what RTFM wants you to do.

Ironically Android has been designed to provide developers a way to write one application that can be supported by many devices. It's also open source, and the SDK (and built in emulator) is freely available. This means if you want to be an expert on Android, you can download the SDK, and EVEN WITHOUT OWNING AN ANDROID PHONE write your very own applications... or try to or whatever. Just stop acting like you know what you are doing or you are some mobile software development expert when you don't even know what some guy who just installed the SDK knows about 15 minutes into trying out the SDK. Sheesh. // Feel Better Now
/ /. continues to be /.

Yes they will know the syntax of the language but the libraries will be totally different.

Actually, they're mostly the same. They took the standard libraries from Apache Harmony. It's missing a few packages that aren't appropriate (like Swing), but most of what a Java programmer expects to be there, is there.

Here is the index to the API docs: http://developer.android.com/reference/packages.html. As you can see, a large fraction of the java.* and javax.* packages are there.

developers are up in arms?

Didn't you read the dozens of articles on the net about how Apple works with regards to The App Store? They're like Cohaagen in Total Recall, absolute rulers. It's their shit and they can fuck with you however they want in the most inconstent way they like and there's absolutely nothing you can do about it.

Sorry, but you developers who get fucked over by Apple can just STFU. That's the risk you took when you went iPhone. Maybe you should have considered developing for a more open OS

As somebody who has written an app for both J2ME and Android, that comparison is really far out.

There are some key differences between J2ME and Android:

• Android is an implementation, J2ME is a spec. Developing for J2ME is a nightmare because practically every phone has a unique combination of serious bugs. This isn't true of Android because every phone is working off the same core code. If manufacturers want to modify that code, that's OK, there's a test suite they have to pass if they want certain things.

• Androids "fragmentation" is actually simply that not everyone has upgraded yet - no different to any other platform (including the iPhone). But Android manufacturers have a history of upgrading versions, and I don't see much reason for them to change this: customers demand it and because Android is open source, doing the upgrade is effectively "free" by mobile development standards, even for things like Sense UI (the APIs are backwards compatible).

• You can see what versions are in use. So there's no guessing about what you can or cannot use, API wise, it's easy to see.

• Android explicitly supports writing apps that run on multiple platform versions, where as J2ME never really did. For instance you can hide your app from earlier devices (in the market), or you can make your app gracefully degrade on older devices.

• Android does actually standardise hardware, it just doesn't standardise on exactly one set. For instance, you can assume all Android devices have a decent touch screen, a display that uses one of a handful of resolutions and so on.

• Google only lets manufacturers distribute certain closed source apps (like Market) if they meet certain conditions. Google has every incentive to keep as many people on the latest version of Android as possible. They have the leverage needed.

In short, it's a slow news day and InfoWorld know how to stir up a story.

Android has a NDK (Native Development Kit); it's possible to write Android apps for the Market in languages other than Java.

Not to mention Google Federal or Google's Fiber plans or you know, Android.

At least we don't have to be afraid of a GoogleBot android that's out to terminate us... uh, wait!

Captcha: encore
Well thanks, I'll be here all week!

How does that work? The only thing I can imagine worse than not supporting multitasking is supporting it, and then randomly killing background tasks when you run out of resources. I'm sure it doesn't work quite like that, but I can't find more info about exactly how android supports multitasking.

It's something like a task is sent a "you're being backgrounded" message when you switch away from it, and it's up to the app to do whatever makes sense for it to do in that case (usually save all its data ready incase the phone is rebooted or it gets killed while backgrounded). Then the app can be sent a "please stop" or just get killed. Obviously, like any system, resources are finite and it is possible for a running background process to be killed, but that's not normal.

http://developer.android.com/guide/topics/fundamentals.html

You can listen to music at the same time as doing other stuff on the iPhone/iPad

Yes but the only reason is because Apple's own software has special privileges to do so. A 3rd party music playing app cannot, eg Spotify.
So it's obviously possible and desirable in some circumstances, just not permitted by the Apple overlords. Which means that no, Apple have not thought how to "do this properly".

Thanks for the info. I found a link the feature.

http://developer.android.com/sdk/ndk/1.6_r1/index.html#overview

Android isn't really a product of the free software movement, it's a product of Google.

Bullshit. Android is a product of the Open Handset Alliance--of which Google is a key member. Android is also completely FOSS. I can download the source code to all of android from here, change what I would like and recompile/redistribute it. I may not be able to include Google's proprietary apps, but Android's base is still FOSS. I don't see anyone being able to do that with the iPhone, although it does rely on a great many FOSS utilities.

I'm sure we'll probably see safe app repositories for Android in short order though

Already exists: http://www.android.com/market/

Nokia have their Ovi Store too, and plenty of other phone manufacturers, not to mention the networks too. The difference is you can choose where to go, rather than only having one option, of course.

I doubt it is Apple, they don't have book content or a all that desirable of a brick and mortar presence. Barnes & Noble is a content provider, and being a droid, has a development kit and a emulator so it will have apps in no time. Having a small LCD and 802.11 to play with will give it a (IMHO) huge advantage.
I could see the nook e-reader add-on to any game/game system. since it has 802.11 wireless it could easily be a extra screen. This would be very handy for multi-player games, IE select your plays for football without the opponent in the same room seeing your options. Pass it around for any time of strategy/puzzle game. Or just have it giving extra directions or tips.

The trouble is that H.264 is very likely to be the source. My Droid records in H.264.

You're highly unlikely to find a portable that records in Theora. It doesn't even merit a mention as an Android core media format

This is obviously just Android, but I'm fairly sure it's representative of the industry's choices.

The gripes are, unfortunately, mostly off target. But you can't blame a developer for having gripes. They deserve an answer. So here goes:

1. Open Source

The heart of this gripe appears to be "What's worse is Google knows how to protect valued code; Its Maps, Gmail, and Store applications aren't open source. Figuring out when it's okay to include one of those in your own application requires a crack legal team with a hotline to the EFF. "

This is a non-issue. Google hasn't released any proprietary code. Using the capabilities of these applications, or any other FOSS or proprietary applications in Android by means of their remote method interfaces or their Intent filters is OK unless the APIs require a key, as with the maps APIs. The process of getting a Google Maps API key is described here: http://code.google.com/apis/maps/signup.html and most introductory Android programming books cover it, too (http://www.amazon.com/dp/0596521472 in chapter 7). J2ME, BREW, and Symbian all require app signing and all support protected APIs.

2. The Tyranny of the Activity

Android has a unique programming model. It wasn't designed just to make a coder's life difficult. It was designed to prevent a small-screen UI from becoming a maze of hierarchical screen transition and enable re-use of functionality across applications. Android makes "shoveware" ports look bad, which is what Haseman seems to be griping about.

3. Device Debugging

This "gripe" is not really a gripe, but good-natured praise for the ease of debugging on Android.

4. Applications Never, Ever Quit

Android has an interesting and powerful application lifecycle. And, since Android is multi-tasking, more developers will notice that their application has a lifecycle.

5. The Developer Cooperative

This is a valid gripe: On the one hand, Android can manhandle your application's lifecycle, and on the other hand, it is fairly easy for applications to become battery-eaters. Google's developers could have done a better job of automatically detecting battery vampires. Use the "Battery use" in the "About phone" menu in "Settings" to find the applications and other system functions using the battery. That's a tip taken from this article: http://answers.oreilly.com/topic/862-ten-tips-for-android-application-development/

6. Java—Thanks, But I'll Take It from Here

Haseman says: "While it might speed time to market by freeing us from chasing down heap corruptions and memory leaks (two of my least favorite tasks), it can make it nearly impossible to, say, write an anti-aliased font library that renders in a reasonable amount of time. Sure, a developer can write custom libraries in C with their NDK, but now we're debugging two languages instead of one."

Java in Android runs on the Dalvik VM, which, up to now, is a pure interpreter: No precompiler, no JIT. It relies completely on the ability to mix in libraries in C via JNIs http://java.sun.com/j2se/1.5.0/docs/guide/jni/spec/jniTOC.html and the NDK http://developer.android.com/sdk/ndk/1.6_r1/index.html.

Why? The short answer is it is hard to put a JIT compiler in a battery powered device. So the developer has to decide what code belongs in Java and what code belongs in C.

7. "Intents"

Here I am right with Haseman, since his gripe is having to write (http://www.amazon.com/Android-Essentials-Firstpress-Chris-Haseman/dp/1430210648/) about classes with names that lend themselves to drifting into being nouns. The Activity, Intent, and Service classes in Android twist up one's prose worse that quarks tha

the baseline Android memory class is 16 (which happens to be the Java heap limit of those devices); some device with more memory may return 24 or even higher numbers.

In practice, is the amount of available ram actually higher than 16M on most platforms? I haven't bothered to check what my droid returns for ActivityManager.getMemoryClass(), and I don't have a HTC or any other Android phones. As a practical matter, am I over-constraining myself by limiting myself to just 16 megs?

Until a competitor's phones can run a like-kind OS to the iPhone, and match their functionality in a robust way (sufficient to compete directly), Apple has a monopoly.

Done.

You can't switch to a "Nokia brand iPhone" that provides equivalent functionality to Apple's iPhone,

However, you can switch to a Nokia brand smartphone, which provides equivalent functionality to Apple's iPhone. In fact, Nokia has a larger smartphone market share than the iPhone.

How exactly can Apple have a monopoly when they don't have the largest market share in their own market segment?

Either way, this is a pretty clear example of why no company should be allowed to have control over what software consumers can put on devices that they own

Depends on the consumer.

The idea of trying to clean malware off my parent's iPhones gives me nightmares. And I can guarantee they'd get infected if it were possible to install any old app, or if Apple had to allow any old app in the store. I'm rather happy they can only get apps that have been blessed by Apple.

OTOH, I'd like more options. Fortunately, Apple's got competition.

Screen size can be largely irrelevant with Android: everything is based around screen density.

It's all been built into the core of Android since version 1.6. See this table for a description of the standard densities and screen sizes supported.

I've been working on an app for a new high-density device and using the API features above, it looks great on a "regular" DPI device too, and even on the new low-DPI devices that are coming out in the next few months.

Most of Android in general (ie new code) is Apache 2.0. Parts of it use other licenses; Linux is GPL, Webkit is LGPL, SQLite is Public Domain, etc. Patches they submit to those upstream projects maintain the original license of that project.

Citation

Too late. The wiki is dead.

Here's the text from the "Rooting" page:

======

Looking to root your nook? You have come to the right place!
nookDevs.com is not liable if you screw up during the root process. kthxbai
This will probably void your warranty, nookDevs.com is not liable for that either.
[edit] Requirements

microSD(HC) card adapter
Small screwdriver
45 minutes
Fingernails or a sharp knife
A linux/unix based computer
Android SDK
[edit] Instructions

Turn off nook
Take off the back cover of the nook
Remove the battery
Remove the user microSD card if there is one
Unscrew all screws. Dont lose them. There is a hole in the bottom left with white in it. That is also a screw. Unscrew that.

There are a bunch of tabs around the sides of the nook that release the white bezel. Once released you will need to unseal the glue
Congrats you are 25 percent there!
There are two black tabs on the sides of the nook where the page turn buttons are. Push those back to unlock them

You should be at the board now. Find the OS microSD card

Remove it

Place the microSD card in a adapter, then into a computer
Mount it as ext3 read-write (sudo mount /dev/sdb1 /media/disk replacing values as needed)
Open the file init.rc as sudo (sudo nano init.rc)
Find the line that starts talking about adbd
Replace the first occurance of the word disabled with enabled
50 percent done!
Eject SD card
Put SD card back into nook
close nook up
restart
Now, on a computer again, download the Android dev toolkit (google it)
Open a terminal
cd to the android folder
cd tools ./adb connect IP_OF_NOOK:5555 ./adb shell
If you want to disable updates from B&N run: mv /system/etc/security/otacerts.zip /system/etc/security/otacerts.zip.bak
CONGRATULATIONS! YOU HAVE ROOTED YOUR nook. Have fun, be safe, dont forget to bring a towel
[edit] Notes

More pictures for tutorial to come later
Make sure to put the SIM card back in correctly if you remove it. Blue and white site up with the notch in the battery compartment opening end, on the right hand side. Refer to included pic. (discovered nook 3G not working when I got to work. Paperclips make terrible screwdrivers)
Android Debug Bridge (adb) is a versatile tool lets you manage the state of an emulator instance or Android-powered device.

Full documentation and list of commands available in adb can be found here:
http://developer.android.com/guide/developing/tools/adb.html#commandsummary

Android 2.0 Highlights

Multiple accounts can be added to a device for email and contact synchronization, including Exchange accounts. (Handset manufacturers can choose whether to include Exchange support in their devices.)

The Droid was the first Android 2.0 device.

"locks third-party developers into a crippled Java sandbox"

Hmm, no it doesn't. Android offers an NDK for native application development. Yes your application entry point is still Java, but using Java's Native Interface (JNI) the main part of the app can be native (C/C++) just fine. It already supports native OpenGL ES 1.1 which is great for 3D games development on G1 or Droid phones which have great 3D graphics hardware.

note: I develop native apps for Android for a living.

Perhaps someday such a system will become viable with much more powerful mobile hardware and better thought out security system that allows more functional legitimate apps

It's already here, and it's called Android. When you install an app, it tells you what permissions the app is requesting, and you can cancel if you're suspicious. Most operations that you'd consider potentially harmful or privacy-violating (reading various types of personal data, accessing the internet, making phone calls, preventing the phone from sleeping, etc.) can only be performed if the app listed the relevant permissions in its manifest.

It's not perfect... you know what the app is capable of doing, but not what it actually will do. Without looking at the code, you can't tell if the app that requests "read GPS position" and "access the internet" is going to send your GPS position to someone over the internet, or if the two features are unrelated. But it does prevent surprises like the ones in TFA.

http://www.android.com/branding.html

But they cannot call it an andriod phone without Google giving permission.

they can't effectively take advantage of advanced features or greater available resources in the high end phones, because they'll lose out on all of the potential customers with the lower end models.

The fact that lower-end models exist in no way prevents devs from taking advantage of the advanced features of high end phones. If high-end phones are their target market, so be it, and they can make money from sales to those customers. The API specifies a tag that can be used to restrict installation to devices that contain the features your app requires.

That combined with the iPhone running native code compared with Android running interpreted bytecode means that the iPhone completely beats the crap out of current Android handsets when it comes to 3d performance.

Android doesn't only run interpreted bytecode: the NDK allows you to write performance-critical code in C/C++. That's why there are usable emulators, ports like GLES Quake, and the Neocore demo I linked earlier.

Lots of stuff to be pleased with in the new SDK, but lack of half-decent audio/midi APIs still makes me angry.

What's wrong with the "raw audio recording and playback APIs" and "interactive MIDI playback engine" supposedly added in 1.5?

The good news are that they seem to finally have added the long-awaited support for multi-touch. As listed in their relese notes:

MotionEvent can now report simultaneous-touch information for devices that support it. Up to three pointers can be tracked simultaneously.

The bad news are that, apart from some improvements to the on-screen keyboard, the GUI doesn't seem to be making use of it at all. So, those of us hoping to impress our acquaintances by zooming web pages in and out iPhone-style will probably have to wait until 2.1...

For android can you go and find the 2.0 SDK anywhere? Nope. So much for Verizon's claims about 'droid being 'open'.

The Android 2.0 SDK is right here. And btw, Verizon has little or nothing to do with the SDK.

Android 2.0 SDK is out! Check out the goods here:
http://android-developers.blogspot.com/2009/10/announcing-android-20-support-in-sdk.html

Highlights:
http://developer.android.com/sdk/android-2.0-highlights.html

Did Raytheon miss the announcement that linux is open source too?

You know, it's entirely possible that they did. You should email them this link right away!

http://developer.android.com/guide/basics/what-is-android.html

Now that is a good argument in favor of less variety, and I agree that if HTC or Samsung, or whoever were to take their entire R&D budget and put it into a single phone, they may come up with an alternative that would out-sell a 10 phone lineup. Unfortunately, that is a lot of risk to take (what if it bombs) and the savings wouldn't be that substantial (most of the HTC phones have nearly identical circuitry, so they don't reinvent the wheel each time).

As far as compatibility is concerned... yes, more variety means fewer eyes on a single model which means there will be a few compatibility issues because a developer didn't consider that their app would be used with a trackball rather than touchscreen for example. However if a developer designs to the documented Android "Best Practices" http://developer.android.com/guide/practices/ui_guidelines/index.html then their application should be compatible with 99% of the Android phones.

Finally, the 50 handsets is 50 total across all carriers and markets. Many of the phones will have slightly different names and features and only be available with a single carrier. My guess is, if you go into a mobile store you won't find more than 2 Android phones from a single manufacturer for a given carrier.

You can download the Android SDK run the emulator and see it in action. Of course the emulator won't have apps like Market and you won't be able to make calls.

As for messaging, it uses a very intuitive conversation oriented layout. My phone has a physical keyboard, but even so I find myself using the on-screen keyboard more and more these days.

Of course, the big plus on the Android side is the growing developer community. It is extremely developer friendly as a platform and as a market-place. It is also nice to know that I can buy a phone from another manufacturer and keep the same software and not need to worry about synchronising contacts or calendar.

Java/Dalvik development only

As has been mentioned in previous posts, native C++ development is available via the Android NDK. Even native access to OpenGL is supported.

with their own version of the app store and installation verification

I guess you never clicked on a URL (in the built-in browser on the phone) that points straight to an Android Package (.apk) file and simply allowed the phone to install it. No "app store" required.

You're welcome. (Android NDK allows for native development.)

You still need a Java wrapper to handle communication with Android (keypresses and such) but the game can be written entirely in C/C++.

I'd say as far as development friendliness you should take into account that you can develop for Android on many platforms. For iPhone you must have OSX.

Yes, Android uses a converter that changes java bytecode to a different beast entirely, and performs a large number of global optimisations that decrease size and increase speed - ones that a compliant Java VM isn't allowed to do. So it ends up going about the same speed as JIT, but only needs the power a small phone supplies.

As for garbage collection - Android performs about as well as a C/C++ program filled with malloc()/free() or new/delete. C/C++ games programmers could do that, but they choose not to because they know that avoiding malloc/free/new/delete gives them a performance boost. Android has exactly the same tradeoff - avoid object creation in your code! Create what you need at the start of a level and then don't free it until the end of the level. You'll get good performance. Android has an entire section on how to get good performance, just like C/C++ programmers have plenty of strategies for getting good performance out of any platform.