My Delphi project have both android 32 and 64 destination. I can deploy them on my test devices and they both works fine.
Now google forces me to upload a single app bundle file (.aab), so i flagged the "Generate Android App Bundle file (arm + arm64)" option, set up my provisioning keystore, loaded the alias and then generated that .aab file
I uploaded that as a beta release for my app from the android developer portal and after a few hours it became available to download for my test devices. But.. it shows the start up logo.. and nothing else.
I don't really know how to debug this since both the apks are working fine (32 and 64 bit), so i tried to launch adb logcat *:W, but i still cannot get useful info. I got those lines in endless loop:
10-30 09:59:21.656 13723 13723 E systems.<my app name>: Not starting debugger since process cannot load the jdwp agent.
10-30 09:59:21.688 13723 13723 W systems.<my app name>: JIT profile information will not be recorded: profile file does not exits.
10-30 09:59:21.688 13723 13723 W systems.<my app name>: JIT profile information will not be recorded: profile file does not exits.
10-30 09:59:21.703 922 1100 E ANDR-IOP: IIop:: Iop HAL Service is not available.
10-30 09:59:21.707 13723 13743 E Perf : Fail to get file list oat
10-30 09:59:21.707 13723 13743 E Perf : getFolderSize() : Exception_1 = java.lang.NullPointerException: Attempt to get length of null array
10-30 09:59:21.743 13723 13723 W linker : Warning: "/data/app/<my app name>-43xRWdYLtXcvUAbEkuUk6g==/split_config.arm64_v8a.apk!/lib/arm64-v8a/lib<my app name>.so" unused DT entry: DT_RPATH (type 0xf arg 0x2cf24) (ignoring)
Just for info: getFolderSize() is not a function i use in my code (its not even declared).
Also, i think this is pretty important: my app deploys some .so files (different files for 32 and 64 bit) and some other files, like images and fonts.
Why i think this is important? Just a suspect born reading this similar issue (but with xamarin): https://github.com/xamarin/Xamarin.Forms/issues/11450
I also tried to deploy the .aab manually on my devices but the only thing i found is how to generate the .apks file from the .aab, and i still cannot deploy it on my devices.
I'm using Delphi 10.4.1 and i also tried to recreate the .dproj file setting up everything again.
How i can debug this? Or how i can get more info about the cause?
Edit: Solved it! I had a few problems that, mixed together, caused this; i'll try to list them in case someone will have a similar issue and will end here!
my androidmanifest.template.xml file was generated by an older version of delphi and was missing some important parts
you need to include all the needed .so files in both 32 and 64bit build to actually have them in the bundle
using TPath.GetLibraryPath() when loading .so files can produce different results if you are using it inside a .aab bundle package
i was trying to load one of those .so file from the initialization section using the function TPath.GetLibraryPath() to get the root path, that was causing a unhandled exception that make my app crash into the splash screen
I solved simply removing TPath.GetLibraryPath() from the path i was using to load my .so and now it works
Related
My goal is to be able to make my Android TV Mi Box S (Oreo 8.1) transcode properly Dolby Digital+ (EAC3) sounds to Dolby Digital (AC3) and output it to, my AVR through SPDIF.
This transcodindg is possible with Kodi 18.1 applicition but is not proposed by other application or Android 8.1 settings. As Kodi is able to do it I reverse engineered Android stack. My conclusion are : - Android Oreo embeds any necessary codecs ans other stuff to do this transcoding but does not propose the settings to configure this - Android Pie proposes the wanted surround sound setting (output Dolby Digital on SPDIF)
So my goal is to backport Android TvSettings application from Pie to Oreo
I first tryed to generate TvSettings with Android Studio. I hacked the application resources but stopped when I understood that I would have to generate platfom dependacies (for instance SettingsLib.jar)
My second trial is to generate the entire Android platform. The build is complete and I can deploy TvSettings application on a x86 TV simulation BUT when I launched the TvSettings appplication I get this error :
--------- beginning of crash
2019-04-01 12:21:04.976 3987-3987/com.android.tv.settings
E/AndroidRuntime: FATAL EXCEPTION: main
Process: com.android.tv.settings, PID: 3987
java.lang.RuntimeException: Unable to get provider android.support.v4.content.FileProvider:
java.lang.ClassNotFoundException: Didn't find class
"android.support.v4.content.FileProvider" on path: DexPathList[[zip
file
"/data/app/com.android.tv.settings-2DkaCncwGQ874WP-kx3G4Q==/base.apk"],nativeLibraryDirectories=[/data/app/com.android.tv.settings-2DkaCncwGQ874WP-kx3G4Q==/lib/x86,
/system/lib, /vendor/lib]]
I searched this error on internet and it seems that it deals with multidex feature. This multidex feature is well documented for clean developped Android appliacation but nor reaally for applications extracted from Android platform and deployed with adb.
This problem is related to java libraries loading.
I found threads referring Android multidex feature but only for applications buils with Android Studio/Gradle and my app was build with Android platform
What can I do?
have you included fileProvider in your manifest?
Well there seems to be a root error during deployment of my TvSettings application. Here is its log :
E/dex2oat: Invalid version number in dex file header. File: base.apk
I read several pages and found this one very interesting : https://source.android.com/devices/tech/dalvik/configure
So, due to different optimizations, platform apps are not generated with the same file format that apps generated above platform API
My idea is to generate the whole platform including TvSettings app and to deploy TvSettings with adb. So the apk format may be wrong.
My next step is to add in TvSettings/Settings/Android.mk the flag below :
LOCAL_DEX_PREOPT := false
I'm trying to use the new Android App Bundles.
I run some test locally on my devices, and everything works correctly. However, once deployed to production, I am starting to see a few errors like this:
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/xyz/base.apk"],nativeLibraryDirectories=[/data/app/xyz/lib/arm, /vendor/lib, /system/lib]]] couldn't find "libsqlite3x.so"
java.lang.Runtime.loadLibrary (Runtime.java)
java.lang.System.loadLibrary (System.java)
io.requery.android.database.sqlite.SQLiteDatabase.<clinit> (SQLiteDatabase.java:86)
io.requery.android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked (SQLiteOpenHelper.java:241)
io.requery.android.database.sqlite.SQLiteOpenHelper.getReadableDatabase (SQLiteOpenHelper.java:199)
...
The error states that a library I'm using (requery/sqlite-android) cannot find the .so file that it needs.
This seems strange, since I checked with bundletool, and in every APK the file .so is there.
The error happens on two devices: a Samsung Galaxy Note 7 and a
TECNO-J8, running Android 6 and 5 respectively.
According to the Play Store, the error happens for app installed through Google Play, so I doubt the error is related to APK sideloading.
The generated APK bundle includes splits for the following architectures:
splits\base-armeabi_v7a.apk
splits\base-mips.apk
splits\base-arm64_v8a.apk
splits\base-x86_64.apk
splits\base-x86.apk
Do you have any hints?
Even though the installs are reported from Play, this information can easily be spoofed when using adb (which some users have learnt to do for some reason that I don't quite get yet). Those crashes very likely come from sideloads which don't install the config splits in spite of the appearances.
This issue might be related to https://issuetracker.google.com/issues/127691101
It happens on some devices of LG or old Samsung devices where the user has moved the app to the SD Card.
One way of fixing the issue is to use Relinker library to load your native libraries instead of directly calling System.load method.
https://github.com/KeepSafe/ReLinker
Another way is to block the movement of the app to the SD card or by keeping android.bundle.enableUncompressedNativeLibs=false in your gradle.properties file.
#see https://developer.android.com/guide/app-bundle/configure-base#disable_config_apks
disable bundle api split can fix this bug.
add this into your build.gradle file
bundle {
abi {
// This property is set to true by default.
enableSplit = false
}
}
I just downloaded the main Java Jar file directly from here: http://loopj.com/android-async-http/
Double-clicked the jar file and got this error message pop up:
"The Java JAR file "android-async-http-1.4.9.jar" could not be launched.
Check the Console for possible error messages."
In the console, it had the following 4 messages pop up:
4/23/16 7:34:40.805 AM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.domain.pid.quicklookd.2848) Path not allowed in target domain: type = pid, path = /Library/Frameworks/iTunesLibrary.framework/Versions/A/XPCServices/com.apple.iTunesLibraryService.xpc error = 147: The specified service did not ship in the requestor's bundle, origin = /System/Library/Frameworks/QuickLook.framework/Versions/A/Resources/quicklookd.app
4/23/16 7:34:53.261 AM QuickLookSatellite[2861]: [QL] Using too much memory (127 MB), hit critical threshold (120 MB), exiting immediately to clean up.
4/23/16 7:34:53.280 AM com.apple.xpc.launchd[1]: (com.apple.quicklook.satellite.2CBCE90F-159F-4B12-83D8-1859B1F39063[2861]) Service exited due to signal: Killed: 9
4/23/16 7:34:53.597 AM QuickLookSatellite[2879]: ImageIO: JPEG Corrupt JPEG data: 1502 extraneous bytes before marker 0xfe
4/23/16 7:34:53.600 AM QuickLookSatellite[2879]: ImageIO: JPEG JPEG datastream contains no image
For reference, I've confirmed that in my mac security, I've switched it to "allow apps downloaded from anywhere," so that shouldn't be an issue.
In addition, I suspect the last two are related to the actual image of the pop-up error (the first thing I reported)... so once the root cause is resolved, there shouldn't be a need for an error message and everything should be dandy.
How can I resolve this?
This jar file is Android library, it is not application file ==> You can not run this file.
while playing around with Android ART and the "native" code file .oat/.elf which is created at the app installation process, I did notice something odd.
For my understanding, if the device is using ART (Android >= 5.0), the app will start with the compiled oat file (/data/dalvik-cache/arm64/).
Thats why I was kinda surprised when checking the used fd's of an app and did not find the file there. Only the normal apk (/data/app//base.apk) is listed there.
Check this output of my "ls -l /proc/PID/fd"
So I thought maybe it's just not listed there. So I did exchange the oat file of that app by myself by compiling another classes.dex with the dex2oat tool.
So even after changing the file, the app starts normally without any strange messages or errors (also in logcat).
What is the explanation for this? What is the detailed process Android does when starting an app under ART?
I hope someone can clear that up for me. Thanks a lot.
Based on #Paschalis comment, I investigated here and the oat file is indeed memory mapped on Android 5.0 devices (emulator):
a6af4000-a6af9000 r--p 00000000 1f:01 7366 /data/dalvik-cache/x86/data#app#my.app.works-1#base.apk#classes.dex
Check via:
cat /proc/<PID>/maps | grep dex
Sadly this isn't true anymore for Android 6.0 devices (Nexus 5 & arm-Emulator).
The odex file is within the /data/app/<APP>/oat/<ARCHITECTURE>/ folder as 'base.odex`
/data/app/app.app.works-1/oat/arm/base.odex
I still haven't found a valid reference for this, it is based on experiments and observations
I copied the sample of Google breakpad for Android and added it to my project. I had first a problem to get the minidumps (I was triggering SIGSEGV errors but nothing was written on my SD card). I finally managed to get some minidumps (I don't really know how but that's not my main problem).
My problem is that I can't dump the symbols of my native libraries, it says the following error message :
dump_syms.exe libcppinterface.so > libcppinterface.so.sym
loadDataForPdb and loadDataFromExe failed
Open failed
Thanks for your help
The Breakpad tools are not very cross-platform friendly. You need to build dump_syms on a Linux machine in order to get a dump_syms binary that can read ELF/DWARF and produce debug symbols from your Android binaries. The Windows dump_syms.exe is only used for dumping symbols from MSVC-produced PDB files.