I just realized that I had messed up one of run configuration parameters. Which is why I was getting 4.1 instead of AND for Capabilities.version. I reverted that and I am getting the correct value of AND.
However, there is still no way to tell the OS version. I see that spark.utils.PlatformMobileHelper does actually read an Android system file to determine the version. Obviously, this fails during simulation. I am going to apply your [Mixin] approach to fix this during simulation. Sorry for the noise. Thanks, Om On Tue, Aug 12, 2014 at 11:42 AM, OmPrakash Muppirala <[email protected]> wrote: > On Tue, Aug 12, 2014 at 11:34 AM, Alex Harui <[email protected]> wrote: > >> >> >> On 8/12/14 11:05 AM, "OmPrakash Muppirala" <[email protected]> wrote: >> >> >Nice idea. So, when we decide to remove this in the future (when Adobe >> >hopefully fixes this bug) will the users get a compilation error if they >> >are using this include? >> If we don't remove the class, then it will still compile and do the >> override. Are you trying to find a way to make it smart enough to realize >> the bug has been fixed? Not sure that's worth it. They can simply remove >> the compile option. >> > > No, that's fine. I was just trying to figure out the repercussions of > taking this approach. > > >> It seems like that would be useful for testing different versions of >> Android in the simulator regardless of this bug. >> > > There is another problem though. I have a mobile app with two run/debug > configurations, one for iOS and one for Android. AIR simulator works fine > for iOS, i.e. it does correctly report "IOS xxx" for version. > > If I add this as a compiler option, it will apply to all run > configurations, right? Is there a way to include a compiler option for a > particular run configuration in FB? > > Thanks, > Om > > >> >> -Alex >> >> >
