Unity: Android Native Crash – [Solved] MP4 Audio Encoding Problem

I’ve been in Beta Testing for a new game I’m about to release on the Google Play Store (the game is called Endless Elevator). I kept having Native Crashes on specific Android platforms in all my builds in the Pre-Launch Reports. Native Crashes can be terrible to work through if you get unlucky so I was a bit worried and figured I’d just have to leave it like it was and release with errors! But being a bit stubborn I threw a few days into sorting through it and am very glad I did. Working through the problem highlighted some things I didn’t know about Android Video support and was an interesting exercise in troubleshooting. So here is the method I followed and the resolution to the problem.

In each case it was always the armeabi-v7a package that was causing the issues. (I split my build into two APK’s for arm64 and armeabi to make it a smaller installation size – I haven’t gone the android bundle path yet).

These are some of my base Beta builds and in most cases there were 4 errors relating to specific platforms.

The Pre-Launch tests are run on a variety of Android platforms but usually they will include these four below in some form or other and my build kept crashing with a Native Error on each of them.

The usual suspects

When I looked at each of them in turn and played the video of the interactive session the fail point always seemed to be about the time when I had a full screen projected video playing or about to play. The video is used as an introduction and tutorial to the game so it was pretty important for me to get it working.

The drill down screen of the crash report where you can see the video of the session and get access to the logs.

I downloaded all the Logcat’s from the console above and looked for any errors or crash reports.

In each case I found this line (which was a bit of a dead giveaway):

——— beginning of crash

A half dozen lines above the likely culprit was writ large:

07-23 04:00:47.862: W/MediaAnalyticsItem(9345): Unable to record: (codec:0:-1:-11:0:3:android.media.mediacodec.mime=audio/ac3:android.media.mediacodec.mode=audio:android.media.mediacodec.encoder=0:) [forcenew=0]
07-23 04:00:47.890: W/Unity(9345): AndroidVideoMedia: Could not create decoder for mime type audio/ac3.
07-23 04:00:47.890: W/Unity(9345): (Filename: Line: 2177)
07-23 04:00:47.906: I/Robo(9288): No foreign elements detected, falling back to original ScreenState.
07-23 04:00:47.910: I/Robo-HyperMultiGraph(9288): New Screen: Optional.of(ScreenNode {Id=5, PackageName=com.ZuluOneZero.EndlessElevator, ActivityName=Optional.of(com.unity3d.player.UnityPlayerActivity)})
07-23 04:00:47.913: E/Unity(9345): Could not allocate memory: System out of memory!
07-23 04:00:47.913: E/Unity(9345): Trying to allocate: 4294705156B with 16 alignment. MemoryLabel: Audio
07-23 04:00:47.913: E/Unity(9345): Allocation happened at: Line:70 in
07-23 04:00:47.913: E/Unity(9345): Memory overview

A bit of googling about led me to believe that as per the error message above the audio codec used in the video was a problem. The AC3 codec is an Audio format that’s used in my MP4 Video. I’d never given it much thought but this format is not supported across all the Android platforms (one of the problems of Android development is that there is so many different platforms out there).

The Video Editing Software that I normally use is called OpenShotVideo. It’s fantastically good for the price (free) and is easy to use and powerful enough for my meagre needs. Turns out the default audio codec used is AC3 (there is probably a way to modify this with OpenShotVideo but I wasn’t in the mood to troubleshoot someone else’s software). I really hadn’t given the audio codec part of the MP4 a second thought.

This is the Export Panel from OpenShotVideo where I confirmed that the Codec was indeed ac3.

While I was doing all this work and after I worked out that the audio codec in the Video was the problem I had a look at the video settings in Unity. I found that there was already a built in transcoder that I’d never noticed right there in the Unity Video Asset Import screen.

Transcode !

That’s pretty cool! Unity has already solved all my problems before I even knew I had them. So I hit the Transcode tick box and waited for twenty minutes while it went to work transcoding. That wait time should have been a bit of a warning. I did the build and uploaded the new apks to the Google Developer Console but while doing that I found that my build size had jumped almost 17 MB!

This was my size before the transcoding:

And afterwards:

A quick look at the Editor.Log confirmed that the transcoding process had made my lovely low quality 7 MB Movie over 20 MB:

Used Assets and files from the Resources folder, sorted by uncompressed size:
22.1 mb 6.8% Assets/Art/IntroMovePlusFoyerClippedSlowLow.mp4

To fix this I downloaded the HandBrake Open Source Video Transcoder and transcoded my original video asset using the AAC Codec for Audio.

The HandBrake Tool

After importing this into my project and rebuilding again I was left with a similar package size and no Native Crashes. Hooray. I’m going to release this Beta Build to Production soon so getting over this little hurdle feels like a huge V for Victory. Huzzah.

Endless Elevator – Early Access Beta

Endless Elevator went into Beta Testing on May 27, 2020, 8:10 PM.

Finally we made it to public testing! After a few months of keeping myself quiet and a seeming eternity of bug fixes I think I got a minimum viable product fit for your eyes, ears, and phone-ready fingers.

Please head over to our Beta Test Page and try it out. I’d love to get some feedback from other enthusiasts and developers.

Get it Here!

Chat With Us!

We have an anonymous Chat Channel right there on the page that you can trash talk into so go for broke! (You are also allowed to be supportive and kind as well if that is your nature).

🙂

The Beta Page has more information about the game as well links to articles written during development that explore the mechanics of the game.

Indie Game Release Click Through and Conversion Rates

Hi Harmony here…

Last Sunday we released our game The Dog Run into the Google Play Store.

This post is a breakdown of the first week release click through rates from this web site and the conversion rates that resulted in an actual download of a game.

Let me say from the outset that without some form of “advertising” or publication campaign a new game on the Google Play Store is never going to be successful.  We found this out the first time around with our game NumBlocks:

NumBlocks is a fun little numbers game that’s a bit like Tetris with numbers that add together. It was our first game with Unity and only a bit more than an experiment in finishing a game that looked good enough to publish.  We weren’t that proud of it and were really just proving our development and release cycle for future games.  It was never publicised and never got downloaded…by anyone.  So if you are not promoting your game… no-one is looking … and no-one will play it.

This time around with The Dog Run we really do want people to play the game and enjoy it. The game is a simple endless runner with a quirky hand drawn style that held many interesting development challenges. More information about the game is available here:

The Dog Run

But what I want to investigate and be transparent about is the way we used this web site and the landing page as a way to interest people into playing the game.

We released the game into the Production Google Play Store on Sunday October 21st.

On the next day at about 8 am New York time we posted on social media channels (we found from research, and validated with our own posts over several months on this site, that this is one of the times of the week that got the most traffic).

We only used Reddit, Facebook and Google+ to promote the release of our game.  We Tweeted and posted to LinkedIn and Tumblr but no-one really follows our feeds on those platforms so I won’t count them.

This is the list of Groups that we hit on social:

Facebook

IGC : Indie Game Creators
Unity 3D Game Developers
Unity 3D Game Developers (different group)
UNITY3D Game Developers
GameDev Show and Test
Game Developers
Indie Game Players & Developers!
INDIE GAMES
Indie Game Promo
Indie Game Development Feedback (IGDF)
Indie Game Chat
Indie Game Promotions

Google+

Unity3d Indie game developers
Unity3D Mobile Developers
Unity 3D Enthusiasts
Unity 3D Developers
Android Apps and Games-Android Mobile Zone
Android Game Developer
Free Mobile Games
Game Developers
Game Developers (different group)
Mobile Game & App Developers
Unity
Unity3d Indie game developers
Unity 3D Developers
Unity3D Mobile Developers

Reddit

/r/Games/
/r/gamedev/
/r/androidapps/
/r/AndroidGaming/
/r/gamernews/
/r/IndieGaming/
/r/androiddev/
/r/gamedesign/
/r/devblogs/
/r/SideProject/
/r/playmygame/
/r/Unity2D/
/r/IndieDev/
/r/indiegames/

So what can we say about this set of groups?  Well they are all Gamer’s Groups. These are “our” people. This is where we go when we need feedback or inspiration or help.  We may not be active in all of them and by no means is this an exhaustive list but after working our way through this lot on a Monday morning there is no energy or time left to look for more groups to join and contribute to.  So this is not a “general public” group nor are they representative of what I think our target audience might be.  But these are gaming enthusiasts and I think more likely to try new games and provide that sort of validating critical and informed feedback that is important for making the game better.  (I love you all!)

So now for the stats….

After seven days since posting these are the figures that hit our website (which normally gets about 20 – 30 visitors a day).  The graph below shows the two weeks previous to release and is indicative of the sort of traffic we get. The blue bar just under the 500 mark is what happens when we do a blog post.  The big orange one is the day after our “social media campaign” (if you could call it that).

Total number of visitors over that week was: 1199

But as you can see a day or two after we posted the traffic dropped straight back to normal. Although the traffic we did get that week was all mostly to look at the landing page of the game.

It is interesting to see where that traffic came from  –  and it’s overwhelmingly Reddit that drives the traffic to our site.  This image below is the stats from the big orange day.

So as you can see even though we posted to heaps of groups in Google+ and Facebook not many users of those platforms were reached.

Out of this massive spike in traffic the number of people who actually clicked on the link to go to the Google Play Store was: 76

This is about 6.5% (rounded up) of our total traffic during that period.  Every day during that week the click through rate was about the same average rate.

Now for the fun part.  Out of those 76 players the number who actually downloaded the game and played it was:  21!

Well that’s a huge improvement over none.

I was very excited by this number.  I’ll type it again in long form…..  Twenty One !

So what I want to drive home with this post is the amount of traffic that you got to drive into your web site to get the sort of volumes that will get your game downloaded.

Let’s break it down into simple numbers……  Out of 1200 people only 75 looked at the game and out of that number only 21 downloaded it.  That’s 1.75% of the traffic to my landing page downloaded the game. That’s the truth of it and remember that these are “our peeps” not the general public so I couldn’t even say that this is indicative of the way the real world works.  But it sure is interesting and in a few months after I’ve spent some time marketing this game to real people (not just the gaming community) I’ll do another post and see if the stats still hold.

Harmony out!

P.S. If you want a friendly copy of all those social media links email me at zuluonezero.z10@gmail.com and I’ll forward them back. (Maybe on a later post – if there is enough interest – I’ll  put them online). Zulu.

Unity Debugging with ADB for Android

Hi Zulu here… (First of all … sorry for the cat)

Let me say straight off that your first port of call for any Unity debugging should be the Unity Console.

Though sometimes you need more low level operating system logging for Android. This is where ADB (in lower case) comes in.

On Windows this is a command line tool to view the logs from a connected Android device.

The command line is not the only way to use the tool sometimes it’s better to use the Android Studio interface (a bit more graphical).

You will need to have your Android device connected to your workstation and USB debugging turned on  (Google that if you need to). You could also use an Android emulator on your desktop.

I use Leapdroid or KoPlayer.  (Leapdroid have now joined Google and no longer support the emulator but it’s still available to download on the internet).  I guess you could also use the emulator that comes with Android Studio.

When your game is installed and running on your device go to the directory in your workstation (PC) where the Android SDK Tools are.

On mine they are here:

C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools

In the tools directory open the monitor.exe (this tool was depreciated in Android Studio 3.0 and replaced with profiler.exe mine is still on the lower revision).

This documentation on the Android site is a good start investigating the profiler:

https://developer.android.com/studio/profile/android-profiler

You can also get into LogCat directly from Android Studio (if you have it open):

Go to  View | Tool Windows | Android Monitor

At the bottom of Android Monitor in it’s own tab is the LogCat console window. This contains all of the information about what’s happening in the Android operating system.

As you can see the LogCat console contains a lot. It logs everything.

To filter it type “tag:Unity” in the textbox at the top to see messages that relate to Unity.

Using adb logcat from the command line

Open a command prompt on your development workstation and find the location of your Android SDK platform-tools folder.

Mine was here:

/Users/YourUserName/Library/Android/sdk/platform-tools

If you get this error when you run adb.exe using the command prompt:
‘adb’ is not recognized as an internal or external command operable program or batch file

You can add ‘adb’ to the $PATH environment variable (and restart the command prompt).

setx PATH "%PATH%;C:\Users\AppData\Local\Android\sdk\platform-tools"

 

To run logcat through the adb shell, the general usage is:

[adb] logcat [<option>] … [<filter-spec>] ..

This is the official Android Developer Logcat Command-Line Tool documentation:

https://developer.android.com/studio/command-line/logcat

but you can get –help on the command line.

It can be handy to know the device id of your Android phone/tablet whatever. This command will help:


C:\Users\<user_name>>C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe devices
List of devices attached
ce10171a5c19853003 device

 

You can specify that the log spew into a file instead of into your console (the console is pretty much useless as there is too much to scroll through).


C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe -d logcat > adb_logcat_out.txt
-d use USB device (error if multiple devices connected)

logcat show device log (logcat --help for more)
-s SERIAL use device with given serial (overrides $ANDROID_SERIAL)

 

The default Log Location on my machine was:
C:\Users\<user_name>\AppData\Local\Temp\adb.log

A few seconds of output got me a 6.5 MB file so a bit of filtering is advisable

If you run into trouble with the adb server just kill it and restart.


C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe kill-server

C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe logcat -s ce10171a5c19853003 DEBUG

C:\Users\<user_name>>C:\Users\<user_name>\AppData\Local\Android\sdk\platform-tools\adb.exe logcat -s ce10171a5c19853003 DEBUG
* daemon not running; starting now at tcp:5037
* daemon started successfully
--------- beginning of main
--------- beginning of system

 

If you want further help check out these pages from the Unity Manual and Tutorials:

https://docs.unity3d.com/Manual/TroubleShootingAndroid.html

https://docs.unity3d.com/Manual/LogFiles.html

https://unity3d.com/learn/tutorials/topics/mobile-touch/building-your-unity-game-android-device-testing

As a final word I’ll also direct you to this package called Device Console on the Unity Asset Store. I’ve not used it but it looks really good and for fifteen dollars might save you a lot of hassle.

https://assetstore.unity.com/packages/tools/utilities/device-console-44935