Is it an overkill to add external integrity check to the AES-GCM encoding? There is a java library for android which implements integrity checking to predefined encrypting mode(which can be found here). 


  Short class description from author page to avoid further questions about code.
  
  
  Algorithm &amp; Mode: AES 128, CBC, and PKCS5 padding. We use a 128 bit key size for its widespread support and because it’s not clear that
  256 is stronger. We would have picked GCM for its built-in integrity
  checking, but that’s only available since Android Jelly Bean, which
  leaves out about 1/4 of active Android devices
  IV Handling: We securely generate a random IV before each encryption.
  Key generation: Random or pasword-based. 
  Integrity: We’ve also added more-or-less transparent integrity checking in the form of a SHA 256 MAC with a constant-time equality
  check. This is in the form of a “combined key” where 128 bits of the
  key are used for encryption and 256 bits are used for integrity, then
  the keys are kept together.
  


As stated before, it's possible to use AES-GCM, which already have built-in integrity checking. 

So, the question is: Are there any (dis)advantages of adding external integrity check to AES-GCM (in theory, or practically)?

To sum up already mentioned comments:


  Disadvantages:
  
  
  loosing the speed advantage of AES-GCM;
  performance/space use and extra complexity(i don't think that complexity is the case, as library is fairly simple);
  human factor:
  
  
  "Crypto is tricky: it’s hard to tell that the gibberish that’s being printed is not good crypto, and it’s hard to tell that the code example you picked up from {put any source name here you like} has serious flaws."
  
  
  
  Advantages:
  
  
  HMAC-SHA256 has stronger authentication than GCM(in-depth explanation here), among other things not leaking the key in case of nonce reuse
  


Thank you for your answers.
Theoretically, there is no issue adding some kind of MAC on top of authenticated encryption's builtin. However, in practice there might be subtle flaws with composing the particular primitives you're using, or you may make an implementation flaw that renders them both vulnerable to a side-channel attack that didn't exist previously. Ultimately, it's best to stay away from getting creative with protocol design - just use the best-known implementation of the best-known primitive for the job.