What I'm concerned about is the inner workings of AES. Does it encrypt each block using the result of the previously encrypted one ?
No. AES is a block cipher. It ciphers a plaintext block using a key, and it generates a single ciphertext block. Note that in itself AES is not secure: it leaks information about the identity of the blocks; e.g. if you feed it the same plaintext block twice then it will generate the same ciphertext, which leaks information to any adversary which is able to eavesdrop.
In some modes such as the venerable CBC mode the encryption depends on the previous block. In that case the cipher is called plaintext aware; i.e. it depends on the previous plaintext and thus ciphertext block. This means that the cipher is also hard to parallelize for encryption as this dependency propagates all through the cipher mode.
Does it deals with blocks based on their length and the key's length (I'm pretty sure that is the case, from what I've read, it adds some padding if the data to be encrypted does not match exactly) ?
It only handles blocks of 128 bits / 16 bytes. The key length of 128, 192 or 256 bits does not directly influence the block size. It is somewhat useful to have a key size that is a multiple of the block size because otherwise it becomes tricky to encrypt / wrap keys with another key. This is one of the reasons to not use 192 bit AES. Some ciphers even allow for variable key sizes and multiple block ciphers. Actually AES is the Rijndael cipher, and Rijndael does allow additional block and key sizes.
The padding is required for the mode of operation of the block cipher. It only depends on the block size of the block cipher algorithm; the padding would remain exactly the same for any other block cipher that operates on 128 bit blocks. Most modes, including the popular AES-CTR and authenticated AES-GCM modes do not use padding at all. Basically it is only used for ECB, CBC and some related block cipher modes (PCBC). The reason why people think that padding is always necessary is the ubiquity of CBC mode - although even CBC can use ciphertext stealing to avoid it.
My foremost concern is with the power of the encryption. Does it make a difference if I encrypt something in chunks or all at once ?
In principle the power is mainly consumed within the block cipher. So the mode of operation doesn't really matter. If you use an authenticated cipher or HMAC then you generally need to pass the plaintext or ciphertext twice, which will of course increase the power consumption.
It depends on the API, but it might be that the latency increases if you have to perform multiple calls to an underlying AES implementation.
My second concern is with decrypting. Do I have to use the same size of chunks when I decrypt the data ?
No. The output of a block cipher mode of operation is well defined. How you chunk the data is entirely up to you. Obviously, for the block cipher mode of operation you have no choice: it is either 16 bytes or a multiple of 16 bytes if multi-block encryption (basically the insecure ECB mode) is supported. Most lower level API's will only buffer up to the block size internally.
ECB can be used to directly encrypt multiple consecutive counter values, in case the CTR mode is not directly available.
