Is there any weaknesses to encrypting fixed-length messages? Should a random amount of padding be added to the message to decrease the odds of some sort of attack?
An adversary who obtains AES-GCM ciphertexts but does not know the key cannot obtain any information about the plaintexts except their lengths. This is (in a highly simplified form) the definition of the claim that AES-GCM is secure. This is true for any secure authenticated cipher.
If your plaintexts are intrinsically all the same size, this is an ideal situation, because the ciphertexts leak no information at all about the content of the plaintext.
If your plaintexts can have different sizes and the size of the plaintext leaks some information that you want to keep secret, then padding plaintexts so that they all have the same length is a possible solution. Beware that the generation of the message, the padding process, the unpadding process and the processing of the unpadded messages are likely to take time that depends on the length of the plaintext, so it may still leak through timing. Appending padding to the message may not be the best solution: depending on how the message is structured, it may be easier to construct a secure system if you arrange each part of the message to have a fixed size, and concatenate those fixed-size parts. That way the assembly and parsing of messages is less likely to reveal confidential information through side channels.
Adding a random amount of padding is unlikely to help security. In particular, if the same message is likely to be transmitted many times, an adversary can average out the lengths, which will negate the uncertainty of the random padding. However, it can help in some scenarios where you want to hide which message was transmitted for privacy (for example, to make it harder to figure out which file a user download on a server). Still, the only fully reliable way is to have fixed-size messages (in the download privacy example, this would mean padding all files to the length of the largest one).
Yes, it may be because the size of the message is directly leaked. This is the kind of thing that professional cryptographers learn at the first day and then forget about. However, it depends on the type of message that is encrypted and the context if hiding the size makes any difference.
Usually the size of the message is indicated in bytes. GCM can work on any bit string, but generally implementations require a plaintext message be build out of bytes. Adding a random amount of padding or padding up to a certain size can help disguise the size of the message.
Any encryption leaks some length information about the plaintext message, even if padding is applied. If the ciphertext is a certain size then the plaintext message fed to the cipher needs to be smaller after all, and padding won't help against leaking that kind of information.
Beware that statistical data may still reveal information about the plaintext messages before encryption, especially regarding max and minimum sizes. Adding, say, 0..10 bytes of random padding will also not help that much if your message is e.g. multiple gigabytes in size. If you can pad to the maximum message size that is best, but of course it will could create a lot of ciphertext.
Note that I would then deliberately put padding inside of your protocol, to be applied before GCM is used. You can use any padding value. Don't use one of the existing padding modes used for block ciphers and combine that with GCM. For instance, you could specify
"AES/GCM/PKCS5Padding" in Java, but that really doesn't make sense at all; it may work differently in specific implementations, if it is not outright rejected.
GCM itself works perfectly fine with fixed size messages, other than the more generic issue about leaking information about the plaintext (which every mode does to a certain amount).