Token android os binderproxy

android.os.BinderProxy@424e5cf8 is not valid; is your activity running? #192

Comments

zengyimou commented Apr 9, 2018

Caused by android.view.WindowManager$BadTokenException: Unable to add window — token android.os.BinderProxy@424e5cf8 is not valid; is your activity running?
at android.view.ViewRootImpl.setView(ViewRootImpl.java:578)
at android.view.WindowManagerGlobal.addView(WindowManagerGlobal.java:269)
at android.view.WindowManagerImpl.addView(WindowManagerImpl.java:69)
at android.app.Dialog.show(Dialog.java:323)
at com.cboy.rn.splashscreen.SplashScreen$1.run(SplashScreen.java:34)
at android.app.Activity.runOnUiThread(Activity.java:4766)
at com.cboy.rn.splashscreen.SplashScreen.show(SplashScreen.java:24)
at com.cboy.rn.splashscreen.SplashScreen.show(SplashScreen.java:44)
at com.zun1.flyapp.MainActivity.onCreate(MainActivity.java:93)
at android.app.Activity.performCreate(Activity.java:5285)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1090)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2259)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2345)
at android.app.ActivityThread.access$1100(ActivityThread.java:139)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1256)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:136)
at android.app.ActivityThread.main(ActivityThread.java:5314)
at java.lang.reflect.Method.invokeNative(Method.java)
at java.lang.reflect.Method.invoke(Method.java:515)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:864)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:680)
at dalvik.system.NativeStart.main(NativeStart.java)

this carsh only happen on android 4.0 , please help me .

The text was updated successfully, but these errors were encountered:

zengyimou commented Apr 13, 2018

someone can help?

techyrajeev commented Apr 23, 2018

I am also facing the same issue. Couldn’t figure out the solution yet.

Mad-hu commented Apr 26, 2018 •

I am also the same issue, I comment out // SplashScreen.show(this); this code .
Android Studio 3.1.2
React Naitve 0.55.3
Splash Screen Version: 3.0.6

oOGenosOo commented Jun 12, 2018

Seems to be a Contect Problem, your context not exist when you call it, look here for more informations:

zengyimou commented Jun 14, 2018

but , it only happens on android 4. Why other version didn’t happen?

oOGenosOo commented Jun 14, 2018

Maybe is not a problem of android 4 but a problem of device speed, an android 4 device is slower (faster if is an emulator) that a newer one, and some asyncronous task end later than you expect, working on a non existent context (that you’ve previously dispose). thy to change the way you get your context.

zengyimou commented Jun 14, 2018

ok thanks your help

globalsalt commented Mar 21, 2019

I also get the same error. But the problem is that the same project is working in Lollipop and not working in Nougat version. and I am getting the below error.

One more point I want to share with you all. After crashing the app in Nougat with below error and when I open the app again it works fine i.e the app is not crashing. I don’t know where is the problem.

Источник

[BUG] handleWindowVisibility: no activity for token android.os.BinderProxy@22067a8 When no albumn #169

Comments

limsocheat commented Sep 7, 2019

Describe the bug
Cannot click to capture image/open camera When No Ablumn Found

W/ActivityThread(13055): handleWindowVisibility: no activity for token android.os.BinderProxy@22067a8 E/RecyclerView(13055): No adapter attached; skipping layout D/EGL_emulation(13055): eglMakeCurrent: 0xe32055a0: ver 3 0 (tinfo 0xe32037c0) W/System.err(13055): java.io.IOException: No such file or directory W/System.err(13055): at java.io.UnixFileSystem.createFileExclusively0(Native Method) W/System.err(13055): at java.io.UnixFileSystem.createFileExclusively(UnixFileSystem.java:281) W/System.err(13055): at java.io.File.createTempFile(File.java:2018) W/System.err(13055): at com.sangcomz.fishbun.util.CameraUtil.createImageFile(CameraUtil.java:58) W/System.err(13055): at com.sangcomz.fishbun.util.CameraUtil.takePicture(CameraUtil.java:31) W/System.err(13055): at com.sangcomz.fishbun.ui.album.AlbumController.takePicture(AlbumController.java:132) W/System.err(13055): at com.sangcomz.fishbun.ui.album.AlbumActivity$1.onClick(AlbumActivity.java:96) W/System.err(13055): at android.view.View.performClick(View.java:6597) W/System.err(13055): at android.view.View.performClickInternal(View.java:6574) W/System.err(13055): at android.view.View.access$3100(View.java:778) W/System.err(13055): at android.view.View$PerformClick.run(View.java:25885) W/System.err(13055): at android.os.Handler.handleCallback(Handler.java:873) W/System.err(13055): at android.os.Handler.dispatchMessage(Handler.java:99) W/System.err(13055): at android.os.Looper.loop(Looper.java:193) W/System.err(13055): at android.app.ActivityThread.main(ActivityThread.java:6669) W/System.err(13055): at java.lang.reflect.Method.invoke(Native Method) W/System.err(13055): at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493) W/System.err(13055): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)

To Reproduce
Steps to reproduce the behavior:

1. Click on the pick image button
2. Open picker screen (No Album), return message: There is no albumn. Take A Picture!
3. Click on «Take A Picture!» button
4. Return Error exception in the console as BUG description above

Expected behavior
It is expected to open Camera and take a photo.

Screenshots

Additional context

[✓] Flutter (Channel stable, v1.7.8+hotfix.4, on Mac OS X 10.14.6 18G95, locale en-US)

[✓] Android toolchain — develop for Android devices (Android SDK version 29.0.2)
[✓] Xcode — develop for iOS and macOS (Xcode 10.3)
[✓] iOS tools — develop for iOS devices
[✓] Android Studio (version 3.5)
[✓] VS Code (version 1.37.1)
[✓] Connected device (4 available)

The text was updated successfully, but these errors were encountered:

Источник

Некоторые “подводные камни” разработки под Android

Недавно наша команда завершила разработку приложения под Android. В процессе разработки и затем поддержки мы столкнулись с некоторыми проблемами технического характера. Часть из них — это наши баги, которых мы могли бы избежать, другая часть — это совсем неочевидные особенности Android, которые либо плохо описаны в документации, либо не описаны вообще.

В этой статье я бы хотел рассмотреть несколько реальных багов, которые возникли у наших пользователей и рассказать о путях их решения.

Статья не претендует на подробный анализ потенциальных проблем, это просто рассказ из жизни одно реального Android приложения.

RTFM (http://en.wikipedia.org/wiki/RTFM)

Так как при разработке под Android надо иметь в виду, что ваше приложение может работать на огромном количестве различных устройств, то надо думать о проблемах их совместимости.

Вот например одна из ошибок, которая возникала у наших пользователей:

А причина — проста, согласно документации класс android.util.Patterns доступен начиная с версии API 8 (Android 2.2.x), а у пользователя была версия 2.1. Решили мы это конечно оберткой этого кода в try/catch .

Вот еще одна подобная проблема вызванная невнимательным чтением документации:

Все дело в том, что strict mode (http://developer.android.com/reference/android/os/StrictMode.html) был включен по умолчанию в Android начиная с версии 3.0. Это значит, что ваше приложение не может обращаться к сети напрямую из основного UI потока, так как это может занимать некоторое время и при этом основной поток блокируется и не отвечает на другие события. Мы старались избегать подобного поведения, но в одном из мест все-таки остался простой сетевой вызов. Решена эта проблема была тем, что мы вынесли этот код в другой поток.

Поворот устройства — что может быть проще и привычнее для пользователя?

Казалось бы, для мобильных устройств смена ориентации экрана — это вещь настолько часто используемая и привычная, что это должно отразиться и в API. Т.е. эта ситуация должна обрабатываться очень просто. Но нет. Тут много нюансов.

Допустим, что нам необходимо сделать приложение, которое загружает список чего-либо и выводит его на экран. Т.е. при старте Activity (в методе onCreate() ) мы запускаем поток (чтобы не блокировать UI поток), который будет загружать данные. Этот поток отрабатывает некоторое время, поэтому мы будет отображать процесс загрузки в ProgressDialog . Все просто и замечательно работает.

Но, после загрузки, пользователь повернул устройство и тут мы обнаруживаем, что снова появился ProgressDialog и мы опять загружаем наши данные. Но ведь ничего не изменилось? Просто человеку удобнее смотреть на этот список повернув устройство.

А все дело в том, что метод onCreate() вызывается не только при создании Activity , но и при повороте экрана! Но мы не хотим засталять пользователя снова ждать загрузки. Все что нам надо — это снова показать уже загруженные данные.

Если мы поищем в интернете, мы найдем много ссылок на описание этой проблемы и также огромное количество примеров как решить эту проблему. И что самое плохое, что большинство таких ссылок предлагает неверное решение. Вот пример этого — http://codesex.org/articles/33-android-rotate

Не делайте обработку поворота экрана через onConfigurationChanged() ! Это неверно! Официальная документация ясно утверждает что “Using this attribute should be avoided and used only as a last-resort.“ http://developer.android.com/guide/topics/manifest/activity-element.html#config

А вот правильный подход описан здесь — http://developer.android.com/guide/topics/resources/runtime-changes.html И как показывает практика — он не прост в имплементации.

Идея в том, что перед разворотом экрана Android вызовет метод onRetainNonConfigurationInstance() вашего Activity . И вы можете вернуть данные (например список загруженных объектов) из этого метода, которые и будут сохранены между 2 вызовами метода onCreate() вашего Activity . Затем при вызове onCreate() вы можете вызвать getLastNonConfigurationInstance() который и вернет вам сохраненные данные. Т.е. при создании Activity вы вызываете getLastNonConfigurationInstance() и если он вам вернул данные — то эти данные уже были загружены и надо только отобразить их. Если же не вернул данные — то запускаете загрузку.

Но вот на практике ситуация выглядит так. У нас может быть 2 варианта когда пользователь поворачивает устройство. Первый вариант — когда идет загрузка данных (работает наш поток который загружает данные и при этом отображается ProgressDialog ) или данные уже загружены и мы сохранили их в списке для отображения. Получается, что в первом случае мы при повороте должны сохранить ссылку на работающий поток, а во втором случае ссылку на уже загруженный список. Мы так и делаем.

Но это усложняет наш код и не кажется мне простым и интуитивным. Более того, когда идет смена ориентации экрана и мы сохранили поток загрузки данных, мы потом вынуждены при onCreate() опять восстанавливать ProgressDialog ! А если добавить сюда, что в нашем приложении пользователь может загружать данные из разных мест и у нас не один поток загрузки данных, а несколько — то количество кода которое обслуживает простой поворот экрана становится просто огромным.

Честно сказать, я не понимаю почему это было сделано так сложно.

Чуть более подробнее о потоках или использование AsyncTask.

Давайте рассмотрим загрузку данных в другом потоке чуть более подробно, так как и при этом нас ждали неожиданные “сюрпризы”.

Немного теории: для облегчения создания и работы в потоке отличном от основного UI потока был сделан специальный класс — AsyncTask (http://developer.android.com/reference/android/os/AsyncTask.html)

Суть его в том, что в нем уже есть готовые методы onPreExecute() и onPostExecute(Result) , которые выполняются в основном UI потоке и которые служат для отображение чего-либо и есть метод doInBackground(Params. ) внутри которого и происходит основная работа и он запускается в отдельном потоке автоматически. Вот примерный код как это выглядит:

Все просто и красиво.

Но теперь — немного практики. Вот Вам ошибка от реального пользователя:

А эта ошибка означает, что когда мы вызываем spinner.show() в методе onPreExecute() , то этот ProgressDialog созданный со ссылкой на MyActivity уже неактивен и его нет на экране! Ладно, я еще понимаю как такое может быть при вызове onPostExecute() . Т.е. например пока мы загружали данные пользователь нажал Back и наш ProgressDialog ушел с экрана. Но как такое может быть сразу при вызове загрузки, когда этот код стартует сразу при затуске Activity — это для меня неясно.

Но в любом случае, мы должны обрабатывать такие ситуации поэтому мы решили это обеткой методов spinner.show() и spinner.dismiss() в try/catch . Решение конечно не очень красивое, но в нашем случае — вполне функциональное.

Кстати, такой же код есть и например в Facebook SDK for Android, который был разработан другими опытными разрабочиками. И там тоже у нас были ситуации когда приложение вылетало при закрытии ProgressDialog . Нам пришлось добавить обработку и в их код. Так что проблема эта — не только в нас.

Добавьте сюда еще проблему, что была описана ранее. Что при повороте устройства надо пересоздавать ProgressDialog если поворот был во время загрузки данных. Это тоже добавит сюда вспомогательного кода.

И еще стоит вспомнить что метод doInBackground() выполняется в отдельном потоке и поэтому если при загрузке данных произошла ошибка, то нельзя выдать Alert прямо оттуда, так как это не UI поток. Надо сохранить ошибку, а затем после выхода из потока загрузки в методе onPostExecute(Void result) уже можно что-то показать.

Т.е. опять много вспомогательного кода и не все так просто…

AlarmManager

А еще есть моменты которые вообще не описаны в документации. Например, мы в своем приложении используем AlarmManager (http://developer.android.com/reference/android/app/AlarmManager.html) который помогает нам выдавать сообщения пользователю через некоторое время когда само наше приложение уже закрыто.

Этот AlarmManager — штука очень полезная, вот только проблема в том, что иногда он “теряет” созданные в нем нотификации! Мы потратили кучу времени чтобы понять как и почему это происходит, перерыли всю документацию и ничего не нашли. Совершенно случайно мы “набрели” на это обсуждение — http://stackoverflow.com/questions/9101818/how-to-create-a-persistent-alarmmanager.

Оказывается, что если приложение падает, или пользователь сам убивает приложение через task manager (что возможно и совершенно обычно), то ВСЕ нотификации для этого приложения в AlarmManager УДАЛЯЮТСЯ! Вот это — сюрприз! Особенно, мне понравился там один из комментариев: “Re Alarm canceled: Thanks for the clarification. I asked this on the Android team office hours g+ hangout and they even seemed confused about this behavior. Is it documented anywhere?”

Так что теперь при старте приложения мы вынуждены пересоздавать настроенные нотификации, так как даже нет API в AlarmManager чтобы проверить есть ли такие нотификации или нет.

Бывает и такое.

Вот вам еще несколько ошибок которые мы зарегистрировали у наших пользователей. В своем приложении мы используем OAuth идентификацию для различных социальных сетей и поэтому вынуждены запускать штатный браузер в Android (через который и должен работать OAuth). При этом, он периодически “падает”

Заключение

Несмотря на все вешеописанное, мне понравилась заниматься разработкой под Android. В основном API вполне продуманный и удобный.

Вот только везде стоит использовать try/catch . Даже там, где это совсем неочевидно.

Источник