Is it a good approach to solve this?
Well, it is most probably not a good way, but your only reasonable choice to solve this in the given situation. But expect this happen again when version V3, V4, V5, ... of lib A1 will be released - as long as you don't take any additional measures, you will always have the effort of merging the A2-changes into the code of A1. If A2 differs only very slightly from A1, and the changes are well documented, that may be fine. Proper use of a version control system or at least a diff-merge tool for generating a patch-set for A1->A2 can also be helpful (at least, when A1 does not change from version to version so much that your patch-set cannot be applied any more).
The better alternative would be to contact the author of A1 beforehand and ask him kindly if he can change A1 in a way that you won't need to the fork in the future any more. He might consider integrating some of the additional features from A2, or (if that is not reasonable) to change the interface of A1 in a way so it will allow the adding of extensions without the need for changing A1. The goal should be to build A2 as a separate library which just links A1, unmodified. Maybe he can provide a "hook" or "plugin" mechanism, or maybe just make some internal methods public, this depends completely on the design of A1 and your requirements for A2.
