How can I access my mini-pc (RaspberryPi / MK802 / Mele A1000 / VIA APC) via ethernet/wifi without having Monitor?

You'd need to set it up initially, but you could run a SSH server on it for remote CLI access. You can then access graphical apps via x forwarding, or through some other remote access method.

You can do this with any proper linux distro - Not sure about android (though the debian chroot method may work), but everything the raspberry pi supports will allow you to do this.

Interestingly, I can see these instructions for raspberry pi/Debian being done offline, with the root SD card mounted on another device - with a few small modifications. I've not tested this of course.

With mods, and ideally on another system running debian

ssh-keygen -t rsa

Should generate a public RSA key. You will want to move this to the equivilent of /root/.ssh/id_rsa on your raspi root file system

Assuming locations relative to your Raspberry Pi file system

mv /boot/boot_enable_ssh.rc /boot/boot.rc

Should boot up the ssh server by default.

Load the card in and boot up. Finding the ip address would be tricky, but you could set up a static ip address the same way - editing suitable settings to /etc/networks/interfaces

This should hopefully as long as permissions are correct (fix them if not!) let you do what you want on a raspi. Likewise you may be able to edit the root file system before the boot on a similar SD card booting device with a x86 based linux system to boot as you'd like.

How can I access my mini-pc via ethernet/wifi without having Monitor?

Depends on how you define "access".

If you do not have a proven kernel & root filesystem (RFS) for booting, then you will absolutely need to have somekind of console attached to this miniPC. Otherwise you will not be able to view all of the startup messages that are generated. (Once a kernel is tested, the kernel is setup to boot in quiet mode for release. Although the Windows kernel is more verbose than normal when using "safe mode".)

PCs have traditionally used a video device (e.g. a monochrome/CGA/EGA/xVGA monitor) as the (text and/or GUI) console. Headless PCs and embedded systems typically use a (low-cost) serial (UART/USART) port as the (text-only) console. Linux can use a console via a USB-to-serial adapter, but some of the startup messages will be lost due to the late initialization of the USB stack.

Remote logins like telnet or ssh can only occur after the kernel has successfully booted. If you have no console and the kernel fails to boot, then you will have scant information to describe or debug the boot failure.

In other words, imagine that you obtain a new laptop with SSD whose screen does not turn on until Win7 or Linux asks for your username/password. The BIOS POST beep codes are disabled. There is no "disk" activity LED. When you first turn on the laptop, nothing appears on the screen at all. There is nothing to indicate boot progress. How are you going to describe the boot failure? How do you begin to solve this? How much time do you have to try out the myriad possible fixes? Or are you just going to use it as a doorstop?

BTW if your LAN is (relatively) secure, then all you need to access the (running) miniPC is telnet (rather than ssh). Startup the telnetd daemon (or configure inetd) on the miniPC, and use a telnet client on your host PC.

Booting from LAN does not solve or address this console issue at all. A LANboot simply means that the kernel image is obtained from a server, rather than local storage. This does not make sense when there are gigabytes of local (and removeable) storage capacity. Admittedly testing kernels with LANbooting is convenient. U-Boot is capable of using the LAN and tftp, as well as local storage for loading the kernel image; the "U" in its name stands for "universal". Note that the LAN can also be used for accessing the root filesystem via NFS.

Update

If your single-board computer has a UART or USART, then a serial-port console is the way to go. However the complication may be that there is no standard DB-9 serial-port connector or, more common, only logic-level signals are exposed rather than RS-232 signals. Some additional hardware would then be needed to use this interface as the console.

For the Raspberry Pi and the Mele A100/1000/2000, there is a UART but only logic-level signals are available. An external board or converter has to be connected, which will provide either a DB-9 or a USB connection to a host PC (which would need a terminal emulator program, such as Tera Term or Putty). A tutorial for setting up the serial port on a Raspberry Pi is here. U-Boot will probably require a recomplie to use the serial-port console. Support for the serial console will also have be be compiled into the kernel; the serial console for Linux is specified in the "kernel command line" originating from U-Boot. Linux allows specification of multiple consoles, and output messages will be displayed on all of them.

Addendum

If a serial-port console is not available and/or net access is a must then there is the intermediate solution of booting the Linux kernel with a netconsole. But that usually requires a secure LAN and a known (e.g. static) IP address assigned to the host acting as the "console".
But for full visibility of the boot process, you would want to use a serial console, since almost all Linux-capable SBCs have a UART (with either logic or EIA/RS-232 levels) for a serial-port console.