Status Update
Comments
fe...@gmail.com <fe...@gmail.com> #2
And as far i can tell, this is happening because createFromParcel in generated code returns Object instead original Class
vi...@google.com <vi...@google.com>
al...@gmail.com <al...@gmail.com> #3
This is not Android issue. Kotlin is responsible for generating the Parcelable implementation.
Report this in Kotlin issue tracker:
vi...@google.com <vi...@google.com> #6
ra...@gmail.com <ra...@gmail.com> #7
Just checked that this is fixed in Kotlin 1.5.10 and the code probably also worked in several earlier versions.
For some background, this was an issue with the old JVM backend, which was fixed Robert Bares
ld...@gmail.com <ld...@gmail.com> #8
mi...@gmail.com <mi...@gmail.com> #9
sh...@google.com <sh...@google.com> #10
This issus is still exists in the Kotlin version 1.7.10
lv...@gmail.com <lv...@gmail.com> #11
I cannot reproduce the issue with Kotlin 1.7.10.
One inconsistency that I noticed is that Android Studio displays an error on createFromParcel
calls in the java files generated from AIDL. This seems to be purely cosmetic, since the generated code contains the correct generic types, both with the old and current Kotlin compiler backend.
Is this the issue that you're seeing or do you have a project that fails to compile? If so, would it be possible to share a reproduction?
gc...@google.com <gc...@google.com>
hi...@gmail.com <hi...@gmail.com> #12
Here's what's going on with the error that the Java editor displays on the AIDL generated files:
IntelliJ has a way of resolving usages of Kotlin classes in Java code without compiling the code first, called UltraLightClasses
. The Parcelize plugin ships an extension to UltraLightClasses
with the Kotlin plugin in IntelliJ (!) and this code has CREATOR
fieldCREATOR
field has the raw type Parcelable.Creator
and hence that createFromParcel
returns results of type Object
. Meanwhile the compiled code contains the correct generic types and in particular the Java compiler sees the correct types.
In summary, this is a purely cosmetic problem, the actual code is correct and it is only the editor display in the IDE that's broken.
I'm going to fix this, but please speak up if you encounter any issue that is not cosmetic and results in build or runtime errors, because that would be a different issue.
Description
Key idea: allow user, after giving explicit consent in settings dialogue to enter alternative pin/password for unlocking the device, that is intended to unconditionally wipe the data from the device. The reasoning behind is to keep user in control of his or her data even when being opposed by criminals or corrupt government officers.
This would require additional menu item in settings, legally-proven additional consent screen, screen to enter the panic password, and a backend engine that resets the device to factory settings.
It's understandable that this feature would require significant engineering effort and may not fit into the current priorities of the development team, so the key questions in this issue are:
1. Does this feature fits into google's vision of user's security model? (If not, why not?)
2. Is there any chance that this will be implemented by google?
3. Will you accept pull requests/patches if this will be implemented by community?