Beta Testing

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 – Last Week of Beta Testing

Hi Harmony here,

I’d like to thank the wonderful Beta Testers who have signed up for our Open Beta of Endless Elevator over the last month. I was really surprised how many people responded to our call and very grateful to all those who provided feedback.

The Open Beta is still running for another week so there is still time to try the pre-release game: https://play.google.com/apps/testing/com.ZuluOneZero.EndlessElevator

Then head over to our Beta Landing Page if you want to give us some feedback.

http://www.zuluonezero.net/endless-elevator-beta/

Your feedback helps us make a better game – thank you!

One feature of our Beta Testing was opening multiple channels to provide users to get back to us. Not only did we use the Google Play Beta Feedback and Stars system but we also took feedback on email and through social media. One new thing we did was to incorporate a chat channel on our Beta Landing Page where users could provide anonymous feedback directly on to our web site. I feel that the anonymity of this format was a really important source of quality comments for us.

Our Chat Page

Happy Playing – Harmony Out.

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!

Endless Elevator Beta

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.

Using ADB Logcat to Debug Unity Application Start Up Times

Our game The Dog Run has been in open Beta testing for some time and we are wrapping up new builds after the feedback we received during the process.

There is still time if you want to check out the Beta edition of the game on the Play Store: https://play.google.com/apps/testing/com.ZuluOneZero.TheDogRun

We used the built in Unity Profiler to work on performance improvements on the running game.
https://docs.unity3d.com/Manual/Profiler.html

But when it came to the application start up we found that we had a problem. It was taking over 20 seconds for the game to open up after a user pressed the icon.
Obviously this was way too long as much of that time was spent sitting on a black screen.

Trouble was with the Debug builds of our APK’s running in the profiler it would only pick up on game play issues and we couldn’t identify what was causing the slowness on start up. So we switched to using ADB the Android Studio Debugging Bridge to see what was actually going on under the hood of Android system while our game was loading.

If you want more info on the ADB tool have a look at my previous post here.

Unity Debugging with ADB for Android

We had a handfull of APK’s that we wanted to test against on out local workstation and used APK to copy them over to our attached development device using ADB commands.
Like this:

C:\Users\<User>>adb install C:\Users\<User>\Downloads\TheDogRun_v13_debug.apk
Success

Then we ran the adb command with the logcat argument and passed that output into a file to read afterwards.
Now pumping logcat into a file generates lots of data including the buffer that was recorded before the command was run so you will get lots of info from earlier that you either need to filter out or grep through.

This is one way to filter out in adb command line but it’s not as useful as grepping through the file:
>adb.exe -d logcat -e isApplicationExternalStorageWhitelisted

It’s a pretty big log generated in just a few seconds of logging:

I preferred to have the full log in the file and use notepads and command line greps and epreps to get the info I wanted to hone in on.
On Windows I have a great Unix like tool called MobaXTerm which is really useful for this sort of work.
https://mobaxterm.mobatek.net/
It’s a Windows ssh client but includes a Cygwin type access to your local Windows file systems.

So when we were searching through the logs (and it takes a while to get used what you are looking at. I’d recommend getting on google for anything that looks interesting).

Here is an example of the log:

 

It changed a little bit with each run but this is the main info that I was using for to make my judgements about start up speed on.

 

### This is the initial call for the application
09-28 10:29:08.684 4938 4938 D StorageManagerService: getExternalStorageMountMode : final mountMode=1, uid : 10495, packageName : com.ZuluOneZero.TheDogRun

### This is the process being allocated
09-28 10:29:08.752 4938 4938 I ActivityManager: Start proc 8679:com.ZuluOneZero.TheDogRun/u0a495 for activity com.ZuluOneZero.TheDogRun/com.unity3d.player.UnityPlayerActivity

### The Window for the game is open had has focus
09-28 10:29:09.336 8679 8679 I Unity : windowFocusChanged: true
09-28 10:29:09.337 8679 8679 V InputMethodManager: Starting input: tba=android.view.inputmethod.EditorInfo@23ee73 nm : com.ZuluOneZero.TheDogRun ic=null
09-28 10:29:09.346 4938 6402 V InputMethodManagerService: windowGainedFocus : reason=WINDOW_FOCUS_GAIN client=android.os.BinderProxy@9752c36 inputContext=null missingMethods= attribute=android.view.inputmethod.EditorInfo@ea1162f nm = com.ZuluOneZero.TheDogRun controlFlags=#105 softInputMode=#20 windowFlags=#80e90500

### The Game has the Window on
09-28 10:29:09.420 4938 5124 D SamsungPhoneWindowManager: Turning screen on : com.ZuluOneZero.TheDogRun uid = 10495

### Splash Screen is coming up
09-28 10:29:09.424 4938 5124 D InputEventReceiver: channel ‘d7f15c8 Splash Screen com.ZuluOneZero.TheDogRun (client)’ ~ Disposing input event receiver.

### Splash Screen removed
09-28 10:29:09.431 3192 3192 I Layer : id=6192 onRemoved Splash Screen com.ZuluOneZero.TheDogRun#0

### This is a Debug Package but the Unity Debugger or Profiler was not attached so there is a 4-5 seconds delay while it times out waiting for the connection
48832 [Id] AndroidPlayer(samsung_SM-G930F@192.168.1.139) [Debug] 0 [PackageName] AndroidPlayer” to [225.0.0.222:54997]…
09-28 10:29:09.544 8679 8696 D Unity : Waiting for connection from host on [0.0.0.0:55070]…

09-28 10:29:14.571 8679 8696 D Unity : Timed out. Continuing without host connection.

### Scripting Engine starts up
09-28 10:29:14.682 8679 8696 D Unity : InitializeScriptEngine OK (0xe7543ee0)
09-28 10:29:14.682 8679 8696 D Unity : PlayerConnection already initialized – listening to [0.0.0.0:55070]

## Creating Open GL
09-28 10:29:14.761 8679 8696 D Unity : OPENGL LOG: Creating OpenGL ES 3.2 graphics device ; Context level <OpenGL ES 3.1 AEP> ; Context handle -1013109888

### Unity Reports it’s Unload time
09-28 10:29:22.067 8679 8696 D Unity : UnloadTime: 2.403000 ms

### Ads Start up
09-28 10:29:22.309 8679 8696 D UnityAds: com.unity3d.ads.cache.CacheDirectory.getCacheDirectory() (line:42) :: Unity Ads is using external cache directory: /storage/emulated/0/Android/data/com.ZuluOneZero.TheDogRun/cache/UnityAdsCache

### About this time the Debugging on the Application side kicks in and you start to get these sorts of messages in the log:
09-28 10:29:23.533 4938 9976 I ActivityManager: DSS on for com.ZuluOneZero.TheDogRun and scale is 1.0
09-28 10:29:23.731 8679 8696 I Unity : Building GPG services, implicitly attempts silent auth
09-28 10:29:23.731 8679 8696 I Unity : #0 0xc6578460 (libunity.so) GetStacktrace(int) 0x44
09-28 10:29:23.731 8679 8696 I Unity : #1 0xc5f5e978 (libunity.so) DebugStringToFile(DebugStringToFileData const&) 0x230
09-28 10:29:23.731 8679 8696 I Unity : #2 0xc546bf9c (libunity.so) DebugLogHandler::Internal_Log(LogType, core::basic_string<char, core::StringStorageDefault<char> >, Object*) 0xa8
09-28 10:29:23.731 8679 8696 I Unity : #3 0xc546be8c (libunity.so) DebugLogHandler_CUSTOM_Internal_Log(LogType, MonoString*, MonoObject*) 0xb4
09-28 10:29:23.731 8679 8696 I Unity :
09-28 10:29:23.731 8679 8696 I Unity : (Filename: ./Runtime/Export/Debug.bindings.h Line: 43)

09-28 10:29:24.925 8679 8850 I UnityAds: com.unity3d.ads.api.Sdk.logInfo() (line:70) :: Requesting configuration from https://publisher-config.unityads.unity3d.com/

Total start up time around 16 Seconds – we got lucky with this one.

But you know it’s system dependent so we did it another ten times for each package to make sure that the readings were comparable to our out loud counting of seconds while watching the device.

To make a long story short we started getting an idea of what happens when the app starts up.
In the end the thing that most improved our startup time was the build that had changed settings to our audio files in the Unity import settings.


Basically all audio files were converted from the Unity default to the Overide for Android setting. The background music was streamed and shorter sound effects were compressed in memory.

So hopefully if you take this advice do that up front and you won’t have to spend a fun rainy Sunday debugging the start up time problem.

Interesting as it was it would have been more fun doing promo art for the upcoming release!

Endless Elevator Mechanics

Howdy. Xander here…

This is a quick demo of the basic play mechanics from our new game in development Endless Elevator.  We got the basic movement working a while ago (see our Smooth Moves post) and now that The Dog Run is in BetaTesting we can spend some more time working on this game.

(If you want to help with Beta Testing and be an early adopter of The Dog Run you can sign up here: https://play.google.com/apps/testing/com.ZuluOneZero.TheDogRun)

This clip below for Endless Elevator shows:

The Good Guy Cop Character movement (oh yeah he goes left and right)

Firing his awesomely powerful dumb dumb gun

Using (the eponymous) Elevator (see if you can spot the camera tracking bug!)

Traversing (the namesake) Escalators

Finally entering a doorway with a Power Cube (I’m not sure what it will look like in the final game yet). When he goes into a doorway with the special block the game flips and he goes into a Super Spy Store (not shown) where new fun weapons and power-ups are available!  Cool.

The Dog Run – Game Play Demo

Hi Harmony here…

Today I did some game play testing of the new game we are beta testing right now.

If you want to do some beta testing you can opt in here:   https://play.google.com/apps/testing/com.ZuluOneZero.TheDogRun

Feedback can be posted on the website in the comments or directly by email at
zuluonezero.z10@gmail.com

 

How To Get Beta Testers

Yay! We Are In Beta!

When ZuluOneZero published NumBlocks on the Google Play Store we went through the requisite development phases.

The game has been released now – have a play:
NumBlocks published on the Google Play Store for Android.

Click to Play:

Also on the Amazon Play Store for Android and Kindle.

Click to Play:

This was our first app that we thought looked good enough to give away to real users.
I was very proud of the artwork and how the game played on screen.
It’s a simple no-frills game but it was a perfect test platform to scope out what’s required to get a game published.
Which incidentally is a little daunting but in reality the whole process of publishing a game on the Google Play Store was pretty easy.
The Google Play Console was easy to use and there were plenty of official and community references to help us through it.

Uh Oh … Problem …

We went through several development iterations and found a revision that worked on most Android platforms.
We were running Unity 5 and targetting all mobiles above Android API 15 4.03 called “Ice Cream Sandwich”.
Not being a big shop our test devices were old personal phones that were around this API version. It was running well and looked great an a VM but once we started using our physical test devices we found a few issues dealing with different screen resolutions and one phone didn’t have enough resources to run the random number generator so that the same numbers kept spewing out.

Then we upgraded to Unity 2017.1.0f3 and lost support for those older API’s. Oops no more supported hardware to test on! We really needed to get some Beta Testers who could trial the game on a variety of different platforms that we couldn’t access. We could test thoroughly with virtual machines but as we found when testing on real phones there are some things about how the game looks and plays that can only be reproduced on the real platform.

Solved! (Not!)

So our marketing team (Harmony and Felicity) and I did some research on recruiting Beta Testers and we quickly realised that we couldn’t affort to pay for the service.
We did find a wealth of paid services out there which I’ll list below in case someone can make use of that information.

Not all of these services were paid but most of them required some sort of effort or buy-in up front that we couldn’t match.

http://appstorm.net/
http://appuseful.com/app/add
http://betacandy.com/
http://betali.st/
http://betalist.com/
http://betapage.co/
http://betatesters.io/?utm_source=InstabugBlog&content=betatestbeginnersguide
http://erlibird.com/

Ready to introduce your startup to the world?


http://makeuseof.com/
http://market.thenextweb.com/
http://momb.socio-kybernetics.net/

Contact us


http://quora.com/
http://startupli.st/
http://startuplift.com/
http://web.appstorm.net/
http://www.betabound.com/
http://www.betabound.com/announce/
http://www.mob4hire.com/

Submit Your StartUp

Submit

Submit Startup


http://younoodle.com/
https://betafamily.com/
https://feedmyapp.com/
https://inspiredbeta.com/
https://www.topcoder.com/
https://www.usertesting.com/
https://www.utest.com/

Social Media Save Me!

So we turned our attention to the online communities that might be able to assist us.
We did some more research and found that social media is literally teeming with sites and groups that want to Beta Test your app. Awesome. Problem solved.

We published a Beta version of the app on the Play Store and mocked up some Beta Testing campaign ideas along with a set of goals that we had for Beta Tests. We were looking for technical testers as opposed Marketing and I can tell you I was pretty excited about getting some feedback on the game. When we pubished the Beta version of the game we could choose a number of Beta testers that the game would be released to. The interface gave us a minimum of 1000 users so we went with that and given the number of social media sites we found thought that this didn’t sound all that unreasonable.

This is a brief list of the social media sites and lists and groups that we advertised for Beta Testers on….

Google Communities:
Android Beta Tests
https://plus.google.com/u/0/communities/109783274236354693762
Android Game Developer
https://plus.google.com/u/0/communities/107240075790372473394
Indie Game Developers
https://plus.google.com/u/0/communities/116817422244345691332
Game Developers
https://plus.google.com/u/0/communities/100673606633986699530
Game Developers
https://plus.google.com/u/0/communities/101640237427303194102
Game Programmers
https://plus.google.com/u/0/communities/102656807509358954492
Mobile Game & App Developers
https://plus.google.com/u/0/communities/107514033174068960125

http://www.reddit.com:
/r/TestMyApp
/r/alphaandbetausers
/r/AndroidAppTesters
/r/startups
/r/betatests
/r/androidapps

https://twitter.com/:
search?q=%23Betatesting%20&src=typd
search?q=%23Betatesters&src=typd
search?q=%23Testmyapp&src=typd
search?q=%23Indiedev&src=typd

We even did a big call through our Facebook Page and Blog.

Big Reveal!!!

Guess how many Beta Testers came flocking to try out our great new game…..

None. Zero. Zilch. Nada. Not one.

We checked around the boards on these sites and groups and actually found very little actual Beta Testing going on.
After a few weeks of interacting with these communities and even testing a few apps ourselves thinking that we might get some kind of Beta Testers Karma we still found that no-one really wants to test your app (unless maybe if you are building a huge free MMO that’s going to be awesome – anyone doing that?).

Free Advice!

So there you have it – Beta Testing using social media groups doesn’t work. You don’t get nufin’ for free in life.

So my advice to you is that if you don’t have one already, start building an email list now. For a startup game dev studio with no support framework it’s pretty hard to come by free help when you need it. Ideally, start collecting email addresses before you even have an app, and keep at it! Because even a handfull of Beta Testers is better than none.