I want to transplantation Faster RCNN to Android device, and I meet some problems.
I build my Android project by Bazel, just like the tensorflow demo. I add the op roi_pooling_op.cc and proposal_op.cc to user_ops, but I seems Android does build user_ops, the logcat shows as following:
tensorflow_inference_jni.cc:146 Could not create TensorFlow graph: Not found: Op type not registered 'RoiPooling'
I try to solve this problem, and I move roi_pooling_op.cc and proposal_op.cc to jni folder(maybe it is a bad ideal), the previous error is disappeared, but I meet another problem, outputs are all not found, I do not know why, logcat as following:
tensorflow_inference_jni.cc:170 Output [rois] not found, aborting!
tensorflow_inference_jni.cc:170 Output [bbox_pred/bbox_pred] not found, aborting!
tensorflow_inference_jni.cc:170 Output [cls_prob] not found, aborting!
I do not know how to solve them and I to debug, could you help me.
Thanks in advance!
Is there an output index on these nodes, perhaps? E.G. "rois:0" or "rois:1".
If you add a log line for node names/types to stat_summarizer.cc in the constructor you can see what nodes are defined in your graph which might illuminate the problem.
Adding the ops to the jni directory as you've done should work fine as a quick and dirty solution, and it seems to have done so if it got you past your initial problem.
Related
Unfortunately I came across this issue quite often already.
In my Android project I am using databinding to bind classes to my xml layouts which works fine. Basically I am doing it the following way:
<layout xmlns:android="http://schemas.android.com/apk/res/android">
<data>
<variable name="myClass" type="com.somepackagename.myClass" />
</data>
</layout>
Throughout my (quite large) project, i am frequently using the same variable name for many different xml layouts.
After doing a lot of refactoring, I can now no longer build my project due to the following build error:
e: error: Cannot resolve type 'myClass'
e: error: cannot generate view binders android.databinding.tool.util.LoggedErrorException: failure, see logs for details.
Cannot resolve type 'myClass'
at android.databinding.tool.util.L.printMessage(L.java:134)
at android.databinding.tool.util.L.e(L.java:107)
at android.databinding.tool.expr.Expr.getResolvedType(Expr.java:386)
at android.databinding.tool.expr.ExprModel.lambda$resolveTypes$1(ExprModel.java:618)
...
While the errorMessage is clear to me and tells me which variable name is causing this issue, unfortunately it is not very verbose and does not tell me:
which xml file causes this problem
which specific type causes this problem
This makes it extremely hard to find the causing issue if you've changed many xml layout.
Isn't there a better way to debug such errors?
After spending many hours, I finally found out what was causing the issue.
I found a way to debug such errors in a way that one should always find the issue relatively quickly. The setup however for this takes quite a few steps though:
First of all, I want to thank the author of this excellent article who gave me a good idea where to start:
https://medium.com/#dzolnai/debugging-a-databinding-compiler-error-9510f88f4cec
Based on the above article, here is how you should be able to find the causing error quickly.
Add a new configuration in Android Studio: Edit → Run configurations. Give it an arbitrary name, for instance DatabindingDebugging and click OK (i.e. nothing should be changed)
In a terminal window execute: ./gradlew assembleDebug --no-daemon -Dorg.gradle.debug=true -Dkotlin.compiler.execution.strategy="in-process" -Dkotlin.daemon.jvm.options="-agentlib:jdwp=transport=dt_socket\,server=y\,suspend=n\,address=5005". The build should print > Starting Daemon. I.e. it waits until you debug.
Back in Android Studio, on the top section your new configuration DatabindingDebuggingshould be selected. Click the green debug icon Debug DatabindingDebugging or press Ctrl + D
The debug window should now launch and indicate something like Connected to the target VM....
In the meantime, back in your terminal window, the gradle build should now execute as usual.
In the debug window in Android Studio, manually add a new Breakpoint: Click ViewBreakpoints (red icon with 2 dots). In the Breakpoints window add a new Breakpoint by clicking the + icon on the top left and select 1. Java Method Breakpoints
In the pop up enter the following:
Class pattern: android.databinding.tool.util.L | Method name: printMessage and click OK.
Make sure that both the Enabled and Suspend checkbox are checked. Also make sure to check the Condition checkbox and enter the following expression: kind.name.equals("ERROR"). This way we instruct the debugger to only suspend if the databinding tool prints a log message with an error.
Click Done.
At some point during your build, if you have a databinding ERROR, a breakpoint should be reached. In the debugger you should now see the exact error message the logger printed: Cannot resolve type 'someType'
Now scroll down the Stacktrace on the left pane of the debug window and click the entry getResolvedType:386, Expr. On the right pane you should now see the causing type for the error: this.mUserDefinedType = "com.somepackagename.myClass".
The final step is easy. Using Android Studio, simply search for this class, for instance using: Edit → Find → Find in Path → "com.somepackagename.myClass". On the right side of the window, select File mask: *.xml You should now see all xml files that caused the issue.
Hope this helps someone in the future. Still IMO this is way to complicated. If anyone knows a better way to debug such issues, please let me know :)
I have a problem with my layout text code. Instead of displaying the code I wrote, it shows a bunch of weird symbols like :
"IHDR 0 0 �1
I thought this issue had to do with the file encoding, but I changed the global encoding to UTF-8 and still doesn´t show the code I wrote.
All suggestions are welcome. Thanks in advance.
Late answer but it will help others:
You need to delete catches folder located in:
C:\Users\user\.AndroidStudio3.5\system\caches
Make sure android studio is closed before you delete, then after deletion you can launch it and it creates a new catch folder that solves your problem,
I added this line to my strings.xml, and it wont compile into R.
<string name="cl_txt_verinfo">List Version: %1$s\nAuthor: %2$s\nDate Created: %3$s\nLanguage: %4$s</string>
the errors i get are:
error: Multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?
error: Unexpected end tag string
I want to ask how to make this work(i will use string.format later)
and what does "formatted=false" do as opposed to not adding it/add it as true.
Edit:
Clean and build is how I got this error. I got it so many times.
But then I deleted an empty line and clean and rebuild everything is fine.
This is really inconsistent and i have no idea what's causing the problem in the first place.
Two questions left:
Could someone still tell me what difference would "formatted=false"
make?
How did I got this kind of behavior?(reporting error when there's none and i try to fix it by blowing things up and create a mess)
This is not the only time i had an error then it magically fixes itself. sometime i restart my adt and it resolves itself, but not this time sadly.
If you added formatted=false then format specifiers(%,$ etc.) in your string resource are disabled and Formatter won't be able to recognize them. This will definitely help you.
For your 2nd problem there is no exact solution but what I do is delete gen and bin folder and then clean build project. What happens is every time you build a project, android checks if there is any new resource available and adds it to R.java and only after that you can use it.
I need to modify a so inside an Android APK.
The task is to rename the dynamic symbols in side the so (which is the function name).
For example, change from Java_com_example_abc_.... to Java_com_yahoo_zzz_....
I try to use WinHex directly search and replace text words, the apk startup error.
Seems like the .hash section also needs to be updated, but i do not know how to update the .hash section.
My question is what is the correct or preferable way to rename the dynamic Symbol?
I heave been stuck for 3 days, please help me, thank you very much!
Found a post might related, but he didn't gave the alternative solution.
https://sourceware.org/ml/binutils/2006-03/msg00266.html
I heave been stuck for 3 days, please help me,
What you are trying to achieve is effectively impossible.
ELF files have complicated internal structure, and what you want to do requires that you break it up and re-assemble the parts. An analogy would be to break an Intel CPU into transistors and re-assemble an AMD CPU from them.
Found a post might related
It is related. Quote:
Basically it does the following:
loop over .dynsym and re-create .dynstr
re-create the .hash table from scratch
calculate new lma/vma, new memory layout (.dynstr size changed!)
fix the contents of .dynamic, according to the new layout
fix .rel.dyn
fix .rel.plt
fix .dynsym again
write out the new section contents
In copy_section: exclude the rewritten sections from being copyied.
Currently it seems to create a syntactically valid ELF file, but as
the distance between .plt and .got changes, the relative addressing in
.plt is broken. Additionally the .got has to be fixed again.
So the author managed to glue together something that looks like an AMD CPU, but which doesn't work.
Sure, you can spend another 2 weeks to understand what the author did, and then another 3 weeks to fix the remaining broken pieces. And after that, you may get something that kind of sometimes works.
Your time is likely better spent elsewhere.
Have a look at LIEF, but try to keep them the same length
native_lib = 'my_native_lib.so'
lib = lief.parse(native_lib)
for x in lib.exported_symbols:
if x.name == 'Java_com_example_abc':
x.name = 'Java_com_foobarr_zzz'
lib.write(native_lib) # overwrite
The ability to change names in shared libraries was added in Patchelf: https://github.com/NixOS/patchelf/commit/da035d6acee1e5a608aafe5f6572a67609b0198a
It should be available in the next release (after 0.17.2). Meanwhile you can build the tool following the instructions in https://github.com/NixOS/patchelf#compiling-and-testing
To use it, create a map file with two names (old and new) per line, and invoke Patchelf with:
$ patchelf --output libPatched.so --rename-dynamic-symbols map_file libOriginal.so
Please provide feedback if you find issues. Thanks!
I'm working on one of my android widgets, which uses LauncherPlus to add scrolling functionality, and am running into a frustrating issue. My currently published version of the code, again using LauncherPlus, is working well, scrolling and all. I'm adding a requested feature, one which allows changing text sizes, but an exception is thrown when I test the update. There exception is:
mobi.intuitit.android.widget.SimpleRemoteViews$ActionException: can't find view:0x7f070041
I haven't changed anything in the layouts and the only code change references a view id which was already referenced in that same section of code. I looked through the R.java and found which resource was referred to and again, nothing has changed there. Here's the bit of code where the issue is coming from:
itemViews.setBoundBitmap(R.id.profile, "setImageBitmap", SonetProvider.SonetProviderColumns.profile.ordinal(), 0);
itemViews.setBoundCharSequence(R.id.friend, "setText", SonetProvider.SonetProviderColumns.friend.ordinal(), 0);
itemViews.setBoundCharSequence(R.id.created, "setText", SonetProvider.SonetProviderColumns.createdtext.ordinal(), 0);
itemViews.setBoundCharSequence(R.id.message, "setText", SonetProvider.SonetProviderColumns.message.ordinal(), 0);
The exception is thrown when applying the first line. Out of curiosity, I changed the order of these lines, and each one of them will cause the exception, though again, the layout hasn't changed. After the exception is thrown the widget will build successfully, but I can't publish this update with an exception (force close) being thrown. Any ideas why there is a resource issue? Thanks!
UPDATE:
I found this discussion where it seems that widget resources may not be reloaded on application updates:
http://groups.google.com/group/android-developers/browse_thread/thread/55a8e44974e8c6ad?fwc=1&pli=1
Does anyone have any experience with this, or a workaround? This may be what I'm facing.
Use Project > Clean in Eclipse or ant clean from the command line, then try again. Since resource IDs are integers, they are inlined in the bytecode of the classes that reference them, and so sometimes your pre-compiled classes can get out of sync with new resource IDs from a fresh compile. I work from the command line mostly, and I always tack clean onto my ant commands (e.g., ant clean install) to avoid this problem.