This is a Notes-To-Self work in progress. Why share? Several reasons, among them, my desire to see Unity become a more popular platform for mobile app development in the near future. If any part of this post saves someone dev time or helps them pick Unity as the dev platform for their mobile project, that means more work opportunities for developers that took the time to learn Unity.
- For on-device debugging, add Android’s adb tool to your environment variable. For me, on OS X, it was fairly easy.
- Set up logcat w/ adb to get on-device debugging on Android. Xcode’s Console lets you do this pretty much by default when you “Run” on a device that’s attached to your machine via USB.
- Enable your Android phone for development & USB debugging.
- Figure out an approach for dealing with the numerous Android pixel densities & screen sizes. Daniel Brauer’s DisplayMetricsAndroid class looks pretty good. Haven’t tested enough yet. As a commenter states, it’s implemented like a “plugin” via the Plugins folder in your project’s Assets folder. Then there’s Screen.dpi, in, at least, Unity 3.5.
- If you’re using Prime31 plugins like Etcetera and Social Networking, you’ll need to get the Android versions. Their Google Analytics plugin works on both.
- If you’re using the open source UIToolkit for menus, screens, HUD, etc, look into how to get 1.5x graphics to work. Perhaps, 1.5x sprite sheet and tweak(s) to or subclasses of the UI or UIToolkit classes. Not sure yet.
- The ProgressDialog is Android’s version of the Activity indicator, UIActivityIndicatorView on iOS.
Potentially useful formulas & numbers
A review aspect ratio formula might come in useful. For example, if you have a screen that’s “1280 x 720”, you can assume width/height = 1280/720 = 1.78 = 16/9, aka it’s a 16:9 aspect ratio. This calculator can be useful at times.
- So, for HTC Legend’s 480×320, you can do 480/320 = 1.5 = 3/2 to get an aspect ratio of 3:2.
- For Motorola Droid’s 854 x 480 – 854/480 = 1.78 (1.779) = 16/9 (roughly) yields a 16:9 ratio.
- For Nexus One’s 800 x 480, do 800/480 = 1.6 (1.666) = 16/10 (roughly) to get 16:10 aspect ratio.
- Samsung Galaxy S3 is at 1280×720, with a 16:9 ratio.
- Most Galaxy S2 phones are at 800×480, 16:10 ratio. At least one is at 1280×720, 16:9 ratio.
- iPad 3 has the horizontal dimensions of 2048 × 1536. 2048/1536 = 1.33, which is roughly 3/2. 3:2 aspect ratio
So if I’m using sprite sheets w/ UIToolkit, does this mean I should create android versions of the sprite sheets at 1.5x, 1.78x and 1.6x versions of the basic size of the smallest iOS images (sheets)? Mmmmm… more research needed.
Try Using Density Independent Pixels via Unity’s Screen.dpi
Screen.dpi is one of the improvements in Unity 3.5 (or from what I hear, even 3.4). If you’re using UIToolkit, you can try using public methods like pixelsFromTopLeft( float x, float y) coupled with the Density-independent pixel technique recommended by the Android developer guide:
Density-independent pixel (dp)
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in a density-independent way.
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline density assumed by the system for a “medium” density screen. At runtime, the system transparently handles any scaling of the dp units, as necessary, based on the actual density of the screen in use. The conversion of dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5 physical pixels. You should always use dp units when defining your application’s UI, to ensure proper display of your UI on screens with different densities.
So to get the x, y values for the pixelsFromTopLeft( float x, float y) method, use the formula px = dp * (Screen.dpi / 160), assuming 160 dpi is your minimally supported screen dpi. This also means that dp = px / (Screen.dpi / 160).
Note, on some Android devices the system fails to generate a dpi and returns a ZERO. In those cases, the above formula breaks, as noted here.
Here’s a free DP to PS calculator.
SD / HD screen sizes for Android, UIToolkit Sprite Sheets & PSDs
In 2012, 800×480 seems like the most common Android resolution for phones. I’ve heard some rumors on forums w/ no links to sources. Any sources I find, I’ll post here:
For UIToolkit, 800×480 can be our SD resolution and the size we should create the first sprite sheet for. So the .PSD files should be created at 16:10 aspect ratio for 800×480, or the SD UIToolkit sprite sheet in Unity.
I personally don’t care about the low density older Android phones – since I’m making 3D games using Unity, those phone’s processors & memory probably won’t be able to handle my app anyway, so why waste time on creating yet another sprite sheet for it?
Depending on whether or not you care about all of Android’s aspect ratios, supporting slightly older Android tablets or only the latest ones, or just the latest high density phones, you can set your UIToolkit HD sprite sheet(s) to, for example 1280×720 for the latest 2012 Samsung phones like the Galaxy SIII. Using 1280×720 or slightly less like 1160×720 to catch devices like the Galaxy Nexus phone, seems to also work on a few Android tables (like Motorola’s).
Remember, and prep your Designers for this ahead of time, it won’t look pixel perfect on every device. Android device screen size fragmentation is probably worse to deal with than cross-browser CSS problems (yes, even with IE6,7.8 vs the standards browsers on Mac and PC). Gently, remind Designers that an Android layout is not a PSD, PDF, an InDesign file or a printed page.
Some common Android phones with the medium 800×480, or the very close 854×480, screen size:
- HTC Inspire 4G
- Motorola DroidX
- HTC Evo 4G
Sprite sheet problem
UIToolkit worked mostly well for iOS with 3 large, full-screen-sized background images even fitting inside the regular (SD) and 2x (HD) sprite sheet at 2048×2048 in TexurePacker Pro.
I just tried using a similar approach for Android and ran into a wall. The 2x sprite sheet is a problem – if for 2x, I’m sizing my graphics for HD Android phones like the Galaxy SIII at 1280×720… those 3 full-screen-sized background images don’t fit anymore inside 2048×2048. From what I’ve heard on the Unity forums Android has problems with images (sprite sheets) larger than 2048×2048. It’s not ideal, but I guess I can always proportionally scale those down for the sprite sheet and then use Screen.width and Screen.height to scale them. Given the client approved design, it’s nearly impossible, not to have them. The other approach would be to add a second sprite sheet, may be one for buttons & smaller UI stuff and one for unavoidable large background images. This will increase production time since extra sprite sheets will need to be created for SD and HD resolutions. & you’ll need to be careful which sprite sheet you’re targeting when from code.
Some Android-related posts on the main UIToolkit forum thread
Testing in Unity’s Game panel
- To fake the 1280×720 screen size of the Samsung Galaxy SIII and similar new phones, switch the Game panel’s aspect ratio to Android Wide (16:10) and then stretch the panel till it approximates those dimensions. You can test them in the Console via Screen.width & Screen.height or use something like Screen Ruler or a PSD that’s at that size to approximate. Note: 1280×720 is actually 16:9, the 16:10 Android devices at that size are 1280×800, so keep that in mind.
- I had trouble with “adb devices” not recognizing an HTC Inspire 4G and then a Motorola DroidX. I googled the crap out of it, read through every post on http://forum.xda-developers.com/ and still nothing. Then I borrowed a USB cable from a coworker who had an Android phone & boom! everything magically worked: adb devices listed both phones, Unity3D was able to publish directly to the device via “Build & Run”. Fun times.
PlayerPrefs.txt & Releasing Updates to iOS & Android Apps
Android: Looks like if you release an update to your app via Google Play, your PlayerPrefs.txt file will not be overwritten. I was able to confirm this from my own experience with a Google Play app.
Same deal for iOS, looks like an App Store update doesn’t overwrite PlayerPrefs.txt. I was able to confirm this from my own experience with a Unity3D-built app in Apple’s App Store.
Some Stuff About Google Play Sucks
- If you’ve uploaded a new version of your app (a new APK), realize that this version has a bug, and decide to revert to the previous version, you can’t. Google Play doesn’t allow it as of October, 2012. If you’re the developer, you can compile your older source code with a newer Version Code (versionCode) and upload it as a NEWER APK and overwrite the problematic version. What a waste of my time!