About the author
There's an issue with the logging mechanism in FireMonkey I don't like, and that's the tag that was used when you make a call to the Log method of the IFMXLoggingService service that is returned by TPlatformServices.Current.SupportsPlatformService.
The Log call is implemented by TAndroidLoggerService.Log in the FMX.Platform.Logger.Android unit and it calls LOGI in the Androidapi.Log unit, and the LOGI routine then calls the __android_log_write function which then goes to the underlying operating system of Android.
Unfortunately, in my opinion, it appears that the R&D staff wrote the code wrongly. The call to __android_log_write is made like this:
__android_log_write(android_LogPriority.ANDROID_LOG_INFO, 'info', Text);
From the definition of function:
__android_log_write(Priority: android_LogPriority; const Tag, Text: MarshaledAString): Integer; cdecl; external AndroidLogLib name '__android_log_write';
we can see that the first parameter is supposed to be the log priority, and the LOGI call uses ANDROID_LOG_INFO, which is correct. The next one is supposed to be Tag, and that's where the R&D staff got it wrong. This is supposed to be defined by the application, but is instead hardcoded as 'info'.
This makes the default IFMXLoggingService useless, because when you're using multiple Android applications developed using FireMonkey, you can't filter out the logs from your application like so:
adb logcat -s MyTagName
or
adb logcat -s info
as the R&D staff intended you to.
I have developed a new unit as well as a demo project on Github, that demonstrates how to fix this.
How to free more space on your home drive by redirecting the location for SDKs in RAD Studio
Learn the command line used to compile System.pas in Delphi
A method to design records so that they're allocated on a specific byte boundary, such as 16 bytes, 512 bytes, 4096 bytes, etc.
Learn why the map is cool in Go!