For Android, you can get the IMEI number ( a type of device ID ) using this ANE: http://blog.snowflax.com/native-imei-action-script-extension-for-andro id/ Check out this thread for more info: http://forums.adobe.com/message/4747846#4747846 ... View more

If this is an Android project, you can use this ANE: http://blog.snowflax.com/native-imei-action-script-extension-for-android/ I have verified that it does work and provides the IMEI.  For cases where there is no IMEI ( bc the device is not a mobile phone, or it uses IMSI instead ), you can just bypass the device id check with your database, and enable full functionality. Although this is not full-proof, it will nevertheless screen a lot of devices.  With this, you can keep track of the number of app installs / resets, and add a 'banned' flag if you want to in your DB -- if you see unusal activity ( like:  unsually high number of re-installs ). ----->  UPDATE: I just found this ANE which  includes a class called 'SystemProperties', to find the IMEI/IMSI/serial/phone number on Android, and the MAC address on iOS: https://github.com/mateuszmackowiak/NativeAlert I have verified that the iOS part works, but haven't tried the Android side, yet.  Note: for iOS, it will also give you a UUID ( even though the object tag claims it is the UDID -- it's not ), which is worthless as a persistent means of identifying the device. since it gets reset on each app re-install.  So, for iOS, you have to use the MAC address, unless you are willing to store/restore the UUID into EncryptedLocalStore, as suggested by a user in: http://stackoverflow.com/questions/6794493/get-unique-identifier-mac-address-udid-etc-in-adobe-air-for-ios ... View more

Haha...Right there with you. I think malloc stands for 'memory allocate', and it's used in the C language to request a block of memory of a particular size, for you to use as you wish.  AIR does the memory management for you, which simplifies things a lot, but I guess that can also be a bad thing when you don't know what is going on. As far as the Apple App store, unfortunately, once you've submitted an app for iPhone+iPad and they accept it, you can't go back and make it iPhone only, once you realize that it's not super stable on the iPad1.  The only thing you can do at that point, short of pulling it from publication, and re-submitting 2 versions, is to optimize your app to make it stable! A few suggestions, which have worked for me in the past: 1) Don't use GPU mode, unless you really have to.  CPU can be quite fast (esp. with stage.quality = StageQuality.LOW <-- only use this once you've cached--meaning: 'rendered'--all your assets with StageQuality.MEDIUM), and it's much more stable memory-wise. 2) If duplicates of the same UI widget is used is several containers, try switching to a single--static--widget instead, and either move it to the right container when you need to (provided you don't see all containers at the same time) OR move it to the stage--depending on the situation. 3) Try to have your bitmaps point to the same bitmapData, wherever appropriate.  Ex: if two buttons use the same bitmapData, but one is red and the other one yellow, just put a ColorTransform on those bitmaps, and have them point to the same (grey) bitmapData. 4) Generate graphic assets on the fly, as needed, and get rid of them when you no longer see them.  There is a little framerate hit in rendering assets at runtime, but at least you are NOT occupying memory with them all the time, for stuff you only occasionaly see. 5) Use cacheAsBitmap, wherever appropriate.  CAB is good in some sense bc AIR will reclaim unused CAB bitmaps that are not part of the display list at the moment.  So it does its own little video memory management, enhancing stability. I have had good results making apps stable, after quite a bit of graphical optimization. ... View more

I don't know of a way to monitor GPU memory, nor video memory far that matter, on iOS apps (there may be a way on Android in debug mode, but I am not sure). What you can do, though, is monitor system memory, via: memory = System.totalMemory / 1048576; // in megabytes. _debugTF.text = memory.toFixed(2).toString(); If you run this statement via an enter frame handler, you'll be able to see when the gc runs, as the mem will go back down. Sorry, I know this isn't much help... ... View more

These sizing issues can be very frustrating, especially as behavior is not the same across OSes and devices.  This is kind of critical stuff: you would think Adobe would have nailed this some time ago. A lot of it is adapted from http://sierakowski.eu/list-of-tips/82-starting-with-air-for-android-and-ios-building-one-app-for-both-platforms.html, with some enhancements on my part to address the issue raised by sigman.pl, in this thread. Please, anyone, feel free to correct me if you feel I am going about this the wrong way. Here is what I do: private static var _resizeEventFiredOnceAlready:Boolean; private static const _screenBounds:Rectangle = Screen.mainScreen.visibleBounds; private var _stageWidth:Number; // Don't get confused: for our use, we mean the SHORTEST visible screen length for the app, irrespective of device orientation.  Think of the app being in portrait mode (unlike in Sierakowski's blog) private var _stageHeight:Number; // LONGEST visible screen length for the app.  public function MyDocClass():void {     addEventListener(Event.ADDED_TO_STAGE, onAddedToStage); } private function onAddedToStage(evt:Event):void {       removeEventListener(Event.ADDED_TO_STAGE, onAddedToStage); // remove this handler      // Below: we only do this once, when the app starts, since another one of this may be instanced later, possibly.      if (!_resizeEventFiredOnceAlready)      {         // Below: we don't want to add (and build) our graphic assets to (based on)         // a stretched stage.         // Rather, we want to build them at the right size, which means we will need         // to know the device screen size in a moment...          stage.align = StageAlign.TOP_LEFT;          // Above: if there is a top status bar, top_left is nevertheless right below it, so we're good...          stage.scaleMode = StageScaleMode.NO_SCALE;          // Above: needs to be set to no_scale, otherwise the resive event, below, won't fire when the app window changes its          // its width or height.  That's a how the RESIZE event is supposed to work.          // The default, otherwise, is "SHOW_ALL", which stretches the stage to fit within the window, but does not theorically          // fire the resize event, though it does on iOS ( but not on Android, which is the correct behavior ) *          // * I wished Adobe would fix these inconsistencies...          stage.addEventListener(Event.RESIZE, onResize);      }      else           initThis(); } private function onResize(e:Event):void {     stage.removeEventListener(Event.RESIZE, onResize); // remove this handler     _resizeEventFiredOnceAlready = true;     // Determine screen size so that we can properly construct our UI...     //     // The problem with fullScreenWidth/Height is that it gives the entire     // screen dimension, including the area occupied by optional status bars     // (in cases where user set <fullScreen>false</fullScreen>, in the app manifest)     // as well as the non-optional (so I read in this thread from sigman.pl) virtual Android buttons bar,     // on some devices (ex: Xoom w/ Android 3.0).     //     // These status and buttons bars have the potential of causing important UI widgets     // to be partially hidden, so we need to size our app so that it fits nicely within     // the visible area of the screen: hence the use of Screen.mainScreen.visibleBounds.     //     // However, when debugging the app on a computer (CTRL+Enter in Flash CS5),     // Screen.visibleBounds returns the area of the desktop, not the area within the flash window,     // so that's annoying (note: Screen.screens doesn't work as of this writing *).  Also, there is no guarantee that in the     // future,mobile OSes might not be able to start apps in a 'minimized' mode (like a computer),     // so we will use Math.min to address both issues, below.     // * Another important unfinished loose end from Adobe     //     // Note: stage.stageWidth/Height would have returned the stage dimensions as was set in CS5,     // regardless of what scaleMode is set at ( scaleMode only affects what the stage looks like,     // stretched or not, on the device, but does not affect the values returned by stageWidth/Height ).     _stageWidth = Math.min( stage.fullScreenWidth, _screenBounds.width );     _stageHeight = Math.min( stage.fullScreenHeight, _screenBounds.height );    // Above: fullScreenWidth and _screenBounds.width always refer to the same side of the screen,    // on any OS and device AFIK, so we're comparing apples to apples.     // Apparently, according to Sierakowski's blog (see link above), stage.fullScreenWidth isn't consistent in always giving the     // same (shortest screen length), when the device is started in landscape mode between iOS and Android *.     // Anyway, let's make sure we always get the shortest screen length:     // * Another Adobe loose end, though I believe this has been fixed in 3.1 (maybe even earlier).      var temp:Number = _stageWidth;     _stageWidth = Math.min( _stageWidth, _stageHeight );     _stageHeight = Math.max( temp, _stageHeight );     // Above: now _stageWidth is always the shortest screen length / and _stageHeight the longest one, irrespective     // of if we started the app in landscape mode or not.  We could now swap the 2 at this point, based on device orientation,     // but at least we know what is what.     // Rest of your code     initThis(); } Note: My personal preference is to always have my apps run in fullscreenMode = true / aspectRatio = portrait / autoOrients = false, only.  If there is a need to redraw/resize stuff based on a change in orientation, then a handler should be able to 'fake' it, rather than actually modifying the stage. The stage is the stage, let's not f*** with it!  It's hard enough as it is... ... View more

I just figured out what was not working with my Nook version: srceen sizing issue (due to the extra pixels required by status bar, I think).  Anyhow, use of AIR 3.1 captive runtime on Nook works and was not at cause! ... View more

Yes, you're right, but that strategy ends being a costly proposition on Android: buy a KF, then a Nook, this device, that device... hahaha.  Besides, not having to worry too much about device specificity is the whole point of AIR, isn't it? But you're right, I'll probably make an exception for the KF. ... View more

Ok, I have gotten a response from the Amazon Appstore:  it appears that all my AIR 3.1 apps with 'captive runtime' do work on the Kindle Fire! My word of caution still stands, though, namely:  the Amazon Appstore checks for Kindle Fire support AFTER it accepts app updates (as of this writing).  So a developer can unknowingly break KF support, and still get app updates accepted into the store! I still have to figure out why a similar AIR 3.1 captive runtime app got turned from the Nook app store... ... View more

A word of caution: the Amazon Appstore checks for Kindle Fire support AFTER it accepts app updates.  So a developer can unknowingly break KF support, and still get app updates accepted into the store! Here is an e-mail I just sent to Amazon's KF team: FYI, there is a significant loophole in your submission pipeline: 1) All my apps use Adobe AIR. 2) For the longest time, they were all compiled with AIR 2.7 so there was no problem.  I got a bunch of downloads, including from Kindle Fire users. 3) A week ago, I updated most of my apps to AIR 3.1, and broke Kindle Fire support, without my realizing it, because I didn't know that the KF only supports AIR 2.7.  Unfortunately, all the updates with broken KF support were accepted into the store!!! 4) Now I am getting users complaining that their apps no longer work on Kindle Fire. What should have happened: NONE of the updates should have been accepted after it was realized by your review team that they broke Kindle Fire support, while previous versions worked fine on it and KF users downloaded them.  Reviewing KF support separately, after the initial review/acceptance, is not a good process! In any case, I have re-submitted all my apps with the release note 'Restored Kindle Fire support'.  What I did was use 'captive runtime' for compiling all my AIR 3.1 apps, which normally means that the app will not require an external AIR runtime to function.  Hopefully, this will work this time.  If not, I am going to have to re-compile everything using AIR 2.7, which is a major drag since some of the features I depended on are part of AIR 3.1. ... View more

Colin Holgate wrote: What they wrote just talked about what happens if an app with AIR 3.0 was embedded is tried, whereas we're talking about a captive runtime AIR 3.1. But you're right, I haven't submitted an app, there could possibly be a problem. I'm not sure though how the app would be seen to be different to a Java one. Embedding and captive-runtime AIR doen't mean the same thing ? To be clear: In my case, I did use AIR 3.1 captive-runtime for the NOOK submission which got turned down. I recently submitted a captive-runtime AIR 3.1 app to Amazon, and am waiting to see if it goes through their Kindle Fire review. The reply I got from Amazon tech support, above, was following being turned down for Kindle Fire, following my submitting a NON-captive AIR 3.1 app. ... View more

Yes, I believe it's the same issue with the NOOK: I recently had my AIR 3.1 captive runtime app turned down by them.  Unfortunately, I didn't receive any explanation e-mail or message from them (I don't think their appstore is as perfected as Amazon's).  I can only assume this was the reason. Maybe Adobe could include a flag in adt so that the app doesn't go for the 'native' version of AIR by default, if the developer provided his own as a captive runtime, like: -forceCaptive ... View more

Colin Holgate wrote: The only option at the moment seems to be to make the app have captive runtime. AIR 3.1 captive runtime apps work fine on the Kindle Fire. Hi Colin, Though I haven't tested this first-hand (I don't own a Kindle Fire at the moment), it appears that using captive runtime with 3.1 doesn't work.  I just got this e-mail from Amazon: My original query to Amazon: Hi, Is there any technical reason why the kindle fire doesn't support AIR 3.1 at this time?  If not, when do you anticipate adding support for AIR 3.1? Reply from Amazon: Hello [my Name], Thank you for writing in. The reason is that there is the native version of Adobe Air 2.7 installed on the KF. Even if a developer compiles an adobe application and packages the Adobe Air 3.0 with their application. The application will first pick up the native 2.7 as apposed to the 3.0 version that was bundled with the application. Unfortunately there is no eta on an update for Air at this time. Best regards, [Tech name] Amazon Appstore Account Team ... View more

Unbelievable! Hey Adobe, wake-up!!!  We need a formal procedure to overlay 3.0 over CS5.5, plz. ... View more

It depends on your situtation. In one of my apps, I had weird rendering artifacts when using StageQuality.HIGH/BEST in CPU mode which went away when I used MEDIUM instead, so I don't really trust it. Also, if your app has a lot of text, LOW can make a big difference in terms of perf, esp. on iPad1. ... View more

* crickets sound * ( haha... I read a book about design patterns once: some of them sounded like a good idea--like decorators--, however, I personally prefer to get things done, quickly ). ... View more

Good to know.  Esp, since it's cheaper to get a 16-32gig iPod Touch 3 on Craigslist than a 3GS, for debug purposes. Thank's, Colin. ... View more

Hi Tim, I haven't tested on iPhone 3GS (nor iPod Touch 3.8 -- I assume it's the Touch version of the 3GS?).  BTW, Air 2.6/7 only work on 3GS upward.  I read in another thread that some people were having what appeared to be GPU memory related issues on iPad1 (as did I), while everything worked fine on the 3GS, probably due to the fact that the display res is lower (320x480). ... View more

Very true...  rendering TFs to bitmaps is faster than rendering TFs directly, even with cacheAsBitmap enabled on the text fields.  However, cacheAsBitmap helps prevent memory overruns in some cases, as there are hooks in Flash to garbage collect cached bitmaps early, when they are no longer needed (I believe: even setting visible to false on a TF with CAB will cause the bitmap to be garbage collected -- someone might correct me on that). This more "active" garbage collection can make the difference sometimes, in GPU mode especially, if you are scolling lots of text fields.  In one of my apps, scrolling many bitmaps (rendered TFs) would eventually cause a crash (memory overrun), while scrolling the TFs with CAB enabled was fine.  I also had code to set visible to false on objects whose bounds were no longer within the visible stage area. Note:  in the code above, unless "snapshot" or a container thereof is scaled, there is no need to use cacheAsBitmap on a Bitmap (you'd be using twice as much memory for nothing). ... View more

hummm...  I know this shouldn't make a difference, but it might be worth trying:  create a bitmap that is the same size as the stage, and manually render your sprites to it via BitmapData.draw().  Actually, this should make things a bit slower, logically: but hey, Flash has its own logic sometimes.. Tip to improve the fps: you can always render some or all your assets to a bitmapData that is half the size of the screen, but whose Bitmap container is inversely scaled by a factor of 2 (stage.quality shoud be set to StageQuality.MEDIUM to take advange of bilinear sampling in CPU mode -- In GPU mode, you'll get trilinear for free, I think).  Also, make sure your Bitmaps have smoothing set to true.  This will radicaly improve the fps, but make your assets a bit blurry. ... View more

I agree, it's pretty stable. The only thing you have to watch out for is memory overruns, which can cause an app to quit unexpectedly. This can happen in GPU as well as CPU mode, but is more likely to happen in GPU mode. One issue, I believe, is that the GPU memory can fill up faster than the garbage collector can get to it.  So the app can run out of memory, even if there is a significant garbage collection debt, which if it had run, would have prevented the crash. One tip is to always dispose your bitmapDatas manually (via BitmapData.dispose() ) when you are done with them, rather than wait for the Bitmaps to be garbage collected.  Manually calling System.gc() is another option, but it can cause a hichkup in your fps.  Note: actually, you need to call System.gc() twice in a row: first pass marks orphaned objects, second pass removes them from memory. Scrolling big chunks of text/bitmaps is one of the most demanding things you can do, and is one use-case in which you can run into memory overrun issues pretty quickly, from my exp. Note: for iOS, the iPad1 is the most likely device to have such problems due to the small GPU memory (256mb) compared to large display resolution (1024x768).  If your app runs well on an iPad1, you won't have any issues on the other devices.  Also, try StageQuality.LOW, it can make a big difference as far as performance. ... View more

Addendum - Tips on increasing scrolling smoothness on iPad1: Using Air 2.7/CPU mode: In the init function, when the program starts, set stage.quality = StageQuality.MEDIUM.  Note: I have seen rendering issues (video memory corruption), when using HIGH or BEST, on iPhone4 in CPU mode, with the resolution in CS5.5 set to "High" (retina display).  Medium works fine. Render all your textures and static vector assets (except TextFields) to bitmaps manually, baking in all the filters you need, such that the bitmapDatas generated are 2-4 times the size they will appear on the screen, BUT their containers (Bitmaps) are inversely smaller (scaleX/Y are set to 1/2-1/4) For TextFields, set cacheAsBitmap = true and antiAliasType = AntiAliasType.ADVANCED At the end of initialization, set stage.quality = StageQuality.LOW What we did: Setting StageQuality.LOW increases the scrolling speed tremendously, but bitmaps are no longer bilinearly sampled.  To prevent downsampling artifacts in nearest-neighboor mode, we have to render our bitmaps at 2x their final screen resolution. Edges will still appear aliased, but they will be continuous looking (no "pits").  For textfields, setting antiAliasType to ADVANCED took care of the aliasing, even if the stage quality eneded up being LOW (actually the aliasing quality of text gets pulled down slightly, but it's still quite good). Using this method, I was able to improve the smoothness of scrolling of big blocks of text + vector shapes.  As a bonus, it will also improve scrolling speed on retina displays, if you set CS5.5 rendering quality to "high". Choosing the right upscaling factor: 2x or 4x ? The amount of upscaling you need to do (2x or 4x) depends on your  fla's starting resolution.  If you start with a 320x480 file in CS5.5,  and select "iPhone + iPad", you need to detect at runtime if this is an iPad, or an iPhone.  I use the following code: private const iPAD:Boolean = Boolean(CONFIG::IOS) ? ( (Capabilities.screenDPI % 132) == 0) : false; // modulus op to account for forthcoming iPad3 private const UPSCALE_FAC:Number = Boolean(CONFIG::IOS) ? ( iPAD ? 4 : 2 ) : 1; Regarding upscaling: In CPU mode on iOS (NOT on Android), if you opt to use stage.quality = StageQuality.MEDIUM (which is the default, I think), you normally get bilinear sampling on bitmaps and aliased vectors (vector edges are ugly).  Baking your vectors to upscaled bitmapDatas, gives you the benefit of bilinear sampling, thus anti-aliasing your 'vectors' on iOS. In CPU mode on Android with StageQuality.MEDIUM, it seems however that the opposite is true:  vectors are anti-alised, but bitmaps are not bi-linearly sampled. ... View more

I have had a lot of problems trying to get my apps working on iPad1 in GPU mode, as well. http://forums.adobe.com/thread/865144?tstart=0 I think that you are right in pointing out that the GPU memory is probably too small for such a high-res screen on the iPad1, since it is also used for the compositing the scene (in addition to storing all the elements that make up the scene).  The iPad2 by comparison has twice the amount of GPU memory and a faster GPU as well. Another problem is that I think that the GPU memory can fill up faster than the garbage collector can clear it.  When the GPU memory is full: the app will simply exit  (crash), even when there is a substancial garbage collection debt,  which if it had cleared, would have kept GPU memory below capacity  (avoiding the crash).  I think Adobe should do more to prevent this case. Air 2.7/CPU mode works fine for me on iPad1, but not Air 2.7/GPU mode.  If GPU mode is required, I have found that Air 2.6/GPU is more reliable than 2.7's on the iPad1, but I still run into GPU memory overun issues. ... View more