Currently I'm using Google In-app Billing v.2 with the help of net.robotmedia.billing project. Now I'd like to move my app to v.3.
In net.robotmedia.billing I have to provide unique salt to obfuscate transactions, but all of similar libraries for v.3 do not provide such option.
My question is: I need to have correct salt to deobfuscate already bought by user on v.2 items, right? how to make transition so that users don't have to buy items twice?
The In-App Billing API v2 supports both managed and unmanaged in-app products.
Robotmedia's Billing library seems to be agnostic to the in-app products types, thus handling both. It maintains a local BillingDB on the device. For unmanaged in-app products, this is the only place where purchased products information is stored. In the case of managed in-app products, it offers another place where the purchase information can be queried apart from Google Play servers. This could prove useful in v2 since it did not offer local caching like v3 does and querying such information resulted in very expensive operations time-wise.
So there are two paths from here, depending which type of in-app products you are using.
The information about the purchases is already being managed by Google Play. So you should be able to migrate to v3 preserving your users' purchase data.
In the In-App Billing API v3 there are no unmanaged in-app products. The way you handle the use cases for which the unmanaged in-app products were designed is via the new consumption API added in v3.
The idea behind unmanaged in-app products is that you maintain the purchases database instead of Google. You can still do the same with v3. The way you do this is by consuming a product immediately after the purchase succeeded.
The library you are using is no longer being maintained. So in order to achieve the interoperability that you want, you may start by getting familiar with the code in the library you are using. You might want to reuse the TransactionManager class and others responsable of storing purchases' data. This way you can store/retrieve the data in the same format you were using and old users won't have to purchase in-app products again. Then every time your users purchase a product, you consume it immediately and update your transaction database.
The migration in this case is not trivial. It's worth mentioning that this would have probably been much easier if the database was being stored in a server instead of the client.
Last but not least, Bruno Oliveira gave a talk at Google I/O 2013 which explains most of the API changes. You will find it useful.