The long and short of this is that you need to figure out what the sound looks like. Is it a simple sound that's easy to differentiate by just choosing the highest peak on an FFT? If your doorbell has a peak at 10khz and your dryer has a peak at 5khz, it should be pretty easy to do if 4.9khz < max(fft(audiodata)) < 5.1khz then dryer; if 9.9khz < max(fft(audiodata)) < 10.1khz then doorbell.
Most likely it's not going to be that easy. Also there is the possibility that the dryer manufacturer and the doorbell manufacturer used the same component for the buzzer and it's going to be mathematically the same sound pattern, but differ on harmonics blocked by the room.
You could need to use the whole fft of the sound, recorded at many different locations in the house and then use nearest neighbor for the convolution of the "new" sound with the old sound and then compared to a database of previous sounds. You would need a large database of example sounds to compare with. Probably at least 100 examples of each sound that would go off and then you would need to set a threshold of "closeness" so that you don't always detect new sounds as one of the old sounds.
If this didn't work, then you may have to go with a hefty fingerprint like chromaprint or echoprint. Those would give you so much info about not just the frequencies, but also the rhythm of the sounds. Like maybe your dryer and your oven have the same frequency pattern because the manufacturers used the same buzzer, but they pulse them differently. That's one advantage to these full fingerprint libraries. And somebody else did the science, so you don't need to write a dissertation in DSP to be sure that you have some rigour to your approach.
Chromaprint would be a good library to go with in that case. It's part of the acoustid project and has a great how it works
blog post for the acoustically curious. The problem would be that it's
mainly developed for sounds as complex as music, so I don't know how it
would work with a "buzz" noise. It's small enough and fast enough that
it can happen quickly enough on a phone. That's how programs like shazam
work. They make the fingerprint on the phone from a 10 second
recording and push it to a server that processes it. Shazam has riddled
the landscape with software patents, so chromaprint isn't a replacement
for that, it's just close enough that it may work.
Other things to look at:
http://code.google.com/p/musicg/ - A java audio DSP library. Does fingerprinting and stuff.
Echoprint has been ported to Android: https://github.com/gvsumasl/EchoprintForAndroid
If you send me some example sounds, I can look at them in python or something and let you know what I think about different metrics that you could use to compare the sounds. Specifically a recording in a loss-less codec like flac or without compression like wav would be important because MP3 and such destroy parts of the audio waveform. 'Course I could just record my kitchen timer and let you know what it looks like...
Your offer to do the programming is great, because I'm no app dev, but I do have some education and experience with signal processing.