I’ll public announce PodLP for Android soon, but I thought I’d share it here first since this group shared ROMs to help reverse engineer features and APIs.
PodLP is a free podcast app designed for flip phones. I originally launched it 6 years ago for KaiOS. It’s now also available for the JioPhone and Cloud Phone. I tested and optimized it for the following phones, but it should work for many more.
Kyocera DuraXV Extreme
TCL Go Flip 2
LG Wine 2
Sonim XP3+
The app adapts based on whether your device has physical soft keys, and where possible, leverages native APIs for navigation bars, dialogs, and more. On phones without a launcher that lists third-party apps you can launch PodLP via:
A dialer secret code: PODLP (*#*#76357#*#*)
A persistent notification (enabled in PodLP Settings)
A special “Open PodLP” contact (enabled in PodLP Settings)
The app can be sideloaded on any Android phone running version 7.0+ (SDK 24). It runs well on my LG Wine 2 which only has 1GB RAM (and allocates 32mb to apps). The app should also check automatically for updates. I’m still manually uploading new APKs, although I plan to build out CI/CD soon.
Let me know if you have any questions, or run into any issues. I have Crashlytics set up, so unless you disable anonymous usage data, I should automatically get crash logs. Please mention what device you have, and if you’re willing to help by sharing ADB logs and/ or extracting APKs/ system frameworks to help me expand the devices supported.
I’m just curious if you can easily take what you used to make the app d-pad compatible and put it into a different app or you would have to build the whole thing over again for a different app?
I was going to say that someone should make a library to make it easy to use these hidden APIs, and without needing to write separate logic for specific phone models.
I don’t think it would be feasible to make a library that enables existing apps (i.e. WhatsApp) to work natively with these phones. But it would be possible to make a library out of most of the features I’m using. Developers wouldn’t want it because it relies on bypassing hidden API restrictions, which is against Google Play ToS.
What I don’t understand is why OEMs don’t just make their UI the default. None of my phones are Google certified, so there’s no approval process getting in the way. Yet components like a context menu, navigation bar, or dialog are all proprietary and limited to only their apps. Why not just style the default Dialog component?
The point won’t be for modding apps nor google play phones but for users on the forum or similar dumbphone app creators would enjoy a lot a library that automatically does all your tricks per device. You did an amazing job! (not sure if you realize it yourself ) if your tricks can easily be used by developers developing for general flip phones like you are, that would be amazing
That’s fair. I need to think through how this might work. I think it would need to be a proper library (i.e. on Maven Central). I do have some reservations about making this open source because of previous negative experiences with getting copied and directly competing with a version of my own work. After I’ve launched publicly, I’ll see what options might enable hacker-type developers to leverage this work.
I’m also curious if there are certain apps people request most often. I considered a launcher a while back, but it’s fairly complex because of integrations into so many other parts of the OS. I also recognize it’s difficult to actually make any money off this work. Podcasts have a double-sided market where podcast hosts want to find new listeners, but most utility apps don’t have any way to make it financially sustainable.
Yes! You should see a download option in the context menu on the episode page, but only for subscribed podcasts. This is actually the same behavior as KaiOS. Because of limited storage space, I didn’t want downloads to potentially get orphaned. Perhaps it should always show on Android
yup. Tried subscribing and it worked. It didn’t download to internal storage (/storage/emulated/0). Probably intentional. Don’t remember how it was in kaios.
another small bug, (sonim xp5800 android 8.1): the search button in the menu doesn’t show the search words. here’s a screenshot:
PodLP uses Android’s DownloadManager, which downloads to whatever storage is set as the default. This is by design because 1) it’s simple and 2) it doesn’t risk hitting an OOM error on KaiOS I had to write my own download system and it doesn’t run in the background (because it can’t).
Thanks for sharing the screenshot. 320 × 432, what a strange resolution. Looks like it’s getting clipped by the title bar, should be a simple fix for the next update. Glad you figured out how to trigger the context menu on a device without soft keys
this phone has a dedicated menu button which triggers menu in almost any app with a menu.
i might be wrong but i think there might be a way to have the notification action be to open the file which can show where it is. Or just in the notification show path.
i got no clue how you figured it out from a screenshot but i did change my dpi. Not sure if its related.
That’s awesome! Phones like the Cat S22 don’t have a dedicated menu button, and they also don’t have soft keys.
i got no clue how you figured it out from a screenshot but i did change my dpi. Not sure if its related.
The screenshot was 320x432 and that matched what it says on Google but yeah the DPI looks off, it’s much smaller/ more zoomed out than when I tested on an emulator
) if your tricks can easily be used by developers developing for general flip phones like you are, that would be amazing
on KaiOS I had to write my own download system and it doesn’t run in the background (because it can’t).
but yeah the DPI looks off, it’s much smaller/ more zoomed out than when I tested on an emulator