|
FAT32 SHAMER posted:I was looking at AnyChart but i get What's your compile/target SDK version? AnyChart is built against 28 so it shouldn't be referencing old stuff.
|
#
¿
Jan 30, 2019 04:18
|
|
|
|
| # ¿ May 13, 2024 15:12 |
|
|
I wanna say there was a typo exactly like this in Android Studio’s starter template for build.gradle if I remember right.
|
|
#
¿
Jan 30, 2019 22:56
|
|
|
baka kaba posted:it's a good tool to learn at some point anyways 100%. This tool will save you so much time. And once you get to the bottom of the leak it's usually always something that'll make you feel really stupid, like a listener causing a referential loop, or something like that.
|
|
#
¿
May 4, 2019 22:32
|
|
|
Yeah, follow the directions in the docs to make a release signed version but don't post it to the store. You can just pass the .apk file to your friend and they can enable "install apps from unknown sources" on their phone and install it.
|
|
#
¿
Aug 15, 2019 15:55
|
|
|
https://developer.android.com/guide/navigation/navigation-deep-link#implicit Have you already looked at this? I haven't tried this but it looks like you can set URI matchers on a specific state in the navigation graph, and the toolchain will auto-generate the intent filters for the container activity accordingly.
|
|
#
¿
Oct 12, 2019 23:23
|
|
|
ringu0 posted:Unfortunately neither of these solutions is in the cards. The web services are self-hosted by the customers, so there's no single URL to package. There is a first-run state and the UI to type in the URL, but the deployment team requested a config file for mass deployment. It's an enterprise app, and we provide hardware with preinstalled software. Last time I worked on such an enterprise app, we provided the clients with the apk and instructions for the client to use apktool to re-pack it with their configuration and customization. We instructed them to sign it and distribute it themselves using their MDM.
|
|
#
¿
Jul 22, 2020 01:38
|
|
|
I work on an app with multiple packs purchasable via IAP. We control it by having a backend service that validates the IAP receipt, and another backend endpoint that dishes out the actual content if you’ve authenticated it. The app does the IAP, the receipt from Play Billing is sent to the backend. Backend calls Google’s validation endpoint to confirm it’s a legit receipt. Upon confirming the receipt is good, the service gives you back a token you can use to get the content by calling the second service. Our content is pretty small. If it were bigger I would probably suggest making a service that will trade an IAP receipt for a signed AWS S3 download link with a reasonable expiry date. Same thing then happens when you restore purchases, we call Play Billing to get all your receipts, send the lot of them to that endpoint, and get back the content. kitten smoothie fucked around with this message at 17:46 on Jan 26, 2021 |
|
#
¿
Jan 26, 2021 17:44
|
|
|
brand engager posted:What causes android 10 to automatically grant the camera permission? I have some test app that only declares uses-permission for android.permission.camera, and when I install it the camera permission is already granted. Everything I've found in the documentation says the camera permission can only be granted by asking at runtime. What version of the Gradle plugin are you using, looks like this may have been fixed in 4.2. The idea was to auto grant permissions for instrumented tests but it just granted whatever was in the manifest all the time https://issuetracker.google.com/issues/172112073
|
|
#
¿
Apr 29, 2021 02:02
|
|
|
|
| # ¿ May 13, 2024 15:12 |
|
|
Glimm posted:Of course, you could encrypt the key before sending it, but then you've got to store the decryption key in the client... Another thing you can do is use key attestation (this is different than Safetynet attestation), this works on devices that shipped with 7.0 and later. If you create a public/private keypair you get metadata in the public key certificate that gives you some important data: the application ID of the app that created the key, and the SHA256 of the app signature, so you can verify the key was created by your app. It also indicates whether the private key is in hardware and not accessible to the Android side of the house. Finally you can plant a piece of user metadata into the keypair when you create it, like a timestamp value to prevent replay attacks. That whole shebang is signed by a key burned into the hardware, which is then chained back to a Google root certificate, so you can verify that the key was actually generated on device in the hardware encryption environment, and not replaying from a previous user. So if you're okay with online access once at first load, you could create a keypair on-device, send a backend of yours the public key. That looks at attestation data, if it's good, encrypts your data blob with the public key and sends it down. At that point then you've got an encrypted data blob that can only be decrypted by that one phone because the private key to decrypt it is in hardware. This might help you with storing the data encrypted at rest (and at least only require online access at first load) but you're still going to have to decrypt it to use it at runtime. kitten smoothie fucked around with this message at 20:00 on May 15, 2021 |
|
#
¿
May 15, 2021 19:56
|
|