Develop Reference

Unity GoogleMobileAdsMediationTestSuite throws exception setAdListener must be called on the main UI thread

I tried to implement MediationTestSuite into my Unity Game, but I got this exception and therefore couldn't see MediationTestSuite
Exception:
java.lang.IllegalStateException: setAdListener must be called on the main UI thread.
at lr.b(:com.google.android.gms.policy_ads_fdr_dynamite#21001000#21001000.272763194.272763194:1)
at com.google.android.gms.ads.nonagon.shim.f.a(:com.google.android.gms.policy_ads_fdr_dynamite#21001000#21001000.272763194.272763194:14)
at com.google.android.gms.ads.nonagon.shim.g.a(:com.google.android.gms.policy_ads_fdr_dynamite#21001000#21001000.272763194.272763194:4)
at com.google.android.gms.ads.internal.client.ap.a(:com.google.android.gms.policy_ads_fdr_dynamite#21001000#21001000.272763194.272763194:62)
at ff.onTransact(:com.google.android.gms.policy_ads_fdr_dynamite#21001000#21001000.272763194.272763194:4)
at android.os.Binder.transact(Binder.java:667)
My code is
public void OnButtonClick()
{
GoogleMobileAdsMediationTestSuite.Api.MediationTestSuite.Show();
}
Binded on single button in scene.
​​​I've tried to do this directly in Update method by dispatching this call, also tried to create empty Unity project and by adding into it only GoogleMobileAds-v4.1.0 + GoogleMobileAdsUnityAdsMediation + GoogleMobileAdsMediationTestSuite all downloaded directly from Google links.
Is there something I'm missing here, or is it just MediationTestSuite that is bugged and calles some UI stuff in separate thread?
It's definetely not a duplicate of AdMob Interstitial and error isLoaded must be called on the main UI thread since it's in Unity and I do not have access to MeditationTestSuite library code.

Well. It was all simple. Apparentely MediationTestSuite throws this kind of exception when you unity build doesn't have "development build" mark. But I did have it. The case was that I should've used assembleDebug in gradle build tasks.
I've got this problem because I builded my android manually by exporting into android project instead of building with unity.

Kotlin in Flutter application causing Crash

Since the last flutter update there has been an issue when I try to use the media player plugin witch uses Kotlin.
When you hit the button and it is suppose to play the audio file, it causes the application to crash.
fun play(url: String) {
player.reset()
channel.invokeMethod("onPosition", 0.0)
player.setDataSource(url)
player.prepareAsync()
channel.invokeMethod("onIsLoading", null)
task?.cancel()
task = object : TimerTask() {
override fun run() {
if (player.isPlaying) {
session.setPlaybackState(PlaybackStateCompat.Builder()
.setState(PlaybackStateCompat.STATE_PLAYING, player.currentPosition.toLong(), 1f)
.build())
channel.invokeMethod("onPosition", player.currentPosition.toDouble() / player.duration.toDouble())
}
}
}
timer.schedule(task, 0, 100)
}
it was suggested that I add this in.
activity.runOnUiThread(java.lang.Runnable {
channel.invokeMethod(...)
})
but I if I do I get
Unresolved Reference: activity
This is the error message.
java.lang.RuntimeException: Methods marked with #UiThread must be executed on the main thread. Current thread: Timer-0
at io.flutter.embedding.engine.FlutterJNI.ensureRunningOnMainThread(FlutterJNI.java:605)
at io.flutter.embedding.engine.FlutterJNI.dispatchPlatformMessage(FlutterJNI.java:515)
at io.flutter.embedding.engine.dart.DartMessenger.send(DartMessenger.java:76)
at io.flutter.embedding.engine.dart.DartExecutor.send(DartExecutor.java:166)
at io.flutter.view.FlutterNativeView.send(FlutterNativeView.java:155)
at io.flutter.plugin.common.MethodChannel.invokeMethod(MethodChannel.java:98)
at io.flutter.plugin.common.MethodChannel.invokeMethod(MethodChannel.java:84)
at live.exit.musicplayer.MusicPlayer$play$1.run(MusicPlayer.kt:49)
at java.util.TimerThread.mainLoop(Timer.java:562)
at java.util.TimerThread.run(Timer.java:512)
I am at a bit of a loss, this is suppose to be playing audio.
I know NOTHING about kotlin.

I think you're using ragotrebor music-player plugin (https://gitlab.com/ragotrebor). Looking at their history a merge was made about a month ago which should fix this issue.
Just update to the latest version of the plugin and you should be good to go!
Background
It's related to a change in flutter to fix a bug which caused FlutterJNI (Java Native Interface) to crash intermittently when certain methods were executed outside of the main thread. Flutter was changed to thrown an exception in all cases, to avoid this intermittent crash and force developers to run methods correctly on the UI thread. Unfortunately this caused many existing plugins to crash and developers were required to update their source code.
Reference links
Change with discussion: https://github.com/flutter/engine/commit/2c9e37c34e79475bbde7c8163eb5e56cdb9662a
Found through this thread discussing a fix for a specific plugin: https://github.com/flutter/flutter/issues/34993).
Merge request details for music player plugin that fixed this issue: https://gitlab.com/exitlive/music-player/commit/693131a7f0d29b3ee42ba9fa2a5ce65aef7652fb

Running ExtractDecodeEditEncodeMuxTest outside of testcase on Android

I am trying to add functionality to extract, decode, edit, encode and mux a video on Android. Therefore, I found some very useful implementation, which is part of the Android CTS ExtractDecodeEditEncodeMuxTest. Unfortunately, the code only works if it is executed as part of the testcase. I tried to execute it from a normal activity and get:
E/ExtractDecodeEditEncodeMuxTest (18781): java.lang.IllegalStateException:
Failed to stop the muxer
W/System.err(18781): java.lang.RuntimeException:
Surface frame wait timed out
W/System.err(18781): at ...OutputSurface.awaitNewImage(OutputSurface.java:216)
Any ideas, why the output surface does not receive the frames?
UPDATE:
Here are the log files for the working test case and the non-working implementation. The code for both is exactly the same. The only difference is that the working one is an AndroidTestCase and the other one is running in the application within an IntentService.
It seems that the whole thing stops extracting and decoding after about 6 frames. Any ideas?
Working Testcase Logoutput
Non-Working Log Output

morelikely you need to run it in separate thread
public static void runTest(ExtractDecodeEditEncodeMuxTest test) throws Throwable {
test.setOutputFile();
TestWrapper wrapper = new TestWrapper(test);
Thread th = new Thread(wrapper, "codec test");
th.start();
th.join();
if (wrapper.mThrowable != null) {
throw wrapper.mThrowable;
}
}

Thank's to fadden, I was able to resolve this issue. I am using an intent service now and start a thread without looper there, which works fine.
For running the code in an Android service, this means that the wrapping thread has to be started from a custom thread. Starting a thread within a thread is probably not the very best solution, but it actually solves the problem.

Handle main commands in android native activity

In android native activity you can handle main commands from system in your own method. I know how to do this, but i dont know what all states i can handle. I know few states like APP_CMD_SAVE_STATE, APP_CMD_INIT_WINDOW... but that´s not all. I cant find list of states or android_native_app_glue.h header file anywhere. Can someone refer me or write list of events with their numebers and when they´r called?Thanks
void CMDMethod(struct android_app* app, int32_t state)
{
switch(state)
{
case APP_CMD_SAVE_STANE: //some code
break;
//what can be next cases?
}
}
void android_main(struct android_app* state)
{
state->onAppCmd = CMDMethod;
}

Heres the enum found in android_native_app_glue.h
enum {
APP_CMD_INPUT_CHANGED,
APP_CMD_INIT_WINDOW,
APP_CMD_TERM_WINDOW,
APP_CMD_WINDOW_RESIZED,
APP_CMD_WINDOW_REDRAW_NEEDED,
APP_CMD_CONTENT_RECT_CHANGED,
APP_CMD_GAINED_FOCUS,
APP_CMD_LOST_FOCUS,
APP_CMD_CONFIG_CHANGED,
APP_CMD_LOW_MEMORY,
APP_CMD_START,
APP_CMD_RESUME,
APP_CMD_SAVE_STATE,
APP_CMD_PAUSE,
APP_CMD_STOP,
APP_CMD_DESTROY,
};
APP_CMD_INPUT_CHANGED - Command from main thread: the AInputQueue has changed. Upon processing this command, android_app->inputQueue will be updated to the new queue (or NULL).
APP_CMD_INIT_WINDOW - Command from main thread: a new ANativeWindow is ready for use. Upon receiving this command, android_app->window will contain the new window surface.
APP_CMD_TERM_WINDOW - Command from main thread: the existing ANativeWindow needs to be terminated. Upon receiving this command, android_app->window still contains the existing window; after calling android_app_exec_cmd it will be set to NULL.
APP_CMD_WINDOW_RESIZED - Command from main thread: the current ANativeWindow has been resized. Please redraw with its new size.
APP_CMD_WINDOW_REDRAW_NEEDED - Command from main thread: the system needs that the current ANativeWindow be redrawn. You should redraw the window before handing this to android_app_exec_cmd() in order to avoid transient drawing glitches.
APP_CMD_CONTENT_RECT_CHANGED - Command from main thread: the content area of the window has changed, such as from the soft input window being shown or hidden. You can find the new content rect in android_app::contentRect.
APP_CMD_GAINED_FOCUS - Command from main thread: the app's activity window has gained input focus.
APP_CMD_LOST_FOCUS - Command from main thread: the app's activity window has lost input focus.
APP_CMD_CONFIG_CHANGED - Command from main thread: the current device configuration has changed.
APP_CMD_LOW_MEMORY - Command from main thread: the system is running low on memory. Try to reduce your memory use.
APP_CMD_START - Command from main thread: the app's activity has been started.
APP_CMD_RESUME - Command from main thread: the app's activity has been resumed.
APP_CMD_SAVE_STATE - Command from main thread: the app should generate a new saved state for itself, to restore from later if needed. If you have saved state, allocate it with malloc and place it in android_app.savedState with the size in android_app.savedStateSize. The will be freed for you later.
APP_CMD_PAUSE - Command from main thread: the app's activity has been paused.
APP_CMD_STOP - Command from main thread: the app's activity has been stopped.
APP_CMD_DESTROY - Command from main thread: the app's activity is being destroyed, and waiting for the app thread to clean up and exit before proceeding.

I think I saw something about that in this book http://www.packtpub.com/android-ndk-beginners-guide/book. But can be wrong. In there there definitely is a chapter about creating a completely native activity with that loop processing all those states.

Runtime.exec() bug: hangs without providing a Process object

Whether I use this:
process = Runtime.getRuntime().exec("logcat -d time");
or that:
process = new ProcessBuilder()
.command("logcat", "-d", "time")
.redirectErrorStream(true)
.start();
I get the same results: it often hangs within the exec() or start() call, no matter what I tried to do!
The thread running this cannot even be interrupted with Thread.interrupt()! The child process is definitely started and if killed the above commands return.
These calls may fail on first attempt, so THERE IS NO WAY TO READ THEIR OUTPUT! I can also use a simple "su -c kill xxx" command line, same result!
EDIT: Started debugging the java_lang_ProcessManager.cpp file in an NDK project with some debugging logs! So here is what I found so far, after the fork() the parent does this:
int result;
int count = read(statusIn, &result, sizeof(int)); <- hangs there
close(statusIn);
Though the child process is not supposed to block on it: That's what the child does (if started at all!):
// Make statusOut automatically close if execvp() succeeds.
fcntl(statusOut, F_SETFD, FD_CLOEXEC); <- make the parent will not block
// Close remaining unwanted open fds.
closeNonStandardFds(statusOut, androidSystemPropertiesFd); <- hangs here sometimes
...
execvp(commands[0], commands);
// If we got here, execvp() failed or the working dir was invalid.
execFailed:
int error = errno;
write(statusOut, &error, sizeof(int));
close(statusOut);
exit(error);
The child can fail for 2 reproducible reasons:
1- child code is not running, but the parent believes it is!
2- child blocks on
closeNonStandardFds(statusOut, androidSystemPropertiesFd);
In either case the read(statusIn...) in the parent ends in deadlock! and a child process is left dead (and cannot be accessed, pid unknown, no Process object)!

This problem is fixed in Jelly Bean (Android 4.1) but not in ICS (4.0.4) and I guess it will never be fixed in ICS.

Above solution didn't prove to be reliable in any ways, causing more issues on some devices!
So I reverted back to the standard .exec() and kept digging...
Looking at the child code that hangs, I noticed the child process will hang while trying to close all file descriptors inherited from the parent (except the one created within the exec() call) !
So I search the whole app code for any BufferedReader/Writer and similar classes to make sure those would be closed when calling exec()!
The frequency of the issue was considerably reduced, and actually never occured again when I removed the last opened file descriptor before calling exec().
NB: Make sure SU binary is up-to-date, it can actually cause this issue too!
Enjoy your search ;)

Bug fix in Bionic was commited monthes ago, but it still hasn't been included in Android 4.0.4.

I have the same problem on ICS (seem to works fine on Android < 4). Did you find a solution?
A simple workaround could be to call the "exec" method in a dedicated thread with a timeout-join so that this situation could be "detected" (yes I know it's not very elegant...)