First, I am aware of a similar question. My situation is different and odd.
An app Foo does not directly use ExifInterface at all. It depends on libraryFoo which is included as an AAR package. libraryFoo uses ExifInterface in a fragment.
When app Foo uses the fragment and the fragment calls a method that uses ExifInterface as follows:
FileDescriptor fileDescriptor = parcelFileDescriptor.getFileDescriptor();
ExifInterface exifInterface = new ExifInterface(fileDescriptor);
exifInterface.setGpsInfo(location);
exifInterface.saveAttributes();
the app crashes:
Failed resolution of: Landroidx/exifinterface/media/ExifInterface;
java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/exifinterface/media/ExifInterface;
Adding the following to the build.gradle of the app solves the problem:
implementation 'androidx.exifinterface:exifinterface:1.3.3'
This is odd. To make this even odder, the app used to work fine without this implementation line.
Could anyone shed some light on this?
You can see that I am not seeking a solution to a problem, but an understanding of this behavior.
Related
so as I stated in the title, I am working on Laravel 5.7 project and am making first tests in this application (big system). We did not make any tests in here yet, so this problem is the first time here.
For every test, this is how the controller uses the trait
use RefreshDatabase;
protected function setUp()
{
parent::setUp();
$this->withoutMiddleware(\App\Http\Middleware\VerifyCsrfToken::class);
$this->withoutExceptionHandling();
}
As you can see, I am just trying to use the trait to refresh the DB after the tests are done.
The problem arises when I call to execute the tests.
ErrorException: Trying to access array offset on value of type int
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Input\ArrayInput.php:135
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Input\Input.php:55
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Command\Command.php:214
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Console\Command.php:170
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Application.php:886
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Application.php:262
C:\laragon\www\demi\systems\damaro\vendor\symfony\console\Application.php:145
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Console\Application.php:89
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Console\Application.php:188
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Console\Kernel.php:250
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\PendingCommand.php:136
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\PendingCommand.php:218
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\Concerns\InteractsWithConsole.php:55
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\RefreshDatabase.php:55
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\RefreshDatabase.php:18
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\TestCase.php:104
C:\laragon\www\demi\systems\damaro\vendor\laravel\framework\src\Illuminate\Foundation\Testing\TestCase.php:71
This is the whole trace.
Some solutions I found are:
composer update - not an option, because the project is in production
disable telescope package in phpunit.xml - did not work
I also tried installing telescope package - did not work as well
Do you have any idea?
So I have not found an answer to this question, but I have found a workaround.
Instead of using RefreshDatabase trait I decided to use DatabaseTransactions trait.
I'm just looking into CefSharp and am confused about NewScreenshot. I've found lots of references to it as well as example code, but none of it works. I found it marked as obsolete in the 63.0 docs...
Has NewScreenshot been removed? If so, what replaces it (how can I tell that the screen has rendered)? For my purposes a blocking (non-async) method would work fine.
Update:
Searching the source for the latest version of CefSharp I find no reference to NewScreenshot.
I started with the Minimal Example that #amaitland referred to. I made a few changes, adapting it for my use. As part of that change I moved the Shutdown() call to the program's destructor.
When I ran the project I received a mystifying error about calling Shutdown() from a thread different than the thread from which Initialize() was called.
Looking through the code I saw ScreenshotAsync and, as I wasn't (knowingly) using another thread, suspected it may be involved. I looked for another way to get my SVG image and found NewScreenshot. Which of course didn't solve my problem, which was that the GC was running my destructor in a different thread (I had no idea that could happen).
At any rate, by this time I'd shucked ScreenshotAsync for NewScreenshot which is how I ended up here.
I set a breakpoint in my handler (which I haven't included as it's never called). Here's what I hope is the relevant code. I've omitted the init code but I believe it's unchanged from the example.
public static void Main()
{
private const string url = "https://www.google.com/";
browser = new ChromiumWebBrowser();
browser.Paint += OnBrowserPaint;
browser.Load(url)
Console.ReadKey();
}
In stepping through the code in the debugger, I set a breakpoint on browser.Load(url). If I examine browser.Paint, I find errors:
Here's the tooltip for DeclaringMethod:
I have no idea if this is related to my event handler not firing, but want to point it out in the event it is involved.
I appreciate your other suggestions but feel I need to find out why an event that should be firing is not.
I'll be happy to reduce and upload the project if it will help. Oh, and thanks for your help!
Our app is crashing on Android O due to the new background execution limits. We are on Firebase version 10.2.1, which is the one that added Android O support.
Seems like an issue with Firebase? Or is there some change needed to support this on our end?
java.lang.IllegalStateException: Not allowed to start service Intent { act=com.google.firebase.INSTANCE_ID_EVENT pkg=my.package.name cmp=my.package.name/my.package.name.MyFcmIdService (has extras) }: app is in background uid UidRecord{30558fa u0a327 RCVR idle procs:1 seq(0,0,0)}
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1505)
at android.app.ContextImpl.startService(ContextImpl.java:1461)
at android.content.ContextWrapper.startService(ContextWrapper.java:644)
at android.support.v4.content.WakefulBroadcastReceiver.startWakefulService(WakefulBroadcastReceiver.java:99)
at com.google.firebase.iid.zzg.b(zzg.java:9)
at com.google.firebase.iid.zzg.a(zzg.java:72)
at com.google.firebase.iid.zzg.a(zzg.java:2)
at com.google.firebase.iid.FirebaseInstanceIdService.a(FirebaseInstanceIdService.java:23)
at com.google.firebase.iid.FirebaseInstanceIdService.a(FirebaseInstanceIdService.java:34)
at com.google.firebase.iid.FirebaseInstanceId.<init>(FirebaseInstanceId.java:31)
at com.google.firebase.iid.FirebaseInstanceId.getInstance(FirebaseInstanceId.java:47)
at com.google.firebase.iid.FirebaseInstanceId.a(FirebaseInstanceId.java:4)
at com.google.firebase.iid.FirebaseInstanceIdService.a(FirebaseInstanceIdService.java:19)
at com.google.firebase.iid.FirebaseInstanceIdService.b(FirebaseInstanceIdService.java:35)
at com.google.firebase.iid.zzb$zza$1.run(zzb.java:24)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
Update Upgrading to 11.4.2 resolves this issue.
#KaMyLL is right. I had the same issue with our app and could solve it by replacing the IntentService (which we have started within onTokenRefresh()) with an JobIntentService.
Because I found the JobScheduler and JobIntentService docs a bit confusing, I would like to some everything up with some code snippets. I hope this makes everything clear to everyone having this issue.
What is causing this issue?
Due to the new Background Execution Limits of Android 8, you should not start background services anymore when the app could be in background:
While an app is in the foreground, it can create and run both foreground and background services freely. When an app goes into the background, it has a window of several minutes in which it is still allowed to create and use services. At the end of that window, the app is considered to be idle. At this time, the system stops the app's background services, just as if the app had called the services' Service.stopSelf() methods.
And also:
In many cases, your app can replace background services with JobScheduler jobs.
So for Android 7.x and below, using startService() when the app is in background is (as far as I know) no problem. But in Android 8, this results in a crash. In consequence, you should use a JobScheduler now. The behavioral difference between JobScheduler and an IntentService is that an IntentService is executed immediately. On the other hand, a job enqueued to a JobScheduler is not guaranteed to be executed immediately. The Android OS will determine when there is a good point of time to do so in order to be more energy efficient. So there might be a delay. And I have no idea so far how long this could take.
So one solution could be to check the OS version and branch your code using if-else. Fortunately, the support library helps us to solve this in a more elegant way without duplicating any code: JobIntentService, which basically does this for you under the hood.
How to reproduce the issue?
The first quote above states that the app still "has a window of several minutes in which it is still allowed to create and use services.", so in order to reproduce and debug the issue (with the example of onTokenRefresh() in Firebase), you could set a breakpoint before your start your service with startService(). Close the app and wait there for 5-10 minutes. Continue the execution and you will see the IllegalStateException from this question.
Being able to reproduce the issue as fundamental to make sure that our fixes really solve the problem.
How to migrate my IntenService to JobIntentService?
I use FirebaseInstanceIdService.onTokenRefresh() as an example:
a) Add the BIND_JOB_SERVICE permission to your service:
<service android:name=".fcm.FcmRegistrationJobIntentService"
android:exported="false"
android:permission="android.permission.BIND_JOB_SERVICE"/>
b) Instead of extending from IntentService, simply extend from android.support.v4.app.JobIntentService, rename the onHandleIntent(Intent) method to onHandleWork(Intent), and add a enqueueWork(Context, Intent) convenient function:
public class FcmRegistrationJobIntentService extends JobIntentService
{
// Unique job ID for this service.
static final int JOB_ID = 42;
// Convenience method for enqueuing work in to this service.
public static void enqueueWork(Context context, Intent work) {
enqueueWork(context, FcmRegistrationJobIntentService.class, JOB_ID, work);
}
#Override
protected void onHandleWork(#NonNull Intent intent) {
// the code from IntentService.onHandleIntent() ...
}
}
c) Start the job using the enqueueWork() convenient function:
public class ComfyFirebaseInstanceIdService extends FirebaseInstanceIdService {
#Override
public void onTokenRefresh() {
Intent intent = new Intent(this, FcmRegistrationJobIntentService.class);
// startService(intent);
FcmRegistrationJobIntentService.enqueueWork(this, intent);
}
}
I hope this example is helpful. At least after following these steps, I was not able to reproduce the issue on my Android 8 device anymore, and it continues to work an my Android 7 device.
Update
as FirebaseInstanceIdService deprecated we should remove this from the code, and use onNewToken from FirebaseMessagingService instead.
I've done some research about it and the best option is to transform IntentService into JobIntentService available in app compat library. It would behave like IntentService on all pre-Oreo devices. On Android 8 and above it will enqueue job to android system JobScheduler. This job by default have set deadline parameter to 0, so theoretically it should fire as fast as possible.
as of today (26/10/2018), FirebaseInstanceIDServie isdeprecated, try this to fix the above issue link
I have an object accessible via a static var in a struct (workaround for the lack of class variable support in swift right now), structured like this:
struct Constants{
static var myObj = MyObject()
}
MyObject has a dictionary in it like so:
class MyObject{
private var params = Dictionary<String,AnyObject>()
func addParam(key:String, value:AnyObject){
params[key] = value
}
}
Now on the first call to this object for Contants.myObj.addParam("param", value:123) all is well and params has contents ["param":123]. On the second call for Contants.myObj.addParam("param", value:456), I get a EXC_BAD_ACCESS.
Here's the kicker though, this only occurs in iOS 8.1. Also, if I add the line let stupidHack = self.params as the first line of my addParam method, it works fine. My assumption is that it deals with mutability of dictionaries. The let may somehow trigger the dictionary to be mutable again after initialization.
Has anyone else run into this issue before? Any idea on how to fix it?
Thanks!
Looks like a compiler bug.
Have you tried switching between Release and Debug then rebuilding? If debug works but not release it can be an indication of a compiler/optimizer bug.
Does it happen in the simulator also?
Your code works for me on iOS 8.1 with XCode 6.1.
By chance, do you have an iPhone 6 with 64Gb ?
I have one and I had the same issue using Dictionaries twice.
In the news (well the tech news ...), I read that the defective memory modules delivered by Toshiba for precisely this iPhone model could cause incorrect allocations in memory.
Try adjusting the Swift compiler optimization level to "None" (Build Settings).
I had a similar issue with a class being deallocated for no apparent reason, it is mostly a compiler bug like Lee said.
Faced similar kind of issues with swift code and fixed such issues by disabling swift compiler optimisation in the build settings of the application target.
Regularly during my application run, I get
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::SystemManager/stageEventHandler()[C:\autobuild\3.4.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:5649]
This is the full stack trace. Obviously, I guess there is something wrong, but I can't understand what.
Is there any way for me to find the origin of that bad behaviour ?
EDIT
Having added my SDK sources to my debugger, I can now say precisely which line it is :
private function stageEventHandler(event:Event):void
{
if (event.target is Stage)
mouseCatcher.dispatchEvent(event); // This is line 5649
}
mouseCatcher is indeed null. The current event target is indeed a Stage object, and event type contains the "deactivate" String. As event occurs at application startup (before I try to do any kind of user interaction), I guess it's a kind of initialization bug, but where ? and why ?
Look at the source code, this is always your best option. The 3.4 SDK is open source (datavisualization and the flash player itself aside) and you probably already have the source for it in your FlashBuilder/FlexBuilder install/sdks folder. Use grep or windows grep to find the file in question (or find, whatever floats your boat). Open the SystemManager file and check what's happening at that line, check for calls to the method (if it's public use grep again, if it's private you just need to look within the SystemManager). Try to understand why it gets to this point, as pointed out by some others it's likely a timing related issue where you're trying to access something before it has been assigned, in this case the SystemManager, you probably need to defer whatever action you're taking that is causing the error to a later part of the life-cycle (if you're using initialize event or pre-initialize try on creationComplete instead since that will be dispatched after the createChildren method is called).
Note: Mine is located here
C:\CleanFS\SDKs\flex\3.4.0.9271\frameworks\projects\framework\src\mx\managers
In my copy of SystemManager with the version of the SDK I have that line number doesn't make any sense since it's a block closure not an executable line so you'll have to look at your specific version.
It looks like you are using the Flex 3.4 SDK. Are you listening for the ADDED_TO_STAGE event when the application loads? Or doing anything with the Stage object on load? If so, you might be hitting a bug specific to the 3.4 SDK:
http://bugs.adobe.com/jira/browse/SDK-23332
The most obvious solution is to swap out the 3.4 SDK for a later version (3.4A, 3.5 or 3.6). You can do that here: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
All of your code should be backwards compatable with the newer Flex 3 SDKs.