search

mb12 / marketbilling

Automatically exported from code.google.com/p/marketbilling
0 stars 0 forks source link

IAB doesn't work on apps that use android:SharedUserId #90

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
STEPS TO REPRODUCE:
1.Set android:sharedUserId="com.****"  in Manifest.xml
2.Set up billing service with "IabHelper.startSetup"
3.Get set up response with
IInAppBillingService.isBillingSupported(3, packageName, ITEM_TYPE_INAPP);

EXPECTED OUTPUT:
Setup successful.

ACTUAL OUTPUT:
12-17 05:09:04.714: E/AS(27058): Problem setting up In-app Billing: IabResult: 
Error checking for billing v3 support. (response: 5:Developer Error)

AFFECTED ORDER IDS (IF RELEVANT):

OS VERSION:
2.3.5

MARKET/MYAPPS VERSION:
3.10.10

DEVICE:
MOTOROLA DROID X2

OUTPUT FROM ADB BUGREPORT ATTACHED:
(Note: The output from "adb bugreport" is required for all bug reports.)
Too many output

NOTES:
Setup successful without use android:sharedUserId, but I need it.

Logcat:
12-17 05:09:04.704: W/Finsky(20189): [27] 
InAppBillingService.validatePackageName: Package name com.****.****** does not 
match the Uid
12-17 05:09:04.714: E/AS(27058): Problem setting up In-app Billing: IabResult: 
Error checking for billing v3 support. (response: 5:Developer Error)

Original issue reported on code.google.com by wangdong...@gmail.com on 17 Dec 2012 at 1:47

GoogleCodeExporter commented 8 years ago 
We're looking into it.

Original comment by b...@google.com on 5 Feb 2013 at 7:16

GoogleCodeExporter commented 8 years ago 
Issue 91 has been merged into this issue.

Original comment by b...@google.com on 5 Feb 2013 at 7:23

GoogleCodeExporter commented 8 years ago 
Confirmed: in-app billing does not work with android:sharedUserId. Thanks for 
reporting. We're working on it.

Original comment by b...@google.com on 5 Feb 2013 at 7:50

GoogleCodeExporter commented 8 years ago 
I have encountered the same issue here. 80% of the users report they can't make 
a purchase while the other 20% can. Using In-app billing V3 with SharedUserId 
in my game. Hope there will be a solution soon. Thanks a lot!

Original comment by jaredsmi...@gmail.com on 17 Feb 2013 at 4:33

GoogleCodeExporter commented 8 years ago 
Hi,
any prevision when this issue will be fixed and a new release of IAP will be 
made?

Original comment by william....@gmail.com on 2 Apr 2013 at 8:36

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hey Google,
  this issue is also impacting my applications. There is no update for this bug since Feb 5, 2013. Is there any forecast to provide to the SW community to resolve this problem? Any elegant workaround to suggest? Thank you very much!

Original comment by thiago...@gmail.com on 12 Apr 2013 at 6:58

GoogleCodeExporter commented 8 years ago 
Hi! Just a quick note to say that yes, we are aware of the issue and haven't 
forgotten :-)... but we don't have an ETA at the moment. I'm keeping an eye on 
it and I'll update this issue as more info becomes available.

Original comment by b...@google.com on 15 Apr 2013 at 4:10

GoogleCodeExporter commented 8 years ago 
Is this issue corrected in the recently release of google play application?

Original comment by william....@gmail.com on 16 Apr 2013 at 7:02

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
This is terrible news.

Is there any update? 

This issue is almost a year old.

HELP!

Original comment by cory.tr...@gmail.com on 14 Aug 2013 at 2:23

GoogleCodeExporter commented 8 years ago 
No resolution for this issue after such long time strikes me as terrible news. 
It works for some but does not work for many others. It makes in-app billing a 
no-go and I will need to re-design my app to move away from in-app billing.

Original comment by dirktros...@gmail.com on 20 Aug 2013 at 4:21

GoogleCodeExporter commented 8 years ago 
This only happens with shared user ID's, and it can be fixed easily. In 
InAppBillingService, you're probably calling 
PackageManager.getPackagesForUid(Binder.getCallingUid()) and checking against a 
single package name instead of looping over the resulting String[].

Even if you roll this fix out now it will be too late for us to use, but please 
get this bug fixed ASAP so future projects can depend on having it fixed. It's 
a 1 line change with zero risk!

Original comment by Boo...@gmail.com on 9 Sep 2013 at 6:14

GoogleCodeExporter commented 8 years ago 
Is this bug fixed in the new release of Android?

Original comment by cory.tr...@gmail.com on 2 Nov 2013 at 12:38

GoogleCodeExporter commented 8 years ago 
Oh boy. This weird bug is has become a nightmare for us. Is there a workaround?!

Original comment by kristof...@arbitrio.se on 19 Nov 2013 at 10:42

GoogleCodeExporter commented 8 years ago 
No, the workaround is to use v2 and for all future applications, find other 
(horrible) ways to accomplish what sharedUserId used to give us.

Original comment by cory.tr...@gmail.com on 19 Nov 2013 at 10:44

GoogleCodeExporter commented 8 years ago 
Our app relies heavily on sharedUserId. Without it, our free/pro versions 
cannot coexist. Does v2 provide the IabHelper class? I upgraded from v1... 
Fantastic!

So the bug lies in some system component inside Android?

Original comment by kristof...@arbitrio.se on 19 Nov 2013 at 10:58

GoogleCodeExporter commented 8 years ago 
This issue is embarrassing easy to fix, PackageManager.getPackagesForUid(int) 
returns a String[]. This function in com.google.vending.apk checks only 
result[0] and ignores everything else, so it randomly throws 
RESULT_DEVELOPER_ERROR when more than 1 package exists for a Uid. Normally, I'd 
keep this to myself but this has taken Google 9 months to investigate with no 
fix in sight. Come on! Just fix line 5 already.

  private InAppBillingUtils.ResponseCode validatePackageName(String paramString)
  {
    int i = Binder.getCallingUid();
    String[] arrayOfString = this.mPackageManager.getPackagesForUid(i);
    if ((arrayOfString.length > 0) && (TextUtils.equals(paramString, arrayOfString[0])))
      return InAppBillingUtils.ResponseCode.RESULT_OK;
    FinskyLog.w("Package name %s does not match the Uid", new Object[] { paramString });
    return InAppBillingUtils.ResponseCode.RESULT_DEVELOPER_ERROR;
  }

Original comment by jamezsmi...@gmail.com on 19 Nov 2013 at 11:13

GoogleCodeExporter commented 8 years ago 
James, your fix requires an update of the com.google.vending.apk, right? Even 
if it was fixed the user could still have the old version installed.

What about this approach:
Consider IabHelper.java(222). What if we instead of calling getPackageName()  
tried all package names that have the same sharedUserId? Would that work or 
would there be a conflict of some kind?

Original comment by kristof...@arbitrio.se on 20 Nov 2013 at 8:41

GoogleCodeExporter commented 8 years ago 
Calling getPackageName() and trying all package names would allow you to 
purchase, but it might record the purchase under a package that's not your app. 
This would likely break other service calls, such as getPurchases, which also 
take a package name.

It also looks as though there's no way to alter the order getPackageName() 
returns packages, so it is impossible for apps with sharedUserId to use billing 
V3.

This is all the more pressing with the expiration of the checkout API today - 
We cannot poll the purchase status of unmanaged V2 products with the new Google 
Play Purchase Status API - but we can't buy and consume managed products, 
because we can't upgrade to V3!

Original comment by t...@noom.com on 21 Nov 2013 at 3:52

GoogleCodeExporter commented 8 years ago 
Is there a way other than this bug tracker to get their attention? I'm sending 
in an email via the developer console, can everyone do the same? That might 
work.

Original comment by Boo...@gmail.com on 21 Nov 2013 at 4:08

GoogleCodeExporter commented 8 years ago 
Using sharedUserId works if only one app with the id is installed. Is it 
possible to somehow unregister the apps from the IAB service when activity is 
paused/destroyed? That way the conflict could be avoided.

Original comment by kristof...@arbitrio.se on 21 Nov 2013 at 4:55

GoogleCodeExporter commented 8 years ago 
Saw this in developer console:

Migrate your app to In-app Billing v3 for better performance, improved 
stability, and new purchasing features to better meet your needs. 
Implementation is straightforward, and in some cases you can reduce the amount 
of code needed for purchases. The v3 API is also much easier to use than legacy 
versions - purchases are fully synchronous with results reported to your app 
immediately. Note that support for earlier versions of the In-app Billing API 
will be removed over time, so consider migrating as soon as possible.

------------------

I sincerely hope that you're going to fix Issue #90 (opened a year and a half 
ago) before you sunset applications that cannot migrate to v3 due to bugs in 
Google code.

Original comment by cory.tr...@gmail.com on 20 Jun 2014 at 7:21

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Yeah, I'll wait another two years... But until then, please, at least tell us 
how to get out of this sharedUserId hell! If we change/remove it, we lose 
access to existing user files (correct me if I'm wrong).

Original comment by kristof...@arbitrio.se on 3 Aug 2014 at 8:57

GoogleCodeExporter commented 8 years ago 
You are correct, any change to sharedUserId is deadly -- you lose access to 
existing user's saved games and files.

Removing it will have disastrous results for your ratings on Google Play, and 
in most cases, force the user to uninstall/reinstall the package. How likely 
are they to leave you a one star? 100% :(

Original comment by cory.tr...@gmail.com on 3 Aug 2014 at 9:06

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I remember in the early days when I decided to use sharedUserId for my two 
apps. Many sources on the net stated "Set it from start in both apps, otherwise 
you will encounter problems.". How ironic...

Today, my advice to the community is: NEVER EVER use sharedUserId until issue 
90 is fixed.

Original comment by hacker.d...@gmail.com on 5 Aug 2014 at 12:10

GoogleCodeExporter commented 8 years ago 
The following issues describe what will happen if the sharedUserId changes:

https://code.google.com/p/android/issues/detail?id=1227
https://code.google.com/p/android/issues/detail?id=55052
https://code.google.com/p/android/issues/detail?id=14074

Original comment by joerg.af...@gmail.com on 5 Aug 2014 at 10:34

GoogleCodeExporter commented 8 years ago 
This issue seems to be resolved on the vending apk (version 4.9.13, code 
80290013). I've no idea since when, but as we received an email that V2 is 
going to stop working on 1/1/2015, we'll be migrating to V3 asap.

First test (running queries against both apps with same UID) indicates it 
works; calls return an inventory.

Original comment by Boo...@gmail.com on 13 Sep 2014 at 12:04

GoogleCodeExporter commented 8 years ago 
Today in the developer console I'm suggested to upgrade to v3 as soon as 
possibile (within November) because Google will remove support to v2 in 
January. No purchases will be possibile with v2. Is this bug fixed? I'm using 
sharedUserId and what happened in January since v2 cannot be used anymore and 
v3 cannot be used with sharedUserId?

Original comment by pietropa...@gmail.com on 13 Sep 2014 at 10:31

GoogleCodeExporter commented 8 years ago 
@Google -- is this fixed yet? If we are REQUIRED to update to v3, we need this 
issue to be fix.

Can you confirm that it is fixed?

Original comment by cory.tr...@gmail.com on 22 Sep 2014 at 5:52