Android: files on internal storage.

I'd only read/written to SD card files before. When you're writing to the SD card, you can use standard Java file I/O. But if you want to write to internal storage, you can't, because you're supposed to ignore where the files go.

You can do so with Context.openFileInput() or Context.openFileOutput(). When you do, the files will be in /data/data/your_project_package_structure/files/your_file. (yeah, that's two /data/s.) For example:
/data/data/com.dantasse/files/hello.txt

More details: official docs and someone's tutorial (which is a lot more useful).

Packages and Android internal data

1. Packages: there are two concepts of "package" on Android.  Here's a great overview.  Make a new Android application package for each project, don't change them if you can avoid it. In my case, I had originally started on my current project, "How are you right now?" with the package com.dantasse, but that leads to two problems:
- I couldn't install multiple apps with the Android application package com.dantasse on the same phone at the same time
- I couldn't publish multiple apps with the Android application package com.dantasse in the Android market at the same time.

2. Android internal storage: it's pretty opaque.  The official Android docs are pretty good at telling you how to access both internal storage (on the phone itself) and external storage (SD card).  Internal storage is easy to use, but AFAICT it's not viewable via the standard filesystem.  (I read somewhere that it goes in /data/data/(your app) , but I tried using Astro file manager to browse through it on the phone and couldn't find it.  And I wasn't able to mount the internal data on a computer, just the SD card.)
There might be something you can do with content providers or something to get this internal data out of your app, but I don't know it.

New Android App: One Photo Every Minute

It's an app that takes one photo every minute.  Or every 5 seconds, or 10 minutes, or whatever.  Wow!  Imagine the possibilities!
(EDIT: it's unpublished from the market now because it crashed a lot.)

And it was a surprising pain!  Some tips that might spare you some pain:

- don't try to use the camera without a preview.  It might work, but I feel like some of the developers might have been assuming a preview.  (all example usages of the camera, in docs and ApiDemos include a preview.)  At any rate, using a preview surface gives you a couple of callbacks that make it easy to manage the camera resources.

- you might get cryptic crashes or ANR's.  I don't feel confident that One Photo Every Minute is 100% crash free, even on the Nexus One I was testing it on.  This is awful.

Some general thoughts:

- At work, on servers, we use Guice and dependency-inject everything.  I tried to do the same here, and it was way overkill.  You can, and should, easily bang out a couple thousand lines of code without doing any DI.  (this means most of your code won't be unit-testable.  I'm okay with that.  No, this doesn't scale well.)  Maybe I'll get into specific issues later.

- Model-view-controller is a nice pattern.  This might be the app where I most specifically understood how it works, because I created classes called Model and Controller, and I designated the MainActivity class (plus the xml layout) as the view.  Totally great idea.

- Learn one or two things at once.  In this app, I tried to learn three (MVC, manual dependency injection, and Android camera apps).  That will just frustrate you.

- Launch as soon as possible.  Especially if you're fed up with the project.  After you launch a functional product, if it's just a hobby (and if it's free), you can stop working on it at any time.  Before you launch, if you give up, you've just wasted a lot of work.  You can always add features later.

- It's amazing the difference between a free hobby app and a paid or corporate app.  If Google or whoever launches a thing with a minor flaw, people jump all over it, sometimes nastily.  (I know; I've worked on Chrome.)  But when you release a free Android app, even if it crashes all the time, people are very friendly, even offering help and support!  The feeling I get is "I know you're trying your best.  I appreciate it."  It's wonderful.

Android AudioRecord

AudioRecord is an Android class that lets you record audio and fiddle with it in real time. MediaRecorder is what you want if you'd rather save the audio to a file and deal with it later.

You'll notice that AudioRecord's constructor takes 5 parameters: audioSource, sampleRateInHz, channelConfig, audioFormat, and bufferSizeInBytes. audioSource is reasonable enough; I used MediaRecorder.AudioSource.MIC. For bufferSizeInBytes, you can use the getMinBufferSize() function. (then you might want to multiply the result by 5 or 10 or something.) But the other 3, you kind of have to guess.

I dealt with this for a while, found something that worked on my Nexus One (2.2), launched an app, and then found out that it crashed the Droid (2.1-update1) on startup. So to save you all a similar experience, here's what I know:

44100 hz, AudioFormat.CHANNEL_IN_MONO, and AudioFormat.ENCODING_PCM_16BIT is the one and only configuration guaranteed to work on all phones. The Android Compatibility Test Suite (that phone makers have to run their phones through before they release them) guarantees this (see AudioRecordTest).

Sample rates of 44100, 22050, 16000, 11025, and 8000 hz (and probably others) work on the Nexus One and Droid. Annoyingly, only 8000 hz works on the emulator (2.1-update1), and by "works", I mean "doesn't crash". I haven't tested that it actually records anything useful.

CHANNEL_IN_STEREO works on the Nexus One, but not on the Droid.

This is all correct as of ... about a month ago. Hopefully nothing drastic has changed since then. Make sure you've put the right permission (RECORD_AUDIO) in your AndroidManifest.xml, and good luck recording audio!