WAI
Status Update
No update yet.
Comments
pr...@gmail.com
i'm afraid this is not that trivial with nullable fields in the database.
right now, Room always finds 1 constructor. For this to work, we'll need to find all constructors, check which fields are null in the cursor and call the right constructor.
otherwise, calling the default one might result in Room passing null values into it when they are non-null.
right now, Room always finds 1 constructor. For this to work, we'll need to find all constructors, check which fields are null in the cursor and call the right constructor.
otherwise, calling the default one might result in Room passing null values into it when they are non-null.
am...@google.com
lb...@gmail.com
Ahh, I didn't know room used `@JvmOverloads` constructors. Neat!
lb...@gmail.com
Mentioned in the original issue, but dropping here too.
It seems you can't have nullable val properties. If I have a class with all val properties, it works fine. It complains about multiple constructors, but it doesn't fail at least
It seems you can't have nullable val properties. If I have a class with all val properties, it works fine. It complains about multiple constructors, but it doesn't fail at least
lb...@gmail.com
This fix will be available in 2.0.0 beta 2.
vi...@google.com
It will need user's consent (and screen unlocked) to enable "File Transfer" (MTP mode) for sharing storage on Android device via USB either to PC or another Android Host.
That means, unlike on-device app, all folders / files access are under user awareness, and prevent possible attack from malware in such situation.
That means, unlike on-device app, all folders / files access are under user awareness, and prevent possible attack from malware in such situation.
lb...@gmail.com
@7 This is incorrect for multiple reasons:
1. User's consent is on all permissions, and when we requested storage permission to access it too, the explanation was not about user's consent, but because of possible malware.
2. It doesn't make sense that with user's consent on the current device, it won't let the user access to the folder, but with user's consent when using USB, it will.
3. User's awareness is the same on the device as on another device. It doesn't make sense that with USB the awareness would be different.
4. User's awareness of USB has nothing to do with malware attack. The other device could have malware and the user isn't aware of it at all. You don't protect the user from malware via USB. The opposite.
5. Whatever the UX is for USB that provides enough "user's consent" and "user awareness" - it can be done without a USB too.
1. User's consent is on all permissions, and when we requested storage permission to access it too, the explanation was not about user's consent, but because of possible malware.
2. It doesn't make sense that with user's consent on the current device, it won't let the user access to the folder, but with user's consent when using USB, it will.
3. User's awareness is the same on the device as on another device. It doesn't make sense that with USB the awareness would be different.
4. User's awareness of USB has nothing to do with malware attack. The other device could have malware and the user isn't aware of it at all. You don't protect the user from malware via USB. The opposite.
5. Whatever the UX is for USB that provides enough "user's consent" and "user awareness" - it can be done without a USB too.
Description
However, this won't work at all as it's completely accessible via USB, which means that if the other side has malware, it can be accessed just like any malware app that's installed on the current device.
Please make an equal rule for both cases.
It doesn't make sense that a USB could let you reach the folder, but on the device you will be.
It doesn't make sense to give false security feeling about this folder, saying that nobody can reach it without root or special means, if it's possible to do so very easily, using a simple cable.