just noticed in my reasoning threads that seemingly its favorite word is now "hmm": Hmm!!! What is that 1? Hmm — it could be the has_value/nullable marker for the MQDescriptor parameter! For in MQDescriptor q (non-null), the NDK client writes writeInt32(1) before q.writeToParcel(). Hmm — OR it's the transaction's "argument count" or a stability marker. Hmm! Hmm — hold on!!! Actually, I bet this is the STABLE AIDL "parcelable presence" marker for method parameters. Hmm. Hmm — OR!!! It could be AParcel_writeInt32(parcel, 1) for a "bool" or for _aidl_version. Hmm. Hmm! Hmm — interesting! So the nhenv size envelope is the problem when combined with the marker. Hmm. Hmm — and mk=1 fd=0 nhenv=1 worked (marker + envelope + no fd). Hmm. Hmm — so: marker + envelope + fd → throws. Hmm. Hmm — and mk=1 fd=1 nhenv=0 throws too (marker + fd + no envelope). Hmm. Hmm! So marker + fd = throws, regardless of nhenv. And marker + no-fd + envelope = OK. Hmm — so mk=1 fd=0 nhenv=0 threw but mk=1 fd=0 nhenv=1 worked?! That's odd. Hmm — mk=1 fd=0 nhenv=0: writes [1][count=4][4 grantors][1][count=0][ints=0][q][flags] with NO nh size field. Hmm. Hmm — and mk=1 fd=0 nhenv=1: [1][count][4g][1][size][count=0][ints=0][q][flags]. Hmm. Hmm — both have no fd. But nhenv=0 throws and nhenv=1 works?! Hmm — the parcel SIZE differs by 4! Hmm. Hmm — AH!!! THE PARCEL SIZE MUST BE A MULTIPLE OF 8? or the object array... Hmm — with marker, total = 4(token?) ... hmm. Hmm — OK, the pattern: mk=1 works ONLY for (fd=0, nhenv=1). Hmm. Hmm — and mk=0 works for ALL. and now i cant get that damn song out of my head   submitted by   /u/gaspoweredcat [link]   [comments]