Regarding the issue of being unable to attach log files that contain some sort of as yet undetermined type of content: I’ve gotten the test log file down to 12 lines, and it seems that pasting it into a in-line code formatted section of a post here will allow someone else to copy the text and save it as txt... but the way the file is handled matters to maintaining the offending material for purposes of sharing it. More about, and the method used below the code section. File is alos in attached zip file which as previously shared (thanks) also preserved the format.
12-09 11:42:35.111 E/fpc_tac (20473): Unable to open '/sys/devices/platform/soc/601b000.cti/modalias'
12-09 11:42:35.181 I/EventHub(2109): New device: id=257, fd=258, path='/dev/input/event7', name='uinput-fpc', classes=0x1, configuration='/system/usr/idc/uinput-fpc.idc', keyLayout='/system/usr/keylayout/uinput-fpc.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=true,
12-09 11:42:35.181 W/InputReader(2109): Ignoring spurious device added event for deviceId 0.
12-09 11:42:35.275 D/LMT::LMT(20454): Starting GUI
12-09 11:42:35.701 E/fpc_hidl(20473): Can't initialize the fingerprint HAL module !!!
12-09 11:42:35.710 D/ICU (20486): Time zone APEX file found: /apex/com.android.tzdata/etc/icu/icu_tzdata.dat
12-09 11:42:35.725 I//system/bin/app_process(20486): The ClassLoaderContext is a special shared library.
12-09 11:42:35.746 W//system/bin/app_process(20486): JNI RegisterNativeMethods: attempt to register 0 native methods for android.media.AudioAttributes
12-09 11:42:35.799 D/AndroidRuntime(20494): >>>>>> START com.android.internal.os.RuntimeInit uid 0 <<<<<<
12-09 11:42:35.804 I/AndroidRuntime(20494): Leaving lock profiling enabled
12-09 11:42:35.813 I/WindowManager(2109): SURFACE show Surface(name=Toast)/@0xfae71c1 on display:0: Toast
12-09 11:42:35.899 I/LaunchCheckinHandler(2109): Displayed com.noname81.lmt/.LMT,cp,ca,876
The initial file was a log captured by the app matlog while testing the app LMT and was several hundred lines long. At first, dividing it in sections would produce one bad section and one good section but by the time it was down to 62 lines splitting the file just about anywhere would result in two good pieces. At that point I semi arbitrarily deleted a few lines at a time which contained only “regular” characters (standard english alphabet, 0 through 9, and basic punctuation). By the time the file was down to 12 lines (as it is here) it seems that dividing it anywhere results in two good pieces. Whatever the problem is it's in this chunk somewhere and touching any of several parts of the file impacts it.
As to possible causes, after seeing the file with the visible code marks a I don't think mutually dependent paragraph markers and other such tandem things could carry through to the 12 line section with which the issue can be reproduced so hypothesis 1 is in the dustbin.
Also this does not seem entirely consistent with a filter being applied to a specific character or even a specific string of text. Could it be possible that a reputation service is contextually analyzing text and blocking it based on a general comparison, and that in the case of this 12 line section the match in that comparison is broken by removing any individual line?
As to preserving the offending material for sharing and testing, in my case, on a windows 10 PC with notepad as text editor and Firefox as browser, if the text from the code section is copied and pasted into a txt document in notepad and then saved, it should still induce the issue. If it might very well do so with other editors and browsers if the format is not changed but that's what I'm using.
, we have you covered.
