The project is managed by GIT. After gradle is packaged, APK can be used. After a class is updated and repackaged, this exception will be reported in the running process of APK.
I compared APK, only classes2.dex file size is inconsistent, other files are the same.
Why does this exception appear?
Best Answer
O
Olivier @MyScript
said
almost 4 years ago
Dear Lingyun,
currently, on our side we did not notice any significant dfference in recognition speed in between our different releases. The problem may be in your implementation, and without your project, it is difficult to understand if there is anything wrong.
Please note the 1.2.2 release is 3 years old, and no support will be brought to the latter. Ensure you properly update to the 1.4.1 release ; if you need more help from, please provide us with a project that allow to reproduce.
currently, on our side we did not notice any significant dfference in recognition speed in between our different releases. The problem may be in your implementation, and without your project, it is difficult to understand if there is anything wrong.
Please note the 1.2.2 release is 3 years old, and no support will be brought to the latter. Ensure you properly update to the 1.4.1 release ; if you need more help from, please provide us with a project that allow to reproduce.
Best regards,
Olivier
L
LINGYUN GUAN
said
almost 4 years ago
Our customers can't accept the recognition efficiency of version 1.4.1. Before version 1.3.1, the recognition speed was very fast, but the recognition speed of version 1.4.1 was obviously slower. When I returned version 1.2.2, I continued to report this exception on some machines. 1.4.1 is there any optimization? Can we send another version of the package to solve the problem of recognition speed?
O
Olivier @MyScript
said
almost 4 years ago
Dear Linugyun,
Thank you for the update.
There was probably a mis-alignment in between the JAVA and native. The important is that the issue is solved.
Let us know if you need any other help.
Best regards,
Olivier
L
LINGYUN GUAN
said
almost 4 years ago
The code cannot provide... Moreover, it is related to the environment and cannot be reproduced by a single demo
L
LINGYUN GUAN
said
almost 4 years ago
I upgraded Iink and deleted the configuration of Tinker. Later, the problem would not appear
But I don't know why
O
Olivier @MyScript
said
almost 4 years ago
Dear Lingyun Guan,
Thank you for contacting us and your question.
Currently, the "internal error" is a generic error, which can have many causes. From this, you understand we need more information to help you:
-Did it occur suddently?
-Did you do any change? Which ones?
-Do you have a log/stacktrace that would help us?
-Is it possible to have access to your code?
Also, you mentionned your application was based on the iink 1.2.2. Please note the latter is no longer supported, and you shall then update to the latest 1.4.1 release.
Best regards,
Olivier
L
LINGYUN GUAN
said
almost 4 years ago
iink1.2.2
When I add some code to the class and repackage it, iink can actually work?
LINGYUN GUAN
The project is managed by GIT. After gradle is packaged, APK can be used. After a class is updated and repackaged, this exception will be reported in the running process of APK.
I compared APK, only classes2.dex file size is inconsistent, other files are the same.
Why does this exception appear?
Dear Lingyun,
currently, on our side we did not notice any significant dfference in recognition speed in between our different releases. The problem may be in your implementation, and without your project, it is difficult to understand if there is anything wrong.
Please note the 1.2.2 release is 3 years old, and no support will be brought to the latter. Ensure you properly update to the 1.4.1 release ; if you need more help from, please provide us with a project that allow to reproduce.
Best regards,
Olivier
- Oldest First
- Popular
- Newest First
Sorted by Newest FirstOlivier @MyScript
Dear Lingyun,
currently, on our side we did not notice any significant dfference in recognition speed in between our different releases. The problem may be in your implementation, and without your project, it is difficult to understand if there is anything wrong.
Please note the 1.2.2 release is 3 years old, and no support will be brought to the latter. Ensure you properly update to the 1.4.1 release ; if you need more help from, please provide us with a project that allow to reproduce.
Best regards,
Olivier
LINGYUN GUAN
Our customers can't accept the recognition efficiency of version 1.4.1. Before version 1.3.1, the recognition speed was very fast, but the recognition speed of version 1.4.1 was obviously slower. When I returned version 1.2.2, I continued to report this exception on some machines. 1.4.1 is there any optimization? Can we send another version of the package to solve the problem of recognition speed?
Olivier @MyScript
Dear Linugyun,
Thank you for the update.
There was probably a mis-alignment in between the JAVA and native. The important is that the issue is solved.
Let us know if you need any other help.
Best regards,
Olivier
LINGYUN GUAN
The code cannot provide... Moreover, it is related to the environment and cannot be reproduced by a single demo
LINGYUN GUAN
I upgraded Iink and deleted the configuration of Tinker. Later, the problem would not appear
But I don't know why
Olivier @MyScript
Dear Lingyun Guan,
Thank you for contacting us and your question.
Currently, the "internal error" is a generic error, which can have many causes. From this, you understand we need more information to help you:
-Did it occur suddently?
-Did you do any change? Which ones?
-Do you have a log/stacktrace that would help us?
-Is it possible to have access to your code?
Also, you mentionned your application was based on the iink 1.2.2. Please note the latter is no longer supported, and you shall then update to the latest 1.4.1 release.
Best regards,
Olivier
LINGYUN GUAN
iink1.2.2
When I add some code to the class and repackage it, iink can actually work?
What's the situation?