Mains power switches work exactly the same way as the relay, in terms of abruptly applying, or removing, power to the load. This is true whether the load is a lightbulb, or a television.
Thus, there is conceptually no difference between a relay and a wall switch in this context.
In practice, there is, however one caveat: Good quality light switches have internal spring action which ensures positive, firm contact making or breaking - a mechanical hysteresis of the manual force applied versus the switching on and off, so to speak.
A basic relay, or one that is energized by too low a current on the actuation coil, will suffer contact bounce, it will make and break the circuit repeatedly for a very brief period, or if the relay coil is just barely insufficiently powered, the relay contacts might chatter.
Standard relays designed for appliance switching on mains lines, such as those made by Omron and other appliance electrical manufacturers, address this issue by implementing a contact make/break hysteresis and firm spring action, thus achieving the positive force and stable contact creation that good wall switches do.
TL;DR: Don't use a cheap sugar cube relay or one not designed for household appliance switching. A good relay will cause just as much, or as little, harm to an attached appliance, as a wall switch does.
There are several issues with the avrdude command you posted.
You are specifying a baud rate and a serial port with -P COM3 -b 19200, which is nonsensical as the USBasp is a pure usb peripheral and does not require a serial port nor use a usb to serial converter internally. These settings have no effect.
You have selected the Atmel avrisp as your programmer with -c avrisp, while you claim that your programmer is the USBasp. This may or may not work, but avrdude supports USBasp natively, so you should instruct avrdude that the programmer is USBasp with -c usbasp.
You are rewriting the efuse bits without specifying a value with -U efuse:w::m. The correct way to set the fuse bits in immediate mode (not reading the fuse bit values from a file) would be -U FUSE:w:VALUE:m, for example -U efuse:w:0xFF:m. The manual of avrdude does not state that leaving the fuse value unspecified sets the fuse to its default value, so it probably just sets the fuse to 0x00.
Your programmer is not the Atmel JTAG ICE, so the bit clock setting -B700 is nonsensical, and has no effect.
The good news is that you trashed efuse instead of hfuse, which could have bricked the AVR by setting RSTDISBL and thus preventing reprogramming.
To resurrect your chip, I would suggest to reprogram all fuses. My guess is that you have inadvertently messed up the fuse values at some point, causing the chip to run at 1MHz or less. This causes the programmer to communicate too fast relative to the clock frequency of the ATtiny, resulting in the glitched transaction you see. The USBasp has a jumper for lowering the data rate, which you should set. For the fuses themselves, there is a handy online tool for easily determining and understanding the values. To program the fuses, run
avrdude -p t85 -c usbasp -P usb -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xff:m
(8MHz clock frequency using internal oscillator, isp enabled, no special settings)
For flashing the chip with a new .hex, run
avrdude -p t85 -c usbasb -P usb -U flash:w:FILENAME:i
Best Answer
Take a look at V-USB. I've used it with ATtiny85. It's essentially a firmware-only USB implementation for AVRs that don't have "built-in" USB.
The V-USB site also has a decent list of example projects you could use as a starting point. Not sure about how/if you can interface with android or not.
One thing to be aware of is their licensing model. You have to pick either GPL or commercial license. If you don't want to bother with adhering to GPL their commercial option has a "hobby" license for $9.90.