Develop Reference

React Native Expo Android crashes only in production and is also not catchable in Sentry

Already tried to look into all different problems here on StackOverflow with related titles, like this one. But no success.
Here is the piece of code where the problem happens:
const fetchApi = useCallback(async () => {
setIsLoading(true);
if (activePortfolioId) {
try {
const response = await getApis().portfoliosApi.getPortfolioOverviewById(
activePortfolioId
);
if (response.data && response.data?.tickers?.length) {
setItems(handleListItems(response.data.tickers));
}
} catch (error) {
Sentry.Native.captureException(error);
Sentry.Native.captureMessage('HELLO?');
Alert.alert(
'Sorry!',
'We were unable to retrieve the performance list. Please try again later.'
);
} finally {
setIsLoading(false);
}
}
}, [activePortfolioId]);
So what happens is, on iOS I have no problem at all here, either on DEV or PROD, using real device or simulator, everything works fine, never went to the catch statement. On Android, using simulator or real device with Expo, it's all fine too, even using expo start --no-dev --minify to try to reproduce the app as PROD, occurs no errors at all. I have tried everything that came on my mind, like removing pieces of the code to see if the problem stops. Like instead of calling the API, just setting the items, like this:
setItems(handleListItems(response.data.tickers)); because I also thought that the problem might be with my handler function, I also tried to just do setItems([{ OBJECT HERE }]);. The problem has just stopped once I stopped setting the items. So I also tried to check my renderItem function, tried to stop using any styled component, just what React Native provides, nothing works. Then I decided to bring Sentry to my code but even with Sentry, no issues is shown there. I open the screen, it is loading, fetches the API, then it falls in the catch block, because I see the Alert on Android and then the app crashes and go back to the splash screen frozen. The only issue that appeared on Sentry was:
Could not open URL 'https://XXXXXXX': No Activity found to handle Intent { act=android.intent.action.VIEW dat=https://XXXXXXX... flg=0x10000000 }
But strangely I have never clicked on this during the "tests" and this link just appears on the login screen, shouldn't have anything to do with the problem itself, right?
I really don't know what else I could try to do and figure out what is causing this problem, so decided to ask for help and maybe find someone who already went through something similar.
Thanks!
PS: I'm using TS too, so apparently no problems with some possible undefined or whatever.

Found the issue, it was with the Intl. Solution here.

setVideoPath Illegal State Exception

I'm running through a slideshow in an infinite loop. Every 'x' amount of time, I switch the video playing. First I stop the video, and then I load the new video. My app is crashing when I set the video path, with an error that there is an illegal state. It only happens once every couple thousand uses, so I cannot replicate it. That is, if I leave the app open for 24 hours on 100 devices, it will happen once per day on one device.
runOnUiThread() {
if (mVideoView!!.isPlaying) {
mVideoView!!.stopPlayback()
}
mVideoView!!.setVideoPath(filePath)
mVideoView!!.setOnErrorListener { mp, what, extra ->
LOG.e("Media player error: $what extra: $extra")
// Something's wrong, try again
slideshowHandler.removeCallbacksAndMessages(null)
slideshowHandler.postDelayed(slideshowRunner, 0)
true
}
if (startTime > 0) {
mVideoView!!.seekTo(startTime)
}
mVideoView!!.start()
}
}
java.lang.IllegalStateException
at android.media.MediaPlayer.prepareAsync(Native Method)
at android.widget.VideoView.openVideo(VideoView.java:356)
at android.widget.VideoView.setVideoURI(VideoView.java:265)
at android.widget.VideoView.setVideoURI(VideoView.java:248)
at android.widget.VideoView.setVideoPath(VideoView.java:239)
Any thoughts on what this could be? What state is invalid? Am I doing things in the wrong order?
I can't find any similar issues on SO. The app is running lollipop 5.1 (has to).
Edit: I'm fixing this right now using a try/catch. Seems like there is some underlying bug in Android that is causing this.

Android: Possible maximum number of audiosessions or effect engines for audio? (EQ, REV...)

for awhile now, I am working on a media playing app. In this app, I also programmed a little 5 Band EQ using mainly this code:
try
{
AppPreferencesClass ap = new AppPreferencesClass(ctx);
if (Activity_Player.eq != null)
{
Activity_Player.eq.Dispose();
}
Activity_Player.eq = new Android.Media.Audiofx.Equalizer(0, Activity_Player.mediaPlayerSessionId);
Activity_Player.eq.SetEnabled(true);
await Task.Run(() =>
{
if (Activity_Player.EqActive)
{
if (ap.getAwesomeSound())
{
Activity_Player.eq.SetBandLevel(0, Convert.ToInt16(Activity_Equalizer.awesomesound0));
Activity_Player.eq.SetBandLevel(1, Convert.ToInt16(Activity_Equalizer.awesomesound1));
Activity_Player.eq.SetBandLevel(2, Convert.ToInt16(Activity_Equalizer.awesomesound2));
Activity_Player.eq.SetBandLevel(3, Convert.ToInt16(Activity_Equalizer.awesomesound3));
Activity_Player.eq.SetBandLevel(4, Convert.ToInt16(Activity_Equalizer.awesomesound4));
}
else
{
Activity_Player.eq.SetBandLevel(0, Convert.ToInt16(ap.getEQ0()));
Activity_Player.eq.SetBandLevel(1, Convert.ToInt16(ap.getEQ1()));
Activity_Player.eq.SetBandLevel(2, Convert.ToInt16(ap.getEQ2()));
Activity_Player.eq.SetBandLevel(3, Convert.ToInt16(ap.getEQ3()));
Activity_Player.eq.SetBandLevel(4, Convert.ToInt16(ap.getEQ4()));
}
}
});
}
catch
{
}
For many days, this worked just fine but out of NO WHERE, the catch block sometimes gets activated. But only occasionally.On other times, try works fine but there are just no more changes to the audio being played. This is odd enough, since I never changed anything on this code after it starting working.
I then tried another phone (Samsung S4) on my code and the eq worked just perfectly.
So this got me googleing and I think I might have heard that there can only be as many audiosession IDs after you just would run out. I tested and the audio session ID used here is somewhere at 74,000.
So this could be an issue I thought but this would easialy be tested because I already had this very app running in the google play store just an older version of it. I am 100 percent positive, that in this version the EQ worked on my phone. Otherwise I would have not uploaded that version.
Anyway, I downloaded my old app from the play store and here we go:
It doesnt work anymore. The EQ in the old version also has simply NO effect on the audio. While ofcourse on my other phones this old version works perfectly.
Before I am going to reset my own personal phone I wanted to ask you guys if this could be infact the case.
Another thing is, that I am using many static variables in order to get the EQ to work right. Actually, the variable EQ itself is static. Do maybe static variables sort of leave a "trace" behind and maybe I have set the eq up just "too" many times? Although I am disposing of the object before intialising it again (see in my code).
Summing up:
1.) Can there maybe be a maxmium number of EQ or AudioSessionIDs and I have passed those?
2.) Can creating static variables over and over again in my code cause a memory leak so big, even deinstalling the app doesnt do anything?
Thank you!
This is the error log:
11-20 12:16:43.736 E/AudioEffect(16990): set(): AudioFlinger could not create effect, status: -38
11-20 12:16:43.736 E/AudioEffects-JNI(16990): Error setting AudioEffect
11-20 12:16:43.737 E/AudioEffect-JAVA(16990): Error code -19 when initializing AudioEffect.
Thread started: #311-20 12:16:43.745 V/MediaPlayerNative(16990): unrecognized message: (6, 0, 0)

After 2 days of googeling and trying evetything out, here is the issue:
NOT CALLING RELEASE() will have you eventually have to REBOOT your phone. It wont allow too many instances of an EQ to be set.
Solution:
if (eq != null)
{
eq.Release();
}

MediaRouter connect second time

I am using Android's MediaRouter / Presentation API (the support.v7 version).
Everything works fine so far. The only thing that doesn't is:
When I quit my activity (e.g.teardown & remove the callbacks), everything still works fine.
However, when starting this activity (the previous mediarouter-activity was forcefully finished, thus onPause/onDestroy was called FOR SURE => so those callbacks in there are gone too, as also shown in my debug messages) again at some later point in time, the callbacks get created and added and everything. Just, that there is no more onRouteAdded called, only onProviderChanged (With the default provider and thus useless).
It does always work like that (with wifi display [miracast], emulated secondary display, chromecast secondary display..). Are there any resolutions which are not in the examples?
Would you like to look at some code? Which special cases? (Can't post it all..)
I couldn't find anything so far, thanks for your help, in advance.

If you change the Google Cast sample app to support MediaRouter.Callback:
https://github.com/googlecast/CastPresentation-android
Then I'm getting the onRouteAdded called every time.

Using getSelectedRoute()instead of the RouteInfo (which is provided by the callbacks) did the job for me.
MediaRouter.RouteInfo selectedRoute = getHelper().getMediaRouter().getSelectedRoute();
if(provider != null && getCurrentRoute() != null && getCurrentRoute().equals(selectedRoute)){
Log.d(TAG, "only provider changes, dont do anything");
return false;
}
if (selectedRoute != null) {
setCurrentRoute(selectedRoute);
}
return updateContents();
this is definetly weird (as the rest of the code looks exactly as in the provided google android developer samples), but it works.

I know this problem was resolved over 1 year ago, but probably it isn't the perfect solution. Maybe it will be useful for somebody else.
I had similar problem with exactly the same symptoms (no more onRouteAdded called). In my situation it was caused by improperly implemented deactivation of MediaRouter: to deactivate it properly you should not only remove all of callbacks, but select default MediaRoute as well.
if (!mMediaRouter.getDefaultRoute().isSelected()) {
mMediaRouter.getDefaultRoute().select();
}

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...)