Related
I'm writing an article on the Nexus 7 and Jelly Bean, and I wonder if someone with more coding knowledge could help me out with something.
I'm wondering why so many apps are listed as "incompatible" with the Nexus 7. Is it the device configuration, or something to do with the way the apps are coded? Why would an app like NBA JAM work on a Galaxy Nexus but not a Nexus 7?
I think it's the default screen DPI value screwing things up.
Sent from my Galaxy S III
TheBiles said:
I think it's the default screen DPI value screwing things up.
Sent from my Galaxy S III
Click to expand...
Click to collapse
That would cause apps to be listed as "incompatible" in the Play Store?
How can developers make apps more widely compatible? Shouldn't the Android SDK responsive design features take care of that?
Thanks!
A lot of the applications that are listed as incompatible are in fact compatible if side loaded onto the device, bypassing the Play Store.
I don't want to assume you are new to Android but usually within 2-4 weeks of a new Android OS launch, more applications will become compatible in the Play Store.
Nexcellent said:
A lot of the applications that are listed as incompatible are in fact compatible if side loaded onto the device, bypassing the Play Store.
I don't want to assume you are new to Android but usually within 2-4 weeks of a new Android OS launch, more applications will become compatible in the Play Store.
Click to expand...
Click to collapse
I've been a Nexus user for a few years now, so I know that eventually apps will be updated, although it's always pretty annoying in the beginning. I'm just trying to understand better what developers have to do in order to make apps compatible with new devices and new versions of Android.
Many also show incompatible (such as Amazon) because they require a rear camera. They work fine when sideloaded (as mentioned above) but force close when trying to access the camera.
There's a build property for "highest version of android that this app will work for". Google advises against using it in the documentation, but a lot of devs set the max version to ICS anyway. Expect it to be corrected as more people get JB
Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.
g313 said:
Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.
Click to expand...
Click to collapse
You're right about bitmap memory management (I had an infinite System UI FC on CM 11 when I got too many notifications (from YouTube, by the way)
Sent from my GT-S7580 using Tapatalk
i want to run marshmallow apps on jellybean 4.1.2
g313 said:
Hello
Asking all developers to start a discussion on what the minimum API level is that you support, and have you decided to drop support for older APIs and if so what the reasons are. The reason for starting this discussion comes from the frustrations caused by having to support older API levels. Yes it's important to support as many users as possible - not everybody has access to the latest and greatest devices / Android versions, my own day to day device is a Samsung Galaxy S6 with Android 6.0.1. Although I have access to a device with Android 7.1 and one with Lollipop. However there is only so far back you can go in terms of support before development starts to get frustrating and in the end the question has to be asked if it is really worth it.
Please first take a look at https://developer.android.com/about/dashboards/index.html for the latest device stats.
For some background, I'm the developer of this app http://forum.xda-developers.com/android/apps-games/quick-gallery-photo-editor-t3394976 and https://play.google.com/store/apps/details?id=com.mobato.gallery. Currently min API 16 is supported, but I am thinking of making this 19 (KitKat), or dropping JellyBean support all together and just supporting Lollipop onwards. I will aim to explain why.
Recently I have added SD Card support. Anybody who has implemented proper SD Card support in their apps knows how frustrating this can be, especially with the new permissions required from the user in Lollipop onwards as part of the storage access framework (this is so bad that I even made a tutorial with screenshots showing the user how to grant access the SD Card, I have seen real users get confused by the SAF permissions activity). On KitKat it is impossible to write to the SD Card unless the device is rooted. This resulted in lots of negative reviews for apps when this limitation was introduced. Prior to KitKat all that was required was the write access permission to be declared in the application manifest. As you can see there are three different scenarios to write code for and test (pre-KitKat, KitKat and Lollipop onwards) which adds to development time/costs and bug fixing can become extremely cumbersome having to do full regression tests. However KitKat is still very popular. Since I don't even own a KitKat device it's impossible to test this scenario, let alone a rooted version (emulators only go so far).
Here are some additional facts:
KitKat devices account for 24% of checkins to Google Play
The 24% of KitKat users combined with older API levels (down to API 2.2) account for a whopping 39.3% of users checking in to Google Play.
Memory management for bitmaps just isn't great prior to Lollipop (lots of OOM can occur even with careful memory management as I have seen from crash reports).
JellyBean 4.4.4 got released in October 31, 2013. That's just over 3 years ago. In the world of mobile, that's equivalent to an entire period of geology such as the Jurassic Period.
JellyBean is discontinued according to https://en.wikipedia.org/wiki/Android_version_history
Fact: most of the bad reviews for my app are coming from users with low-end devices running older versions of Android, Lollipop onwards users generally leave more favourable reviews.
So in conclusion I am thinking about dropping support for KitKat and older at some point unless anybody believes it is worth supporting still? The question is how likely are those users ever going to make in-app purchases, although from a perspective of just showing adverts it might be worth it.
Please share your experiences with your apps and contribute your ideas.
Click to expand...
Click to collapse
i want to run marshmallow apps on jellybean 4.1.2 by decompiling particular app and editing its manifest.xml then change the minsdkversion to 16. is it possible? i tried it by decompling the file but i havent found any minsdkversion in manifest file after decompiling the apk.i downloaded an app called solid explorer and there is an option in it to open the apk file but that apk is not decompiled.so i took compiled apk ,i opened compiled apk file and then to manifest file after opening it i can see the minsdk version and other platform versions remember that was compiled apk file.
please tell me how to do this.
NOTE: So far, I've only seen this blog post talk about the HD 8, but the same should go for HD 7 owners as well: Don't get scammed.
In my usual daily search for possible root, I generally don't find anything of interest. Today however, is a different story.
This will be short and simple: Don't get scammed. If it sounds too good to be true, it probably isn't. An "article" is circulating the web this morning, in a couple places, claiming the new Android Oreo 8.0 is available for the Amazon HD 8.
"Good news to everyone! Amazon Fire Hd 8 owners can now update their device to 8.0 Oreo by using custom ROM." He even makes it super easy because you "Don't bother to Google or search for it" (because believe everything you read on the internet. It's true. [NOTE EXTREME SARCASM]). Why? They conveniently "uploaded it for you."
Don't fall for scams. As of the posting of this thread, to my knowledge and the knowledge of developers on this site, there is NO "Android Oreo custom ROM" available for the HD 8 and is NOT available for ANY Amazon tablet regardless if it's rooted. In fact, there is NO custom ROM available AT ALL for the HD 8. You CAN however, flash a custom ROM if you have a Fire HD 7, assuming it can be rooted and is earlier than FireOS 5.3.2.1.
The current FireOS, 5.4.4.0 CANNOT be rooted, the bootloader IS LOCKED therefore NO custom ROM is available for ANY Amazon tablet, regardless of it's size. Sorry for being so 'bold' *snicker*, but I hate seeing posts and threads about people bricking their devices beyond repair because they believed someone on a blog. When in doubt, take some time to look over XDA and find the proper forum section pertaining to your device for assistance. If all else fails, contact your service provider or device manufacturer.
You can check your tablet for updates by tapping settings > device options > system updates > check for updates. It will also tell you the latest FireOS version. You can download an app like 'Droid Hardware Info' to see what Android base you have.. Install > open > device > OS version. The newest tablets are Android Lollipop 5.1.1.
DragonFire1024 said:
NOTE: So far, I've only seen this blog post talk about the HD 8, but the same should go for HD 7 owners as well: Don't get scammed.
Click to expand...
Click to collapse
Same thing happens every time a new version of Android is released; follows the usual click-bait happy media frenzy. Likely varients of the same article are popping up for other device types. A future sucker is born every day.
As seen here
https://www.reddit.com/r/LineageOS/...ect_trebel_devices/?utm_source=reddit-android
LineageOS team state that project treble is in its baby shoes and completely dependant on google to optimize it even more since as of now gsi rom requires certain adjustments for each device, so will project treble successed?
any1 has an insight please share.
I think it needs more adjustment. The kernel should be universal and updateable along with the OS, it's pretty universal as it is at the moment. Drivers should also be standard and updateable, at least for standard items. There should be a driver model where possible to support other devices, and any phone specific changes could be done through manufacturer supplied drivers. There's really no reason why it can't be done, it would be along the lines of how Windows works. Of course, it can be tailored to suit phones.
System updates should realistically come from Google, it would mean all phones and devices would be up to date with the latest security updates. The phone can also check with the manufacturer for specific updates. If Google keeps them apprised of any changes they can update their specific updates in time. This model would mean individual service testing for a new OS update etc wouldn't be a problem since it should at least be compliant with the base model.
Don't forget Google tracks down security leaks in other OS like Windows, which isn't even a direct competitor, and releases the security leak information if it isn't patched within 30? days. How many Android devices are updated with security patches within 30 days by the manufacturer? It's very much a double standard. Google really needs to think of an even more universal model like I just depicted for Android 10 Quinoa Slice (or whatever they call it).
Will Treble succeed? It's a step in the right direction, but needs more work. Not only should something like I just described be done, it should be made mandatory for all new devices. It doesn't mean custom versions are out, but custom versions would have to have OTA updates and be updated quickly along with the standard OS.
To say whether it succeeded or not, I think you'd first need to define what's its goal.
I still don't even know the answer as of today.
Some people say that the goal is to have a system image controlled and updated by Google.
But I don't see this happening any time soon. Google would need to test their GSIs on many devices, and they didn't even test P GSI over O-MR1 Pixels!
It seems to me that their goal was simply to make updates easier to OEMs. Considering Essential PH-1 getting Pie day-one, this might seem a success.
But we'll need to compare Oreo adoption rate to Pie's to confirm.
Oooh someone made a thread so i can moan cheers
The main problem with treble for me is that it's splintered between a plethora of devices, so one dev will release a treble rom and a multitude of device owners will flash it, each with their own subjective problems and issues, requests and wants.
And there lies the problem, it's difficult even when it's a dedicated rom thread for a particular device to get help at times.
So when you have a bunch of users talking about completely different devices you haven't got a hope in hell.
I think there should be branches to each thread for each specific device, that way help threads can be more linear rather than the chaos that it is at the moment.
Least that's my thoughts
My only rom i've flashed is RR and besides a few missing features, Fingerprint, Stereo and NFC i think it's brilliant.
Hi friends,
Background: I have DirecTV Streaming Service for my home because it offers 5.1 surround.
I HAD their mobile app on my Sprint Note 4 but before Sprint was purchased by T-Mo I was prompted to update the app in the Play Store.
When I tried a dialog popped up saying that my Android 6 Marshmallow phone was no longer compatible and that DirecTV Stream now required Android 7, Android 8 recommended.
If I successfully flash an OREO 8.1 ROM will the Play Store permit me to update my app or will they see that I am a Note 4 and deny me ?
And although YTTV/Hulu etc apps still work on Marshmallow they have poor audio for my home surround system .
No, it will only see the actual version of Android.
I actually flashed CRDROID Oreo 8.1 and was then able to download the latest apk from the playstore.
Installed and ran perfectly...
BUT, my WIFI connection repeatedly disconnected.
So did my bluetooth.
And my S-Pen was neutered.
Battery life abysmal.
Also, OREO was simply baffling to me.
Nothing like the Marshmallow that I am used to.
I wish that there was a way to "spoof" my android version and APPEAR as Nougat 7.
The Note 4 itself proved that it can run the app A-OK.
When Sprint died I just assumed that the latest Samsung offering would be better than my 7 year old phone.
So I bought a brand new A52 in August 21.
$450.00 wasted.
I hate it.
Stupid aspect-ratio results in black bands while streaming.
The display IS an inch wider (in landscape mode), 6.7 inches vs 5.7 inches.
BUT, considerably shorter (in landscape mode) which translates to LESS screen area.
As a result, typing is nearly impossible on the diminished keyboard.
No replaceable battery.
No S-Pen.
Overall, a big step BACKWARD !
<rant off>
Maybe try https://forum.xda-developers.com/t/...experience-pie-trlte-tblte-trlteduos.3925885/ (PixelExperience 9)?
There are tons of roms and at least 1 will suit your needs
traman124 said:
Maybe try https://forum.xda-developers.com/t/...experience-pie-trlte-tblte-trlteduos.3925885/ (PixelExperience 9)?
There are tons of roms and at least 1 will suit your needs
Click to expand...
Click to collapse
Thanks pal...I have only flashed the OREO I mentioned so I am a very green newbie.
I have seen positive comments about Pixel so I will give it a shot.
Android 9 > 8. Any apps for 8 will work on 9 (or 10 and 11 and so on)
Hi Gang,
I thought that I'd update my results for those who are interested.
I eventually got comfortable flashing the Custom ROMs/GApps and tried many variants from 7(Nougat) up to Lineage 18.1(Android 11).
I tried a Pixel Experience package with included GApps that was very nice but on THIS particular ROM the DTVS(DirecTV Stream) APK would not install.
I suspect that the very comprehensive included GApps somehow betrayed my device's true identity.
All the other ROMs that I successfully flashed permitted the installation of the DTVS APK and it streamed flawlessy on each of them.
I do not understand why Marshmallow 6.0.1 is no longer considered sufficient.
Anyway, in the end I was really enjoying CRDroid 10 but something I had not considered made this entire exercise moot.
My home has terrible cellular reception and WIFI-Calling is indispensible for phone connnections.
What I had not realized was that WIFI-Calling is associated with each carrier's customization and cannot be incorporated into Custom ROMs as it is closely held proprietary information.
And so I have returned to the stock T-MO ROM I started out with.
Like anyone else I must be able to reliably contact emergency services for police, fire, medical, etc.
So my current solution is to leave my Mint Mobile SIM Card installed in the Note 4 while I am at home.
And if I wish to stream DTVS(via cellular) while I am out and about I must transfer the SIM to my Huawei Mate 10 which runs EMUI 12 (Android10).
It lacks WIFI Calling so it cannot be my home phone, BUT, it streams DTVS perfectly on a nice 16:9 display (no black bands on each side).
Swapping the card is a hassle but it's the best option I could think of.
I hope other users can somehow profit from my experience.
Weird. The app is not looking for the phone model; it's looking for the Android version.
Correct !
I can only assume that the model and droid version are conflated since the Note 4 was last updated in 2015 (marshmallow 6.0.1) and no further updates were/are authorized.
And so if the app sees Note 4 it can only be 6.0.1 max.
Just guessing here.
I spent alot of time studying build.prop mods to spoof my version but that never panned out.
I feel like I need to restate this: it doesn’t care if you have a note4 and limit based on that. It only limits based on version of Android.
Weird that PixelExperience didn’t work….
Lord_Ligonier said:
Correct !
I can only assume that the model and droid version are conflated since the Note 4 was last updated in 2015 (marshmallow 6.0.1) and no further updates were/are authorized.
And so if the app sees Note 4 it can only be 6.0.1 max.
Just guessing here.
I spent alot of time studying build.prop mods to spoof my version but that never panned out.
Click to expand...
Click to collapse
2016. That's when Marshmallow was released. 2015 was Lollipop
I Recently learned of a Magisk Module called "Hide Props Config"
that promises to fake my version...
How To Spoof/Fake The Android Version On Your Device
How to Spoof/Fake the Android Version on your device
In this comprehensive guide, we will show you the steps to spoof/fake the current Android version on your device to an older one.
droidwin.com
Trying to understand how this might work to make MY android version masquerede as a newer version that would permit the installation of the DTVS APK.
It appears that having rooted via Chainfire that I would need to unroot and then start over with Magisk.
Something about the stock boot.img being patched creating an obstacle to the installation.
Has anyone successfully installed Magisk while previously rooted ?
I tried and the app installs but two critical buttons are grayed out at the bottom of the app.
SU and Modules.
Anyone ???