0

By reading at some question/answers such as this one, I’ve understood that I cannot use request codes bigger than 16 bits because it should thrown a runtime exception due to its masking validation.

However, I’m running up to this question because I’ve only experience this issue in one device even though I’ve been using integers bigger than 16 bit without any issue (such as 2847827) and it works just fine delivering the right result with the same code.

Now, my question is: how is it working? Why it doesn’t throw an exception if it’s bigger? This is making it hard to understand why in some devices with the same API (28) and request code it works, and others don’t.

Miguel Ruivo
  • 16,035
  • 7
  • 57
  • 87
  • The exact code of all devices aren't the same, even for the same version of Android. Its entirely possible that one OEM put in a patch to fix it, or at least to remove the check. – Gabe Sechan Mar 23 '19 at 18:30
  • I’ve tried with two different emulators. Shouldn’t happen right? – Miguel Ruivo Mar 23 '19 at 19:07
  • Looking at AOSP, the only check in Activity.java is that its non-negative. However there are multiple code paths it could be going through. My guess is some of them validate and some of them don't. For safety's sake I would use a 16 bit request code. – Gabe Sechan Mar 23 '19 at 19:15
  • Nevertheless, why isn’t throwing an exception if I’m using the native sdk? Has anything changed related to it lately? Because accordingly to the docs it should. This question comes up relying in a package that I have which happens to result in a crash for an user but with the same environment, I can’t replicate the crash and it accepts 32 bits integers without an issue. More than fixing it (which switching to a 16 bit should do) I would like to understand what’s happening behind both scenes. – Miguel Ruivo Mar 23 '19 at 19:18

0 Answers0